赵成：劈开迷雾，蘑菇街技术架构演进之道
今天，我主要分享典型互联网电商企业蘑菇街的发展历程，和大家共同探讨在发展过程中，我们是如何进行技术架构和技术选型的，我认为总结下来就是四个字——顺势而为。
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 崔玉松
（点击文字查看文章内容）