跳开 DDD 和中台概念看阿里巴巴交易平台的问题及解决思路

| 本文出处：https://yq.aliyun.com/articles/511876

作者Ryu Xin，原文标题《如何实现32.5万笔/秒的交易峰值？阿里交易系统TMF2.0技术揭秘》，技术琐话受权转载。

总体介绍

2017年双11，交易峰值达到了32.5万笔/秒，这给整个交易系统带来了非常大的挑战。一方面，系统需要支撑全集团几十个事业部的所有交易类需求：要考虑如何能更快响应需求、加快发布周期；如何能为新小业务提供快速支撑、降低准入门槛；是否足够开放使得业务方能做到自助式扩展；新需求是否已经在其他事业部有可复用资产等问题。

互联网的特点决定了业务系统是按领域服务建设的分布式架构。而电商业务的特点是业务生命周期长，从招商、选品、供应链、仓储、营销/导购、下单、履约、物流、售后等，其业务链路长、业务逻辑上游对下游又有影响。在这业务主线的链路上，又建设了众多系统进行支撑，比如商品平台、购物车系统、下单系统、履约系统、优惠系统、物流系统、供应链系统等，围绕这些核心系统，还有数不清的辅助系统/服务，比如服务平台、天猫SMC、淘宝CPC等等。

在每一次的业务需求分析过程中，又是需要能从业务生命周期的全链路视角进行需求分析、技术方案评估、编码、联调以及发布。这整个过程，也是一次复杂的跨团队协助过程，痛点主要体现在：

1）缺少全链路视角的需求管理机制，协同效率低 

2）平台准入门槛高，新小业务无法快速试错 

3）业务与平台没有很好分离，无法支撑业务自助式（Self-Service）发展 

4）缺少可复用业务资产。

痛点一： 缺少业务全链路视角的需求管理机制，协同效率低

对业务需求的跟踪与管理缺少全业务链路视角，主要体现在：

需求的描述往往就是一句话。详细的需求描述基本都是靠后期的一些文档、邮件以及组织需求澄清会的形式进行讲解。在讲解时，会尽可能拉上能想得到的可能会相关的平台开发同学，场面蔚为壮观。

需求传递低效，需要反复沟通。业务需求在建模与分解过程中，缺少有效传递载体和形式，不能准确无缝传递到开发，导致反复沟通澄清与需求返工以及重复工作量。

平台能力缺少透出，技术方案评估花费时间长。技术同学在评估需求实现对平台的改动点时，由于平台能力缺少透出，业务与平台代码没有分离，导致技术方案评估时，很难一下评估出针对新续期，现有平台有什么能力可以服用？改动对现有哪些业务会有影响？对相关的周边哪些系统有影响？工作量有多少？ 这些基本都需要事后去反复翻代码分析评估。

类似需求重复建设。 需求发布上线后，随着时间的推移，人员的更换。就没有人知道这个需求当时是如何实现的？遇到类似需求的方案评估，又只能翻代码，或者重复实现一次。

痛点二：平台准入门槛高，新小业务无法快速试错

新小业务都有一个成长规律，在早期业务模式验证阶段，需要的玩法比较简单，希望能频繁的发布快速试错。但共享的交易平台、商品平台、营销平台等虽然能支持各种业务模式与营销玩法。但对于新小业务而言，这些在早期并不适用，他们希望平台能灵活裁剪，比如：

1）下单流程是否能裁剪成极简流程，而不是必须走完整流程 

2）与其他业务代码在运行期分离，不希望对其他业务或者被其他业务所影响 

3）业务发布节奏可以自行控制，不希望等待每周一次的全网回归

痛点三：业务与平台没有很好分离，无法支撑业务自助式（Self-Service）发展

阿里电商业务五花八门，各部门的定位也不一样，有的定位于是面向“垂直”行业的，比如天猫汽车业务、盒马生鲜业务、航旅业务等；而有的又是定位于面向对所有行业支撑的平台业务，如聚划算、导购宝等。 所以，业务本身会分成“垂直”和“水平”两个维度。在一次业务交互过程中，其业务复杂度就在于业务“垂直”维度与“水平”维度产生的叠加，并由叠加而产生的业务规则上的冲突。

