2017双11交易系统TMF2.0技术揭秘，实现全链路管理

摘要： 本文是《2017双11交易系统TMF2.0技术揭秘》演讲整理，主要讲解了基于TMF2.0框架改造的交易平台，经过业务管理域与运行域分离、业务与业务的隔离架构，大幅度提升了业务在可扩展性、研发效率以及可维护性问题，同时以更好的开放模式，让业务方能自助进行无侵入的需求开发。

12月13-14日，由云栖社区与阿里巴巴技术协会共同主办的《2017阿里巴巴双11技术十二讲》顺利结束，集中为你们分享了2017双11背后的黑科技。本文是《2017双11交易系统TMF2.0技术揭秘》演讲整理，主要讲解了基于TMF2.0框架改造的交易平台，经过业务管理域与运行域分离、业务与业务的隔离架构，大幅度提升了业务在可扩展性、研发效率以及可维护性问题，同时以更好的开放模式，让业务方能自助进行无侵入的需求开发。内容以下。

阿里巴巴资深技术专家 毗卢

毗卢，阿里巴巴资深技术专家，主导设计了TMF2.0框架，并基于该框架完成交易平台架构升级改造，目前负责商品中心，专一电商领域业务建模与工程交付相结合的研究与平台推广。

交易平台遇到的挑战
在刚刚过去的2017双11，交易峰值达到了32.5万笔/秒，这给整个交易系统带来了很是大的挑战。一方面，系统须要支撑全集团几十个事业部的全部交易类需求：要考虑如何能更快响应需求、加快发布周期；如何能为新小业务提供快速支撑、下降准入门槛；是否足够开放使得业务方能作到自助式扩展；新需求是否已经在其余事业部有可复用资产等问题。另外一方面，整个电商体系涉及的应用高达7000+：要考虑需求的评估是否具备全链路视角；业务需求的技术评估是否分析全面、技术方案的影响范围是否评估到位；业务的全链路稳定性保障、调用链路监控、强弱依赖等问题。此外面对天天几百个业务需求，500+个独立的发布变动：要考虑各业务方的需求发布是否会相互产生影响；需求代码是否对平台有侵入、致使平台腐化；高频率的需求发布下如何管控质量；可否按业务维度进行业务监控、故障分析等等。

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

业务可视化：平台能力、业务规则决定是否对外透出；
需求结构化支持：基于透出的业务能力、已有的业务规则完成需求结构化分解下降沟通成本；
业务配置化：这是可视化的前提，要在需求明确的状况下在线配置业务、快速发布上线；
业务测试一体化：根据修改的代码进行自动化用例筛选、自动化测试；
业务监控：以精细化的业务维度进行监控，而不只仅局限于交易大盘；
故障排查：当业务故障时快速拿到故障快照、还原故障现场以及迅速定位问题缘由。
针对以上六大关键问题，TMF2.0的关键设计点有如下三个层面。

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

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

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

下文将针对这三块的内容分别展开来详细介绍。

业务定制包与平台分离的架构

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

上面一层是解决方案层。你们都知道阿里巴巴目前正在走国际化的战略，因此面对不一样的市场会构建不一样的解决方案，不一样的解决方案中也就有本身不一样的业务玩法、业务逻辑。因此要将不一样的市场解决方案和他们自身的流程、规则结合起来。可是这一过程当中会发现，不一样的市场解决方案会有不少能够复用的地方，好比营销模式。因此造成的可复用基础实现就能够在不一样的解决方案中获得复用，所那么在面对不一样的市场时就不用考虑可复用基础实现的内容，只须要关注市场相关的业务就能够了。

往上一层是业务定制层。即便是在一个市场内，也会有各类细分的定制玩法，这些不一样的细分点就会有各自不一样的业务逻辑，这就是制定业务定制层的缘由。团队会根据底层的需求点来进行一些业务定制包的组装，就能够实现不一样的业务逻辑和玩法了。

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

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

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

业务管理域与运行域分离的框架

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

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

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

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

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

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

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

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

在实际应用中，基于TMF2.0交易平台改造效果具体以下：

业务需求平均开发周期缩短至12天。好比汽车4S服务中，在老系统上作了一个月（未完成），新系统7天完成；五道口业务中，在老系统中评估工做量两个月，新系统12个工做日完成；饿了么业务中，老系统评估要两周，基于新系统2天完成。平台与业务解耦。目前已完成的业务，其业务定制均只存在于业务包；在平台未改动状况下，业务方的发布更加灵活（有屡次单业务发布，不须要其余业务方进行回归的案例）。业务资产库。积累造成了50+业务资产库，新业务可快速进行快速复制、调整并发布。