赵成：劈开迷雾，蘑菇街技术架构演进之道

本文转载自微信公众号：TGO鲲鹏会(ID：tgo-kunpenghui)，演讲者：蘑菇街平台技术总监赵成

近日，由极客邦科技旗下品牌 TGO 鲲鹏会举办的 GTLC 全球技术领导力峰会台北站圆满结束。在 GTLC 台北站上，蘑菇街平台技术总监 & TGO 鲲鹏会杭州分会会员赵成带来了「顺势而为，技术架构演进之道」的主题分享。以下为赵成现场分享内容：

今天，我主要分享典型互联网电商企业蘑菇街的发展历程，和大家共同探讨在发展过程中，我们是如何进行技术架构和技术选型的，我认为总结下来就是四个字——顺势而为。

2015 年 1 月，我离开华为，来到了蘑菇街，主要负责平台技术部。在过去的 12 年里，我绝大部分的经历和经验基本上集中于后端的技术架构，如今主要专注于云计算领域。

赵成现场分享

蘑菇街的技术发展历程蘑菇街是一个集时尚内容和时尚电商于一体的网站。2011-2013 年是蘑菇街发展的第一个阶段，主要做时尚导购内容;2013-2016 年是蘑菇街发展的第二阶段，随着业务的发展和用户的积累，我们开始投入大量的精力去做电商平台，完成整个交易体系的建设;2016- 至今是蘑菇街发展的第三个阶段，我们开始投入很大的精力去做直播技术，与能力超强的主播合作完成销售体系的建设。

从去年年中开始，蘑菇街进入第四个阶段。此时，蘑菇街的线上平台和技术体系建设已经比较完善，我们希望能把线上的技术经验赋能到线下，进入线下时尚内容生产中，给用户提供更高品质、更具时尚感的产品。

实际上，我们整个技术的发展过程与业务发展相匹配的。

2011-2013 年，我们正在做内容导入，业务架构相对来说比较简单，在此阶段的团队使命是技术支撑公司业务发展。

因为这时的技术栈相对比较简单，整个架构是一个单体架构，所以我们的技术选择策略是简单直接、快速上手、快速开发。

2013-2016 年，我们开始做电商的交易体系。这时，我们需要建设相应的用户体系，包括交易、支付、广告、搜索、会员、店铺等一系列内容，于是 2016 年，我们的技术团队快速扩充到了 800 人。

一方面是因为业务复杂度上升，另外一方面是因为当时整个业务的体量在高速发展，我们日 PV 可以达到三亿，DAU 也突破了百万，双 11 大促时规模会更大。在此阶段，我们的技术团队使命是通过技术支撑公司业务高速发展。

因为我们的业务变得更加复杂，业务体量也变得非常大，单体架构已经没有办法满足我们对业务灵活性的响应需求。

于是，我们开始全面转向分布式架构和技术，策略是架构设计一定要体系化。我们根据整个业务领域进行了模块划分，设计了一些基础的架构，考虑最多的是高性能、高并发和大流量，这对于技术平台的要求是非常高的。

我们将分布式架构分为了三层，以最底层资源——基础设施层为主，上面是分布式组件、核心业务组件层以及业务应用层。

2015 年，我们开始规划分布式体系系统时，中台的概念并没有像现在这么火爆，业界也没有太多很成熟、很完善的经验供我们借鉴。

但是最后我们发现，当我们立足于自己的问题或场景，一步步解决问题，最后做出来的样子基本就是现在的技术中台和业务中台的样子。

因此当我们需要做类似的架构时，其实只要立足于我们原本的问题，按照正确的方式去做，到最后大家都是殊途同归的。

技术团队面临的永恒挑战技术团队面临的挑战，尤其是在分布式架构下，你会发现始终离不开三条：效率、稳定和成本。

效率挑战

要解决效率问题，首先我们要建设一个 DevOps 体系。微服务实际上是将原先单体的架构按照业务领域进行拆分，每一个细分的业务领域可能会单独成立一个开发小组，用于开发和维护一些应用。接着，开发团队需要与产品、运营部门等做大量的沟通和交流，还需要考虑测试、运维等一系列相关事宜。因此，想要解决效率问题，不仅在技术上会面临挑战，还会带来很多跨团队协作问题。

在跨团队协作过程中，你会发现项目团队内部也划分了不少团队，在这种跨职能或跨组织架构协作的情况下，如何高效的协作和配合是一件非常重要的事情。所以，我们需要想法设法解决跨团队的协作、沟通和管理的问题。

于是，我们做了一些自动化的流水线和几个关键点的管理机制，以便于打通在流程环节中的持续交付通道。除此之外，我们还做了一些管理工具，比如统一管控平台等等。

在整个过程中，我们总结出了三个关键原则：

第一，标准化，避免架构失控。我们可以尝试很多技术，创造一个开放的氛围，但是在项目落地时，基本上只会选择一种主流的框架和解决方案，在保证高效的协作能力的同时，还要避免架构失控。

