专访蘑菇街七公：25 倍增长远非极限，优化需要偏执狂

每秒能支撑的峰值订单数是衡量电商系统高并发可扩展能力的重要体现，在电商内提升每秒支撑订单数存在无数的方法，每一个方法都存在各自的优化角度和对应的障碍挑战，如何在一开始根据自身企业的特点选择最合适的优化路径，并其后在这路径上高效贯彻和执行，对于团队尤其是初创团队而言都不是简单的事情。

2016 年 7 月 15-16 日， ArchSummit 全球架构师峰会将在深圳举行。本届大会，我们邀请了蘑菇街技术专家七公，前来分享《跨越篱笆——蘑菇街每秒最大订单数25 倍提升历程​》的内容，讲述的是蘑菇街从一开始只能支撑每秒400 单的交易创建一直到每秒1 万单的优化实践内容，以及他们在这个过程中翻越的无数障碍和对应的解决之道。

现在我们就来采访七公老师，看看蘑菇街是如何快速走出一条高效、实用的服务化发展路径的。

受访嘉宾介绍：

七公，原名白辉，2014 年以前在阿里巴巴B2B 主要负责Aliexpress 资金中心、评价、任务中心等系统。14 年8 月离开阿里出国游历，15 年回国后加入蘑菇街，目前在蘑菇街、美丽说、淘世界大集团共享的电商基础平台负责购物车下单小组及交易平台架构工作。

InfoQ：在 2014 年以前您在阿里巴巴 B2B 负责 Aliexpress 资金中心等项目，能否谈谈在阿里的这段经历给您之后出国游历、回国加入蘑菇街带来了哪些动因和影响？

七公：我是 2011 年 3 月加入阿里巴巴的，彼时阿里整个的业务、技术体系都处在一个飞速发展的时期，我个人也获得了飞快的成长。受去看世界的梦想推动，2014 年 8 月我和女朋友一起从阿里辞职，出国游历了半年。

回来之后，阿里当时内部各方面整体已经趋向稳定，我希望找到另一家飞速发展的公司，北京上海找了一圈不满意，最终还是回到了杭州，加入了蘑菇街。在蘑菇街一年的时间里，我们业务和技术都获得了火箭般的飞跃式前进，我一年里的进步和收获比在其他公司呆两年得到的还要多，实现了和公司的共进步、同成长。

InfoQ：您加入蘑菇街电商团队后带领团队同学仅用一年便完成服务架构的各阶段升级，能否谈谈你们是如何规划优化路径并高效实现的？在高效率工作上你们有什么经验或技巧可以分享？

七公：第一个阶段【蘑菇街系统拆分 & 服务化 1.0 体系构建】，是我们做 PHP 全面转型 Java 体系、初步建成电商基础服务中心的战略规划，在面临不停歇的业务需求和巨大的系统改造压力下，我们采用瀑布流工程方法，通过规划、分析、设计实现、测试、服务产品 & 文档交付的过程，高质量地把第一阶段的服务化建设根基像打桩一样打牢，然后通过进一步的迭代开发不断完善。

第二阶段【购买链路核心服务的性能提升 & 服务架构 1.5】和第三阶段【服务 SLA 保障推动稳定性提升 & 服务架构 2.0】，实际上是业务迅猛发展、流量不断上涨、日常和大促稳定性保障的强烈需求推动我们自身服务架构的升级。我们通过引入 Scrum 的敏捷开发模式，项目中的每个人都是猪（敏捷开发中，猪为项目负责人，鸡只是普通参与者，寓意来自猪要牺牲才能提供食物而鸡只要下个蛋就行了），每个人都要为服务框架升级和项目进展负责。

我们先后有十人以上共同推进了服务框架负载均衡、降级限流、连接切换优化等基础框架演进，以及监控、服务端超时控制、多版本、分组隔离、动态路由等服务治理体系完善。

总结一下：高效推进上，我们的经验是首先要采用项目的方式进行管理，再一个是时机不同、阶段不同，选择的项目工程方法也不一样：

• 新架构探索：建议采用传统的瀑布式和迭代式开发；
• 架构的持续迭代：可以尝试一些新的开发方法。

InfoQ：能否介绍蘑菇街系统架构的中间件系统？蘑菇街的一系列中间件是如何实现 Web 应用层和基础设施层对接的，各中间件如何确保在全站稳定落地？

七公：蘑菇街购买链路服务架构示意图：

