赵成:劈开迷雾,蘑菇街技术架构演进之道
今天,我主要分享典型互联网电商企业蘑菇街的发展历程,和大家共同探讨在发展过程中,我们是如何进行技术架构和技术选型的,我认为总结下来就是四个字——顺势而为。
2015 年 1 月,我离开华为,来到了蘑菇街,主要负责平台技术部。在过去的 12 年里,我绝大部分的经历和经验基本上集中于后端的技术架构,如今主要专注于云计算领域。
蘑菇街是一个集时尚内容和时尚电商于一体的网站。2011-2013 年是蘑菇街发展的第一个阶段,主要做时尚导购内容;2013-2016 年是蘑菇街发展的第二阶段,随着业务的发展和用户的积累,我们开始投入大量的精力去做电商平台,完成整个交易体系的建设;2016- 至今是蘑菇街发展的第三个阶段,我们开始投入很大的精力去做直播技术,与能力超强的主播合作完成销售体系的建设。
从去年年中开始,蘑菇街进入第四个阶段。此时,蘑菇街的线上平台和技术体系建设已经比较完善,我们希望能把线上的技术经验赋能到线下,进入线下时尚内容生产中,给用户提供更高品质、更具时尚感的产品。
实际上,我们整个技术的发展过程与业务发展相匹配的。
2011-2013 年,我们正在做内容导入,业务架构相对来说比较简单,在此阶段的团队使命是技术支撑公司业务发展。
因为这时的技术栈相对比较简单,整个架构是一个单体架构,所以我们的技术选择策略是简单直接、快速上手、快速开发。
2013-2016 年,我们开始做电商的交易体系。这时,我们需要建设相应的用户体系,包括交易、支付、广告、搜索、会员、店铺等一系列内容,于是 2016 年,我们的技术团队快速扩充到了 800 人。
一方面是因为业务复杂度上升,另外一方面是因为当时整个业务的体量在高速发展,我们日 PV 可以达到三亿,DAU 也突破了百万,双 11 大促时规模会更大。在此阶段,我们的技术团队使命是通过技术支撑公司业务高速发展。
因为我们的业务变得更加复杂,业务体量也变得非常大,单体架构已经没有办法满足我们对业务灵活性的响应需求。
于是,我们开始全面转向分布式架构和技术,策略是架构设计一定要体系化。我们根据整个业务领域进行了模块划分,设计了一些基础的架构,考虑最多的是高性能、高并发和大流量,这对于技术平台的要求是非常高的。
我们将分布式架构分为了三层,以最底层资源——基础设施层为主,上面是分布式组件、核心业务组件层以及业务应用层。
2015 年,我们开始规划分布式体系系统时,中台的概念并没有像现在这么火爆,业界也没有太多很成熟、很完善的经验供我们借鉴。
但是最后我们发现,当我们立足于自己的问题或场景,一步步解决问题,最后做出来的样子基本就是现在的技术中台和业务中台的样子。
因此当我们需要做类似的架构时,其实只要立足于我们原本的问题,按照正确的方式去做,到最后大家都是殊途同归的。
技术团队面临的挑战,尤其是在分布式架构下,你会发现始终离不开三条:效率、稳定和成本。
要解决效率问题,首先我们要建设一个 DevOps 体系。微服务实际上是将原先单体的架构按照业务领域进行拆分,每一个细分的业务领域可能会单独成立一个开发小组,用于开发和维护一些应用。接着,开发团队需要与产品、运营部门等做大量的沟通和交流,还需要考虑测试、运维等一系列相关事宜。因此,想要解决效率问题,不仅在技术上会面临挑战,还会带来很多跨团队协作问题。
在跨团队协作过程中,你会发现项目团队内部也划分了不少团队,在这种跨职能或跨组织架构协作的情况下,如何高效的协作和配合是一件非常重要的事情。所以,我们需要想法设法解决跨团队的协作、沟通和管理的问题。
于是,我们做了一些自动化的流水线和几个关键点的管理机制,以便于打通在流程环节中的持续交付通道。除此之外,我们还做了一些管理工具,比如统一管控平台等等。
在整个过程中,我们总结出了三个关键原则:
第一,标准化,避免架构失控。我们可以尝试很多技术,创造一个开放的氛围,但是在项目落地时,基本上只会选择一种主流的框架和解决方案,在保证高效的协作能力的同时,还要避免架构失控。
第二,以应用为核心的架构体系。我们整个架构是以应用为核心,它拆分出来的功能点一定要对应到应用上,以便于跟踪、评估和管理。
第三,自上而下的推进机制。当团队间不能达成一致时,我们需要采取自上而下的推进机制。在自上而下推进的过程中,我们需要一个至少是技术 VP 或者最高的技术领导者作为决策者,他需要决定整个架构体系的标准。在这种情况下,大家会保证步调一致,达到最高的效率。
稳定是所有工作的前提,现实中,很多时候我们会遇到不可预见的情况发生,比如突然爆发的流量,这是很难提前预测的。这时,我们不是应该保证系统不出问题,而是应该保证系统在出现异常的情况下仍可以正常工作。
不管是电商,还是社交类软件,我们所做的工作只有一个核心点——面向极端的场景。在正常情况下,系统一般都不会出现太大的问题,但是在非常极端的业务场景下,各类问题就会集中爆发,原来很小的问题,也会被放大,甚至形成雪崩效应,因此我的建议是,如果要做稳定性建设,先找准业务将要面对的极端场景会是什么,比如电商业务的大促场景、社交类软件的热点事件等等,这样才能做到有的放矢。
而稳定性保障中,非常关键的一点是容量评估。比如在双十一时,我们会对整个用户模型进行评估,估算参与用户数量、用户消费金额、优惠条件等等,根据历史数据进行统计,统计出来以后,我们将会按照这个模型进行压测,模拟流量是否足够支撑。同时,在压力测试时,会引入限流降级,监控等稳定性保障手段。
我们都知道,有时越到技术做得越深入,投入成本会越高,但获得的收益可能会越小,因此就涉及到了投入、产出,成本取舍的问题。
举个例子,为了应对双十一,我们前几年需要投入几千万采购设备扩充容量。峰值过后,大部分容量都是闲置的,这属于极大的浪费。同时,我们要在基础架构上,投入巨大的精力解决开源软件的 bug、解决高压力场景的突发问题等等。最后,导致我们在基础架构上的投入越来越大。
当我们在这方面投入的资源和精力越来越多时,会导致我们无法集中精力在业务发展上。所以,我们开始反思到底是在技术上继续做得更深,还是把更多精力放在业务上,专注解决业务问题。
2016 年,我们准备开始做直播业务时,再次遇到了这个难题。我们调研发现,直播技术需要很多专门人才,比如视频编解码专业的人才;同时,我们也没有资源做很强大的基础架构,比如建设全国的 CDN 节点,这该怎么办?最后,我们决定与公有云合作,找专业厂商为我们提供整套方案,后来在云厂商的支持下,我们的直播业务在一个月左右就快速上线了,而且现在已经成为我们非常关键一块业务,如果当时我们没有争分夺秒做下来,这块业务可能就不存在了。
当我们面对很多在基础架构和基础设施上的问题时,通过我们在直播领域与云的合作,让我们再次感受到云计算技术的力量。
因此我们开始思考,我们应该如何利用好云计算。我们仔细分析了当时整个云计算的发展现状,发现很多之前遇到的专业问题,其实早已被云厂商解决了。随着云技术架构的完善,很多企业面对的基础架构问题在云上已经早已不是问题。
同时,现在很多新技术都是在云上演进出来的,已经很少有跟云不相关的技术了,所以,云必然是未来的趋势。2017 年,我们决定将整个系统迁移上云,将我们更宝贵的精力专注在业务和业务架构上。
于是,我们的整个技术架构重心开始随之改变。之前,我们做电商面对的是大流量,高并发,需要花费很大精力建设技术平台,但是当我们的业务发展起来后,上到云上了,我们逐步将精力转向产品和运营团队,加大我们对线下生产环节的支持,打磨我们的产品和运营能力,这才是我们公司的核心竞争力。
这时,技术团队的职责就变成充分利用云计算,为业务提供更多的可能性。
在当前的技术高速发展背景下,在探索新技术和新业务过程中,技术人员的优势就体现出来了。因为技术人员对新技术有一定的敏感度,他们会在第一时间接触和体验到最新的技术,从而联想到很多技术层面的解决方案。但是对于没有技术背景的人员,当他们不了解技术时,就只会想着产品功能和运营的需求,不会想到用什么样的端到端的技术解决方案。我相信,未来做技术的同学一定会有更大的发展空间。
最后,我总结一下蘑菇街的整个发展过程。我们从最初的单体架构,到后来的分布式架构,最后基于公有云的基础架构,整体迁移上云。在这个过程中,你会发现我们做的很多事情是立足于我们当下所遇到的问题,立足于实际场景,踏踏实实解决每一个问题,结合业界趋势找到最佳解决方案,四个字总结——顺势而为。
感谢大家的聆听,谢谢。
编者注:赵成老师的干货分享是不是很精彩呢?是不是还没有看够呢?下载「极客时间」APP 订阅赵成的运维体系管理课程吧,带你直击运维的本质!
美篇 首席架构师 张超 | DataPipeline CTO 陈肃
AfterShip CTO 洪小军 | 知道创宇 CTO & COO 杨冀龙
UCloud CEO 季昕华 | 编程猫 CTO 孙悦
喜马拉雅 CTO 陆栋栋 | 有赞 CTO 崔玉松
(点击文字查看文章内容)
你想与以上优秀的 TGO 鲲鹏会会员一起学习交流吗?
赶紧点击「阅读原文」,加入 TGO 鲲鹏会,与 800+ 全球科技领导者同行。