第二，以应用为核心的架构体系。我们整个架构是以应用为核心，它拆分出来的功能点一定要对应到应用上，以便于跟踪、评估和管理。

第三，自上而下的推进机制。当团队间不能达成一致时，我们需要采取自上而下的推进机制。在自上而下推进的过程中，我们需要一个至少是技术 VP 或者最高的技术领导者作为决策者，他需要决定整个架构体系的标准。在这种情况下，大家会保证步调一致，达到最高的效率。

稳定性体系

稳定是所有工作的前提，现实中，很多时候我们会遇到不可预见的情况发生，比如突然爆发的流量，这是很难提前预测的。这时，我们不是应该保证系统不出问题，而是应该保证系统在出现异常的情况下仍可以正常工作。

不管是电商，还是社交类软件，我们所做的工作只有一个核心点——面向极端的场景。在正常情况下，系统一般都不会出现太大的问题，但是在非常极端的业务场景下，各类问题就会集中爆发，原来很小的问题，也会被放大，甚至形成雪崩效应，因此我的建议是，如果要做稳定性建设，先找准业务将要面对的极端场景会是什么，比如电商业务的大促场景、社交类软件的热点事件等等，这样才能做到有的放矢。

而稳定性保障中，非常关键的一点是容量评估。比如在双十一时，我们会对整个用户模型进行评估，估算参与用户数量、用户消费金额、优惠条件等等，根据历史数据进行统计，统计出来以后，我们将会按照这个模型进行压测，模拟流量是否足够支撑。同时，在压力测试时，会引入限流降级，监控等稳定性保障手段。

成本取舍

我们都知道，有时越到技术做得越深入，投入成本会越高，但获得的收益可能会越小，因此就涉及到了投入、产出，成本取舍的问题。

举个例子，为了应对双十一，我们前几年需要投入几千万采购设备扩充容量。峰值过后，大部分容量都是闲置的，这属于极大的浪费。同时，我们要在基础架构上，投入巨大的精力解决开源软件的 bug、解决高压力场景的突发问题等等。最后，导致我们在基础架构上的投入越来越大。

当我们在这方面投入的资源和精力越来越多时，会导致我们无法集中精力在业务发展上。所以，我们开始反思到底是在技术上继续做得更深，还是把更多精力放在业务上，专注解决业务问题。

2016 年，我们准备开始做直播业务时，再次遇到了这个难题。我们调研发现，直播技术需要很多专门人才，比如视频编解码专业的人才;同时，我们也没有资源做很强大的基础架构，比如建设全国的 CDN 节点，这该怎么办?最后，我们决定与公有云合作，找专业厂商为我们提供整套方案，后来在云厂商的支持下，我们的直播业务在一个月左右就快速上线了，而且现在已经成为我们非常关键一块业务，如果当时我们没有争分夺秒做下来，这块业务可能就不存在了。

云计算基础架构呈现出的显著特点

当我们面对很多在基础架构和基础设施上的问题时，通过我们在直播领域与云的合作，让我们再次感受到云计算技术的力量。

因此我们开始思考，我们应该如何利用好云计算。我们仔细分析了当时整个云计算的发展现状，发现很多之前遇到的专业问题，其实早已被云厂商解决了。随着云技术架构的完善，很多企业面对的基础架构问题在云上已经早已不是问题。

同时，现在很多新技术都是在云上演进出来的，已经很少有跟云不相关的技术了，所以，云必然是未来的趋势。2017 年，我们决定将整个系统迁移上云，将我们更宝贵的精力专注在业务和业务架构上。

于是，我们的整个技术架构重心开始随之改变。之前，我们做电商面对的是大流量，高并发，需要花费很大精力建设技术平台，但是当我们的业务发展起来后，上到云上了，我们逐步将精力转向产品和运营团队，加大我们对线下生产环节的支持，打磨我们的产品和运营能力，这才是我们公司的核心竞争力。

这时，技术团队的职责就变成充分利用云计算，为业务提供更多的可能性。

在当前的技术高速发展背景下，在探索新技术和新业务过程中，技术人员的优势就体现出来了。因为技术人员对新技术有一定的敏感度，他们会在第一时间接触和体验到最新的技术，从而联想到很多技术层面的解决方案。但是对于没有技术背景的人员，当他们不了解技术时，就只会想着产品功能和运营的需求，不会想到用什么样的端到端的技术解决方案。我相信，未来做技术的同学一定会有更大的发展空间。

顺势而为

最后，我总结一下蘑菇街的整个发展过程。我们从最初的单体架构，到后来的分布式架构，最后基于公有云的基础架构，整体迁移上云。在这个过程中，你会发现我们做的很多事情是立足于我们当下所遇到的问题，立足于实际场景，踏踏实实解决每一个问题，结合业界趋势找到最佳解决方案，四个字总结——顺势而为。

感谢大家的聆听，谢谢。