大促当前，如何做一场美丽联合的架构融合

2016 年 6 月，美丽说、蘑菇街、淘世界合并数月后正式宣布新集团为美丽联合集团，各技术团队在技术栈、多机房架构、中间件、电商底层系统模型等方面差异巨大，然而美丽联合集团在短短数月内完成了融合统一，相信不少技术人会对背后的融合思路和实践过程感到好奇。

2016 年 12 月 2 日 -3 日， ArchSummit 全球架构师峰会将在北京国际会议中心举行。本次大会设置了《电商专题：系统架构如何应对业务爆发式增长》和《阿里双11 技术架构突破》专题来深入解读双11 等大促背后的技术故事，其中邀请了美丽联合集团交易团队负责人乐多老师前来分享《美丽联合集团电商平台融合之路》，我们借此机会采访了乐多老师，他为我们带来有关平台融合和应对大促的思考，希望可以为大家带来启发，如果读者想了解更多美丽联合集团融合背后的架构演进，欢迎报名参加ArchSummit 北京站并与乐多老师进一步交流。

受访嘉宾介绍：

乐多，原名范宏杰，美丽联合集团交易团队负责人，13 年加入蘑菇街，经历了蘑菇街从社交到电商转变的全过程，负责交易团队管理以及架构工作，带领团队完成交易系统的服务化以及平台建设工作。

InfoQ：能否介绍曾经带领的 CPS 广告团队和现在的交易团队？这两支技术团队的技术栈有什么不同？身为负责人，能否谈谈在两次带领中您自己有没有什么不一样的地方和成长？

乐多：先简单介绍这两个团队：

• CPS 团队主要是利用 CPS 模式与外部站点进行合作，从而为商家以及平台带来更多流量，团队主要职责是快速接入各类外部站点，业务完全是从零起步，因此对于团队的要求就是快。正常需要 2 天接入的，尽量 1 天内接完；
• 交易系统的职责是提供买卖家一个完成钱货交换的平台，是业务结果的重要体现，技术团队不仅要支持业务需求，还要完成交易平台建设与稳定性保障工作，两者都是同等重要的。

技术栈方面：CPS 团队要求的面更广一些，不仅要掌握后端开发技术外，对于前端技术也要有一定了解；交易团队则主要使用后端开发相关技术，如 Java、数据库、消息队列、缓存等，对于技术的深度要求更高一些。

团队目标上：CPS 团队目标很明确，就是引流带来的 GMV 数量；交易团队的目标会更全面，例如业务支持快，系统运行稳等方面。两者的差异也是业务系统与基础平台的区别，业务与技术的权重会有些不同。

对我个人而来，随着业务的快速发展，成长也是非常快的。在 CPS 团队时，我有一个比较大的转变：每天开始都会分析业务数据，比如 DAU、GMV、佣金等。随着分析手段的完善，绝大多数业务需求或技术改造对业务结果产生的影响我都很清楚，这对我在团队的规划以及决策上有非常大的帮助。

交易团队负责的业务领域比较广，收到的业务需求也很多，我发现平台沉淀下来的东西不多，之后我开始梳理平台遇到的问题，思考问题的解决方案，并形成接下来的几个阶段的规划，经过几轮后，发现交易平台沉淀下来的东西多起来了。

InfoQ：您谈到蘑菇街、美丽说双方都希望两个平台技术体系能够快速完成合并，目前的融合进度如何？融合阶段出现系统问题的概率是否会上升？

乐多：我们大概 4 月开始讨论方案，4 月中旬启动融合项目，618 大促时 90% 以上的流量都已经运行在融合后的平台上，剩下老版本以及一些小流量的入口还在原有系统上运行，之后的老版本切换，我们也花了一点时间，当时对于用户体验考虑比较多，大概 9 月份就完全融合完毕了。

整个切换过程都是要求平滑切换，任何一个阶段都可以回退到上一个阶段，但 APP 发版之后就无法回退了，这要求我们在 APP 灰度之前，高质量完成底层数据融合，这个是对所有子系统的要求。

融合后系统保障上，我们基本还是沿用原有的保障方法，对于美丽说、蘑菇街两个平台，我们主要做了流量隔离，两边业务做到互不影响，服务的熔断与限流，我们还是保持原来的方式，数据存储这块目前是整合在一起，考虑到数据存储这块出现问题概率不大，而且我们在存储的扩容与快速恢复上做了很多事，因此数据存储的隔离暂时就不考虑了。