针对业务叠加的处理，各系统基本上还是基于SPI扩展机制，这些SPI缺少按照业务维度进行组织与隔离。在业务种类少，不同业务在逻辑叠加度小的情况下还是可以在很大程度上解决业务可定制化、多样化的问题。但随着各类业务越来越多时，就会导致各类业务在同一个扩展点上的叠加效应越来越突出。其中最薄弱的点就是 SPI接口中是否需要执行的过滤方法（filter）的编写。一旦过滤方法写得不好，就可能会造成不该执行的逻辑被执行了，或者把后续本该执行的逻辑给跳过了。

在共享的各个平台中，提供给业务方可扩展的SPI多达几百个。一个业务的最终逻辑是否正确，就需要该业务确保这几百个SPI决策树中每个节点注册的位置正确，过滤方法中的过滤条件正确，同时执行逻辑也必须确。不仅如此，本业务注册的SPI都正确了，还需要其他的业务注册的SPI也都是正确的，这最终导致了业务与业务之间高度耦合。这种耦合，又进一步导致了各业务方之间、业务方与平台之间的大量联调、集成与回归等配合工作，无法做到自助式的业务设计、开发与交付。

痛点四：缺少可复用业务资产

一个企业的IT体系建设是否成熟，业界是有一些指导框架来进行评估的，比如TOGAF框架。在该信息系统建设框架中，有一个很重要的系统成熟度评估项目 —— Enterprise Continumm（企业统一体）。

这里面的关键是企业需要建立：

架构统一体（Architecture Continuum）： 该统一体能从特定架构中提取出可复用的组件到仓库中（Reposity），为后续的类似业务的重用（Gerneralization for future re-use）。在具体应用中，可以从组件仓库中选择可复用的组件并进行与实际应用场景适配（Adaptation for use）。

解决方案统一体（Solutions Continuum）：与架构统一体类似，在面对不同的市场，需要能从可复用的解决方案库中选择并快速复制。对于新兴市场的交付，也能提取成可复用的解决方案到资产库中。

经过多年的发展，我们在淘宝、天猫国内市场中，我们 有各种各样的业务支撑工具与玩法，比如，电子凭证、预售、购物券、红包等等，在面对国际化市场交付时，是否能做到业务模式的快速复用？

解决这些问题的思路

整个电商体系涉及的应用高达7000+：要考虑需求的评估是否具有全链路视角；业务需求的技术评估是否分析全面、技术方案的影响范围是否评估到位；业务的全链路稳定性保障、调用链路监控、强弱依赖等问题。此外面对每天几百个业务需求，500+个独立的发布变更：要考虑各业务方的需求发布是否会相互产生影响；需求代码是否对平台有侵入、导致平台腐化；高频率的需求发布下如何管控质量；能否按业务维度进行业务监控、故障分析等等。

面对这些挑战，TMF2.0框架需要解决的六大关键问题：

业务全链路可视：业务分析人员和技术人员能基于同一套业务语言以全链路可视化方式进行需求讨论、影响分析以及技术方案评估，在业务视图上看到的规则就是实际在运行系统上运行的规则。在对大规模的业务交付支撑场景下，业务可视化对于效率提升是非常必要的。

需求结构化：基于透出的业务能力、已有的业务规则完成需求结构化分解降低沟通成本。

业务配置化：这是可视化的前提，要在需求明确的情况下在线配置业务、快速发布上线。

业务测试一体化：根据修改的代码进行自动化用例筛选、自动化测试。

业务监控：以精细化的业务维度进行监控，而不仅仅局限于交易大盘。

故障排查：当业务故障时快速拿到故障快照、还原故障现场以及迅速定位问题原因。

TMF2.0 关键设计思想

针对上面提到的问题，TMF2在架构设计上主要的思想是：

业务包与平台分离的插件化架构： 平台提供插件包注册机制，实现业务方插件包在运行期的注册。业务代码只允许存在于插件包中，与平台代码严格分离。业务包的代码配置库也与平台的代码库分离，通过二方包的方式，提供给容器加载。

全链路统一的业务身份： 平台需要能有按“业务身份”进行业务与业务之间逻辑隔离的能力，而不是传统SPI架构不区分业务身份，简单过滤的方式。如何设计这个业务身份，也成为业务间隔离架构的关键。

