如何寻找边界，美丽联合集团架构融合之路

架构师 架构 乐多 美丽联合集团 ArchSummit

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

2016年12月2日-3日，ArchSummit全球架构师峰会将在北京举行。本届大会组委会邀请了美丽联合集团交易团队负责人乐多老师前来分享《美联集团电商平台融合之路》，我们借此机会采访了乐多老师，他为我们带来有关平台融合和应对大促的思路，希望可以为大家带来启发，如果读者想了解更多美丽联合集团融合背后的架构演进，欢迎报名参加ArchSummit北京站并与乐多老师进一步交流。

受访嘉宾介绍：

乐多，原名范宏杰，美丽联合集团交易团队负责人。2013年加入蘑菇街，经历了蘑菇街从社交到电商转变的全过程，完成交易、支付系统搭建，之后负责CPS广告团队，2014年7月负责交易团队，带领团队完成交易系统的服务化以及平台建设工作。

在CPS广告团队和交易团队的成长

先简单介绍这两个团队：

• CPS团队主要是利用CPS模式与外部站点进行合作，从而为商家以及平台带来更多流量，团队主要职责是快速接入各类外部站点，业务完全是从零起步，因此对于团队的要求就是快。正常需要2天接入的，尽量1天内接完；

• 交易系统的职责是提供买卖家一个完成钱货交换的平台，是业务结果的重要体现，技术团队不仅要支持业务需求，还要完成交易平台建设与稳定性保障工作，两者都是同等重要的。

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

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

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

交易团队负责的业务领域比较广，每周收到的业务需求量是很多的，因此业务支持、系统保障、效率提升都是我必须要考虑的问题。把一些想法以及方案梳理清楚后，我们会形成交易平台接下来的几个季度规划，甚至更长期的规划。这些事情有些在日常需求支持时随带做掉，有些会单独立项来做，经过几轮后，发现交易平台沉淀下来的东西多起来了。

寻找底层基础设施的边界

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

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

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

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

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

融合时间表以及系统保障思路

我们大概4月中旬启动了融合项目，618大促时90%以上的流量都已经运行在融合后的平台上，剩下老版本以及一些小流量入口，为了保障用户的体验，在老版本切换过程我们也花了一点时间，大概9月份就完全融合完毕了。

整个切换过程都是平滑切换，任何一个阶段都可以回退到上一个阶段，APP发版这个回退不了，这个是对所有子系统所有的要求，对于最复杂最容易出问题的数据切换环节，我们也做了多次在线演练，整体上还是比较顺利的。

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

未来各方会不会脱离同一条主线

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

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

交易系统平台化进程

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

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

1. 第一阶段，业务应用独立，根据业务领域模型不同，我们把“综合服务”抽取为独立的应用，比如商品详情、交易下单等，完成独立应用业务模型的建立，系统功能方面完成了前后端分离，独立应用不再承担“业务表达”的功能；

2. 第二阶段，建立规则引擎、流程引擎、SPI框架三大基础技术，可以方便各个业务平台的规则定制、功能点扩展以及流程定制。

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

进化的美丽联合集团大促手段

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

1. 系统容量，在2013、2014年的几次大促中，交易链路上订单数据写入的容量一直是我们比较担心的，同时业务发展又很快，大促的写入量又是平时的几十倍，在单库上我们做过很多优化后，已经达到单库写入瓶颈，后面我们通过分库分表的方式，让订单表具备水平扩展的能力，目前下单写入容量在上万单每秒；

2. 系统限流，不管系统容量如何，限流是必不可少的，我们之前采用QPS限流，经过压测发现极端情况，也会出现系统雪崩的情况。目前我们采用并发 + QPS双重限流的方式，对系统保护效果更好。

大的保障手段还是那些，并且与融合相关方案的调整并不多，我们按照平台与渠道做了标准化的划分后，我们的监控数据也自然做到了按照不同平台区分。压测方面主要在压测模型中加入匹配美丽说业务的压测数据。

今天我们主要基于系统架构的变化与之前保障过程中的问题做了一些改进：

1. 容量方面与往年不同，今年重要的容量提升工作，我们会在Q4之前全部完成，比如商品分库分表、交易数据库扩容。大促保障时，会更关注于限流降级以及通过压测验证的工作；

2. 监控方面，监控系统也经过了几轮的优化，系统变得更加稳定。业务监控打点上，我们提供了一个打点工具，让打点更加自动化以及标准化；

3. 流量隔离上，我们做了“服务分组”，根据调用方不同提供不同的分组，来达到流量隔离的目的；

4. 降级策略上，由于美丽说的融合，要求我们在保障上做得更加精细，对于有些比较明确的降级方案，我们可以有自动降低的策略。

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

合并热潮下，技术选型是否正确

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

1. 人才储备，选择大家最擅长的；

2. 团队的积累，已经沉淀下来的技术直接拿来使用；

3. 社区活跃度，遇到复杂问题可以在社区寻求帮助，当然也需要回报社区；

4. 行业标杆，对于行业内已经成熟的技术选型方案，会比较复用的成本；

5. 另外，对于一些影响没那么大的系统，也可以尝试使用一些新的技术。

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

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