InfoQ：底层的基础设施放在一起才有机会做得更强更完善，能否解释“底层基础设施”的边界？

乐多：这个问题挺好的，团队同学平时也有边界的讨论，这部分系统到底是属于“底层”还是“上层”呢？我们先来看下目前我们整体的分层架构：

从图上可以看出目前我们的系统都已经分层了，有基础技术、服务中心、业务平台以及更为上层的前端应用，最终以一个用户产品的形态展现出来。

对于服务中心和基础技术，这两部分是全公司的数据基础与技术基础，这两部分一定需要整合到一起。

对于更上层的业务平台，如果是各业务分开建设，我们会创造许许多多为各个业务定制的系统出来，通过对模型、流程的抽象，沉淀为业务平台，而各个特定的业务流程、业务规则都可以在业务平台上完成定制，这样是一个更好的方案。对于前端部分也是一样的，通用组件也需要下沉，比如时间组件等。

按照目前的系统分层来说，我认为基础技术、服务中心、业务平台以及前端组件都属于“底层基础设施”。架构不断演进过程中会有新的系统产生，所有的“重复建设”都需要被整合到一起。

InfoQ：融合的主要任务是什么？例如业务、数据库等具体是如何实现融合的？能否谈谈从中遇到最大的问题？

乐多：系统融合涉及到的系统比较多，按照业务领域划分可以划为用户、商品、交易、商家、促销等；按照系统分层可以分为底层数据以及上层业务；这样两个维度一叠加，整体项目就非常庞大了；

对于数据模型的融合，我们总结出了一些通用的数据迁移方法：

1. 通过异步的方式进行数据同步，利用最终一致性保障数据不丢失；
2. 明确数据流向，防止数据冲突；
3. 更关注数据模型变化，少纠结在业务逻辑上，降低复杂度；

整个数据同步过程，我们需要保障够准、够快、够稳。

对于上层业务融合，我们梳理对比蘑菇街和美丽说的电商业务，并做了以下分类：

1. 平台现有的业务功能，这个最简单，通过设置不同业务不同规则就可以实现；
2. 有类似业务功能，但是有些功能点不同，需要与业务沟通，通过节点的功能扩展来支持，比如特殊的限购逻辑；
3. 有类似业务功能，但是实现方案差别大，建议业务上采用相同方案，减少重复建设，比如预售的流程；
4. 没有类似业务功能，且业务上非常重要，这类工作量最大，需要新增一个业务功能，比如美丽说虚拟币；

对于不同的业务功能的支持，是对电商平台化程度的考验，我们介绍几个打造平台的思路：

1. 业务元数据定义，做好业务识别；
2. 抽象业务需求，通过规则来完成业务需求；
3. 定义功能扩展点，通过扩展节点来完成业务的支持；
4. 对业务模型抽象，使业务模型可扩展；

另外，对于工作量大且优先级低的业务需求，我们通过临时下线来处理的，让我们把时间放在优先级更高的业务功能融合上面；

整个方案里，最困难部分就是在线数据切换了，切换后直接会改变数据的写入流向，一不小心底层数据就可能会有冲突，对于这类切换操作，我们要求平滑且可回滚，切换当天还是非常曲折，这是一段非常难忘的回忆；

InfoQ：在融合的过程中，蘑菇街和美丽说双方的如何快速统一意见、减少矛盾的，意见统一后双方进行了怎样的分工和磨合？融合完毕后，未来如何把控各方不会脱离同一条主线？

乐多：意见统一这点非常重要，这件事需要双方的努力。对于遇到的问题大家都很清楚，整个过程中，大家都是以“简单开放”的心态来解决我们遇到的问题，一起沟通后，脱离主线的问题很自然就解决了。

至于如何分工，这个项目我们必须要在 618 大促前基本解决，我们分工方式还是按照大家原来负责的工作来划分，这样做比较高效，另外因为我们去北京支持的人数毕竟有限，北京这边也会有其他业线研发同学进来支持，业务未来发展更多要看业务的决定，技术体系肯定是统一的。

InfoQ：除融合外，美丽联合集团也实现了平台化，能否简述服务化过渡到平台化的架构体系演进过程？