从蘑菇街购买链路服务架构 1.0 到 1.5，我们完成了服务化框架 Tesla、分库分表 TSharding、分布式缓存 MoguCache、Corgi MQ、配置中心 Metabase、调用链跟踪 Lurker 等一系列重要中间件的自研、完善和在全站落地。这一系列中间件的研发，是随着业务系统和服务框架的不断发展（最早我们只有 Tesla 一个中间件）而逐步衍生出来的。

2015 年初，蘑菇街全网还在 PHP 体系，Tesla 框架诞生后，我们先构建了用户、商品、交易、促销等一系列的电商基础服务中心：

1. Tesla 框架支撑了 PHP Web 应用到服务中心的 PRC 调用场景；
2. 服务中心内部有数据容量提升需求，所以先后有了 TSharding 和 Raptor 分库分表中间件；
3. 服务内部有异步化处理需求，有了 Corgi MQ；
4. 服务中心内部有分布式缓存需求，所以有了 MoguCache 等；

所以服务框架是支撑和推动整个网站架构发展的核心和源动力。2015 年底我们启动了 PHP Web 单体应用拆分为一个个 Java Web 业务应用和前后端分离项目，很快购买链路完成了 PHP 体系到 Java 生态的彻底升级。

Tesla 走向真正的服务框架（而不仅仅是一个 RPC 框架）是随着业务的不断发展和业务系统的强烈要求开始的。最早业务系统面临服务发布时不平滑（客户端几秒甚至数 10 秒后才拉到更新的 IP 列表）等问题，以及业务服务蓬勃发展时期强烈的服务治理需求，Tesla 不断进行服务框架的改造升级：

• 通过新的配置中心 Metabase 的诞生和客户端拉取配置优化、客户端响应服务端连接关闭事件解决连接优化问题；
• 通过对监控预警、动态限流、服务端超时、服务分组等的支持完善了服务治理体系。

实际上业界的众多服务框架也是这么一步步发展起来的，没有捷径。

中间件在全站的有效落地，是靠中间件团队和业务系统支撑团队密切配合完成的。新的中间件刚刚开发出来，肯定会有各种问题出现，但是中间件也是业务系统的实际需求推动才产生的，所以双方的目标、利益点是相同的。我们会采用项目的方式，每个项目成员都对中间件的使用推广和自身完善负责，共同推动中间件在全站的稳定落地。

InfoQ： 在中间件研发过程中，开源技术起到怎样的作用？

七公：蘑菇街是拥抱开源技术的。在我们的技术体系中，很大一部分基础技术组件依赖于开源产品。我们的 Tesla 服务框架是基于 Netty 开发的，最早我们用的 MQ 是 RabbitMQ，后来我们才转向自研；我们的 Sentry 监控平台是基于 Grafana；目前我们仍然在广泛使用 Kafka 来收集全站日志，使用 Zookeeper 协调分布式系统，使用 Hadoop 生态来支撑数据平台计算任务等等。

而自研 Tesla、Corgi MQ 等等中间件的原因是因为这些是支撑我们网站发展的核心产品，我们必须要能够完全掌控、有能力做到深度定制，以便快速支持业务发展，而不是成为业务发展的瓶颈和阻碍；而这些中间件的诞生、持续发展和在全站落地之后，变成了我们技术团队乃至整个蘑菇街的核心竞争力之一。

针对纯技术的中间件 / 产品，我们会选择性的开源。TSharding 是我们最早的分库分表中间件，之前因为有小米、有赞等不少技术同仁都有咨询，所以我们开放在了 Github 上，见 https://github.com/baihui212/tsharding 。

InfoQ： 如何通过数据分析来指导“前瞻性地谋划实施、支撑业务快速发展”？在电商中哪些数据发生怎样的变化会给系统架构带来预警，提示需要改良或优化？能否结合谈谈你们的峰值系统的监控架构和方案？

七公：“前瞻性地谋划实施”可以通过关注业务数据和系统数据的增长变化情况来获得一个合理的度。通过当前业务的增速能推算出来三五年内的业务爆发和数据增长情况，如果有些架构上的不适宜（如过度中心化或存在易攻击点、系统难以扩展或者稳定性难以保障等问题），要尽早规划新的架构形态并快速推进实施，提早解除可能阻碍业务发展的绊脚石。但是也不能过度设计，考虑五年以后、十年以后的情况做设计，可能还未到时候，现有架构早就过时了。

电商数据比较复杂，概括如下：

• 业务数据
  目前我会关注 DAU，分平台的 GMV、UV、客单价、支付订单数、支付用户数等。
• 系统数据
  主要是容量和系统运行情况，容量包括数据库表空间、磁盘使用情况、服务应用的水位、缓存集群的分片情况等；系统运行状态主要包括 QPS、RT、调用成功率、CPU 占用率、内存使用、IO 等。