管理域与运行域分离： 业务逻辑不能依靠运行期动态计算，要能在静态期进行定义并可视化呈现。业务定义中出现的规则叠加冲突，也在静态器进行冲突决策。在运行期，严格按照静态器定义的业务规则、冲突决策策略执行。

业务包与平台分离的插件化架构

如上所示的业务定制包与平台分离架构可以分为三个层次。最底层是业务规范层，包括一些交易模型、交易领域的划分、业务领域的划分、以及交易启动环境下的配置项。基于这个理论模型，就可以进行一些定义及规范工作，比如接口定义、流程规范、模型规范等，而且其中的很多内容都可以在不同的领域进行复用。

业务规范层之上是解决方案层。大家都知道阿里巴巴目前正在走国际化的战略，所以面对不同的市场会构建不同的解决方案，不同的解决方案中也就有自己不同的业务玩法、业务逻辑。所以要将不同的市场解决方案和他们自身的流程、规则结合起来。但是这一过程中会发现，不同的市场解决方案会有很多可以复用的地方，比如营销模式。所以形成的可复用基础实现就可以在不同的解决方案中得到复用，所那么在面对不同的市场时就不用考虑可复用基础实现的内容，只需要关注市场相关的业务就可以了。

再往上一层是业务定制层。即使是在一个市场内，也会有各种细分的定制玩法，这些不同的细分点就会有各自不同的业务逻辑，这就是制定业务定制层的原因。团队会根据底层的需求点来进行一些业务定制包的组装，就可以实现不同的业务逻辑和玩法了。

在这样一个复杂的分离架构中，最重要的是要将不同层次间的职责划分清晰，整个代码都严格地、有意识地进行分离。所以在最后的部署过程中，首先要完成底层业务的复用，然后形成不同市场的解决方案，再在解决方案下对不同的业务实现差异化的点。

全链路统一的业务身份

上面所讲的是业务和平台的分离，在业务和平台分离之后就要进行业务和业务之间的隔离，即统一的业务身份，类似于身份证号码，在整个交易链路上必须是唯一的。业务身份需要通过人、货、场三个维度进行抽象，比如市场类型、垂直市场、渠道来源等等，确定了这个唯一的业务身份后就可以将业务流程和业务规则进行关联。

基于业务识别，团队也提供了一个基于UIL的业务身份识别方案，总体设计基于标准模型来抽象，自定义语法，统一管理模型。事实上，通过样品模型、买家模型、卖家模型、类目模型这四个维度，99%的商品都可以有效地进行标识。业务身份确定后，就可以按照业务身份维度，对业务配置、部署进行统一管理，在这其中要注意配置隔离性、热部署、配置回滚、配置确定性等核心要素。

业务管理域与运行域分离

业务身份确定后就要进行业务定义，这其中就涉及管理域和运行域分离的问题。管理域就是指对业务生命周期、业务身份、业务对象进行定义，包括业务流程、业务管理等。这些操作完成之后就会将配置文件下发到，运行域上的各种平台就会自动解析配置域所下发的配置文件，然后将配置文件解析成业务命令来执行。

在上面所讲的业务域中，一个核心的问题就是如何定义业务：核心三要素是业务身份、业务叠加关系、冲突决策，即基于业务协议标准定义业务，执行单元按协议执行业务逻辑。

在业务叠加关系中，业务的复杂度就在于业务规则在不同维度下产生的冲突。业务的复杂度可以分为两个维度，一个是横向维度，一个是垂直维度。

垂直维度，也可称之为“行业”。往往一个特定的“业务对象”（如商品），在静态期就能确认其具体归属于哪个行业。行业与行业之间的业务规则是不会有叠加的。比如，付款超时时间，各可以设置为1天超时。但“天猫汽车”把超时时间改了，一定不会联动改其他业务的超时设置。横向维度，也称为产品维度，特点有：产品是可以被多个垂直业务所使用的、一个垂直业务是可以使用多个产品的、产品是否生效是需要结合业务会话的。比如，“电子凭证”是否生效，要看用户是否选择了“电子凭证”的交付方式。

通过业务复杂度的分析，可以得出一个结论是：一次业务会话完整的规则=1个垂直业务规则集合+ N个水平业务规则集。所以在做业务定义和管理的时候，具体就是在管某一个垂直业务是和哪些横向业务在叠加。在叠加之后产生的业务冲突又是怎么解决的？要基于这一点进行业务管理。这是比较关键的一点。