乐多：服务化后，我们建立了多个服务中心，如用户中心，商品中心，交易中心等，我们明确了业务模型，并提供了相关的服务接口，而更上层的“综合服务”主要用来支撑业务，为了更好支撑业务，我们把“综合服务”改造成“业务平台”，从业务的模型、规则、功能点、流程四个方面进行支撑，更好更快支持业务的发展。

交易系统在服务化到平台化过程中，我们主要经历了以下两个阶段：

1. 第一阶段，业务应用独立，根据业务领域模型不同，我们把“综合服务”抽取为独立的应用，比如商品详情、交易下单等，完成独立应用业务模型的建立，系统功能方面完成了前后端分离，独立应用不再承担“业务表达”的功能；
2. 第二阶段，建立规则引擎、流程引擎、SPI 框架三大基础技术，可以方便各个业务平台的规则定制、功能点扩展以及流程定制。

目前，业务识别的规则不统一，导致定制的规则和流程标准不统一，后续我们会在平台规则的标准化以及能力的可视化做出一些事情，不仅是对内能力的透出，对其他中小公司提供电商服务也会是一个方向。

InfoQ：针对历届大促，交易系统出现过哪些问题和经受了哪些考验？针对大促今年做了哪些准备以及有什么创新点？

乐多：加入蘑菇街后，我一直在做电商相关的事情，参与了蘑菇街转型后所有的大促，问题与挑战并存，我说说遇到过的问题以及解决方案：

1. 系统容量，在 2013、2014 年的几次大促中，交易链路上订单数据写入的容量一直是我们比较担心的，同时业务发展又很快，大促的写入量又是平时的几十倍，在单库上我们做过很多优化后，已经达到单库写入瓶颈，后面我们通过分库分表的方式，让订单表具备水平扩展的能力，目前下单写入容量在上万单每秒；
2. 系统限流，不管系统容量如何，限流是必不可少的，我们之前采用 QPS 限流，经过压测发现极端情况，也会出现系统雪崩的情况。目前我们采用并发 + QPS 双重限流的方式，对系统保护效果更好。

美丽说 & 蘑菇街系统融合后，对于稳定性保障手段调整并不多，我们按照平台与渠道做了标准化的划分后，我们的监控数据也自然做到了按照不同平台区分，压测方面主要在压测模型中加入匹配美丽说业务的压测数据。

今年，我们主要基于系统架构与上层要求的变化，以及之前保障过程中的问题做了一些改进：

1. 容量方面与往年不同，重要的容量提升工作，我们都在 Q4 之前全部完成，比如商品分库分表、交易数据库扩容。大促保障时，会更关注于限流、降级、熔断等保障工作，并通过全链路压测验证的工作；
2. 监控方面，监控系统经过了几轮的优化，系统变得更加稳定。业务监控数据上报，我们开发了一个打点工具，并制定了一些打点的标准，让交易链路打点更加自动化以及标准化；
3. 流量隔离上，我们做了“服务分组”，根据调用方不同提供不同的分组，来达到流量隔离的目的；
4. 降级策略上，由于美丽说的融合，要求我们在保障上做得更加精细，可以根据不同业务，设定降级开关，对于有些比较明确的降级方案，我们可以有自动降级的策略。

从上面也可以看到，两个平台融合后我们做得更加专业和更加高效。最后，我想说一下“所有保障工作都在平时”。

InfoQ：技术整合看似可遇不可求，市场上却屡屡发生合并热潮，您认为在主导技术体系合并时，如何通盘考虑或应具备怎样的能力才能防止当初做了错误的技术选型？

乐多：这个说法我要纠正下，技术整合与技术选型的是否正确没有直接关系，相同功能或职责的系统都可能被合并。对于核心系统的技术选型，我会考虑以下几点：

1. 人才储备，选择大家最擅长的；
2. 团队的积累，已经沉淀下来的技术直接拿来使用；
3. 社区活跃度，遇到复杂问题可以在社区寻求帮助，当然也需要回报社区；
4. 行业标杆，对于行业内已经成熟的技术选型方案，会优先采用；

另外，对于一些影响范围较小的系统，我们也鼓励尝试一些新的技术。

最后说下，技术选型没有最好，只有最合适，要在过程中根据研发效率与维护成本的情况来优化。

InfoQ：感谢乐多老师接受我们的采访，期待您在 ArchSummit 全球架构师峰会分享的《美丽联合集团电商平台融合之路》。

感谢冬雨对本文的审校。

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