只要持续关注这些核心数据，才能敏锐地把控到系统接下来的发展趋势和改造方向。

蘑菇街大促峰值的监控分两部分：一部分是实时业务监控，播报实时 PV、UV、购买订单数、GMV、客单价的情况，这部分是通过实时计算平台的流式计算任务来完成的，延迟在秒级左右；另一部分是实时系统监控，我们是通过异步上报、LogAgent 收集、实时统计分析来保证 10s 左右的延迟就能把系统的实时统计指标呈现在可视化监控平台上。前者给业务方密切关注，后者则是我们做大促保障指挥决策、预案执行的哨兵和自动化告警的主要手段。

InfoQ：目前蘑菇街的架构是否已经达到了“该优化的已经优化了”的阶段？您将在 ArchSummit 的分享中提到“25 倍”的优化路径，在您的猜想下，25 倍是否是优化的极限，您认为短期未来还可以达到多少，如何做到？

七公：蘑菇街业务每年都保持 3 倍多的迅猛增长，对技术的挑战一直非常大。2015 年我们主要完成了业务应用服务化建设 & 服务架构升级、基础中间件研发落地、前后端分离、稳定性平台建设 & 大促保障常态化等重大技术改造，为网站架构的进一步发展打下了很好的基础。

目前我们还面临诸多问题和挑战，比如前端组件化的建设和新业务的快速交付、蘑菇街 / 美丽说 / 淘世界整个集团各平台业务发展的快速支撑和系统化的稳定性保障 & 质量保障能力；JDK8、异步框架等技术在全站的落地；应用高性能的持续优化、虚拟化 & 私有云的持续建设等等，蘑菇街还远未到“该优化的已经优化了”的阶段。我们要做的就是把每行代码都写好、每件事情都做到位，让我们的系统变的越来越强大，同时用更少的人力和机器成本去支持更大体量的业务。

关于优化的极限问题，最终追求的极限不是倍数，是在机器数上。机器堆的多了，自然可以支撑更大的流量，但是我们目前在做的是用更少的机器，支持更多倍的流量。目前我们主要还是进一步提高虚级化占比的方式（已逼近上限）和单机能力提升（还大有可为）的方式来进行的。

InfoQ：为什么您认为“根据场景来选用性能优化方案，没有通用方案”，蘑菇街以前是否考虑过“通用方案”的设计？能否结合蘑菇街架构升级案例谈谈这个体会？

七公：性能优化有很多种手段：

• 硬件
  对硬件更新换代、提升硬件能力、调优硬件参数可以提升性能，横向扩展方面加机器也可以提升性能。
• 软件
  对数据库 /Web Server 等软件进行配置优化、对 CPU 执行效率做优化、对 IO 效率做优化、对程序 CPU 计算复杂度做优化等等都可以提升性能，甚至仅仅做业务化简也能得到很可观的 RT 的降低。

2015 年初蘑菇街面临非常大的性能问题，只能支撑 400 单左右每秒的交易创建，严重不满足业务超高速发展和大促迅猛流量的要求。我们在完成系统拆分 & 服务化 1.0 体系构建后，开始了购买链路的专项性能提升项目。这个项目过程中翻越了许多障碍、篱笆，比如 DB 单点写瓶颈是一直压在头上的一座大山。

我们通过自研分库分表组件 TSharding，完成分库分表，最终下单服务支持了写入的无限水平扩展，订单库容量提升到了千亿级规模；营销服务的 RT 不稳定，每轮压测，营销服务都能再进一步，然后遇到下一个问题；我们通过 SQL 优化、缓存 & 预处理、读写分离等手段，大促期间最终计价接口 RT 稳定在 7ms；异步处理非常有必要性，能大大降低服务响应 RT，然后我们通过自己的方式解决异步化后的分布式事务问题，等等。

我们优化的案例还有很多，优化的过程很类似：找到瓶颈点——优化——压测验证然后再循环。但是最优的方案往往都是针对该场景和问题定制的，不应该去追求通用方案，也不会有通用方案。

InfoQ：并没有很多技术人员能有处理海量服务的机会，在从事这方面的工作中您有什么特别的感悟或经验可以和大家分享吗？

七公：我的体会是：只有自己经历过、尝试过的，才能真正成为自己的。如果有意愿深入接触高并发高可用高可扩展服务架构，但是目前还没有机会的，建议尽早换到业务在快速发展的有大流量场景的互联网公司，给自己挑战自我的机会。

InfoQ：感谢七公老师接受我们的采访。期待您在 ArchSummit 全球架构师峰会上的分享。

感谢陈兴璐对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。