TMF2.0 关键模型介绍

下面详细阐述一下TMF 2.0的关键模型，主要包括业务配置主线和业务运行主线。

在业务配置主线中，由项目的业务PD来看一下当前业务涉及到哪些业务域，以及这些业务域下面有哪些功能和产品可以去使用，哪些业务点是可以去扩展的。这其中就需要能力域模型的支撑，通过这个模型所透出的结构化数据，来研究平台中每个域具备的能力、每个能力具有的可变点，从而有针对性地进行设置。在配置模型里，通过关键的视图模板，进行模板透出，然后保存、下发配置数据到业务运行主线。业务配置主线和业务运行主线是相交互的。

基于TMF 2.0关键模型，整个交易平台实现了业务定义可视、可管、可配。业务定义可视化包括系统能力可视化、业务流程可视化、业务规则可视化、产品叠加可视化等；业务可配置，所见即所得的业务规则可配置能力，凡是基于TMF2标准构建的系统均立刻可获取业务可配置能力，不需做额外的开发；配置版本化，针对业务配置有完善的版本化管理机制，配置推送可实现按版本快速生效或者回退；业务多租户管理，不同的业务系统之间可以通过租户完全隔离的。不同的租户有自己的数据空间，以及配置推送策略。

面向业务维度的运维 & 稳定性保障

当业务与平台分离并且具有业务身份的识别后，我们就可以从业务维度进行可靠性保障，主要有：1）按业务维度进行故障监控 2）按业务维度分集群部署 3）按业务维度做稳定性保障 等。

1) 按业务维度进行故障监控

在过去没有做到业务身份识别时，每天的交易大盘监控还比较粗放，只能去从整体去监控交易量趋势。有些业务，特别是一些新小业务，其早期交易量非常小。即使因为故障交易跌零了，从交易大盘上也无法即使监控到，只有等到客户投诉了才发现有故障发生。

基于TMF2构建的业务系统，因为有“业务身份”的标示，我们就可以将业务身份标示贯穿整个接口调用链路以及写入日志中。并在各类监控大盘中，可以针对业务维度进行分组展现。

2) 按业务维度分集群部署

过去淘宝、天猫所有的交易，都是通过同一套BUY、TP进行下单并履约的。当某个业务有新需求或者故障解决等原因，要进行升级部署时，就不可避免的将所有机器都分批进行升级部署。每一次升级发布，都是一次变更行为，只要有变更就可能会产生新的故障。

基于TMF2构建的业务系统，因为有“业务身份”的识别。我们就可以根据业务身份做前置路由。给不同的业务身份分配不同的集群，并按集群去分别部署业务。从物理的隔离，在满足一些业务快速迭代发布的诉求下，还能保障业务的稳定性。

3) 按业务维度做稳定性保障

过去在没有业务身份的识别下，在做性能优化、大促保障时，是没法按业务维度用不同的QoS策略进行差异化的大促保障。比如，无法按照业务维度进行流量分配进行限流、无法按照业务维度建立性能基线并进行性能劣化监控等。业务平台目前正在做的天秤项目，与过去单纯监控物理指标不一样的地方，就是在于能按照业务进行场景化监控。例如：

可以按业务维度建立各业务在各个调用场景下的性能基线，如RT、QPS等，一旦某次发布和预设基线有重大差异，就能快速找到性能劣化的业务并进行改进

• 可以按业务维度建立外部服务调用的强弱依赖关系，结合强弱依赖关系可制定全局以及业务维度的各种预案开关。

• 可以按全局或者业务维度，构建全局调用链路监控大盘。

交易平台改造效果

业务需求平均开发周期缩短至12天: 比如汽车4S服务中，在老系统上做了一个月（未完成），新系统7天完成；五道口业务中，在老系统中评估工作量两个月，新系统12个工作日完成；饿了么业务中，老系统评估要两周，基于新系统2天完成。

平台与业务解耦: 目前已完成的业务，其业务定制均只存在于业务包；在平台未改动情况下，业务方的发布更加灵活（有多次单业务发布，不需要其他业务方进行回归的案例）。

业务资产库: 积累形成了50+业务资产库，新业务可快速进行快速复制、调整并发布。