1. 2017双11： 交易系统TMF2.0技术揭秘

2. 交易平台在互联网分布式协作模式下遇到的挑战 • 需求如何能更快的得到响应？发布周期更快？  支撑全集团几十个事业部的所有交易类需求 • 平台是否能为新小业务提供快速支撑，准入门槛低？ • 平台是否足够开放，业务方能做到自助式扩展？ • 新需求是否已经在其他事业部有可复用资产？ • 需求的评估是否具有全链路视角？  整个电商体系涉及到7000+应用 • 业务需求的技术评估是否分析全面？技术方案的影响 范围是否评估到位？ • 业务的全链路稳定性保障、调用链路监控、强弱依赖 • 各业务方的需求发布，是否会相互产生影响？  每天几百个业务需求，500+个独立的发布变更 • 业务需求代码是否对平台有侵入，平台腐化？ • 高频率的需求发布，如何管控质量？ • 是否能按业务维度进行业务监控？故障分析？

3. TMF2.0 解决的关键问题 业务可视化 需求结构化支持 1.平台能力能否对外透出？ 能否基于透出的业务能力、已有的业务规则完成 2.业务的规则是否对外透出？ 需求结构化分解降低沟通成本？ 业务配置化 关键 业务测试一体化 1.能否在需求明确的情况下在线 问题 能否根据修改的代码进行自动化用例 配置业务、快速发布上线？ 筛选，自动化测试？ 2.是可视化的前提 业务监控 故障排查 能否精细化的以业务维度进行监控， 当业务故障发生时，能否快速的拿到故障快 而不仅仅只有交易大盘？ 照，还原故障现场，迅速定位问题原因？

4. 针对关键问题，TMF2.0的关键设计点  业务/平台分离插件化架构： 平台提供插件包注册机制，实现业务方插件包在运行期的注册。 业务代码只允许存在于插件包中，与平台代码严格分离。业务包的代码配置库也与平台的代 码库分离，通过二方包的方式，提供给容器加载。  统一业务身份： 平台需要能有按“业务身份”进行业务与业务之间逻辑隔离的能力，而不 是传统SPI架构不区分业务身份，简单过滤的方式。如何设计这个业务身份，也成为业务与 业务之间隔离架构的关键。  管理域与运行域分离： 业务逻辑不能依靠运行期动态计算，要能在静态期进行定义并可视 化呈现。业务定义中出现的规则叠加冲突，也在静态器进行冲突决策。在运行期，严格按照 静态器定义的业务规则、冲突决策策略执行。

5. 业务/平台分离 业务定制包与平台分离的架构：平台+解决方案+业务插件包 架构分层 业 务 定 制 层 Wudaokou Business Tmall Car Ali Com Business Ali Game Business Cuntao Business …… 业务定制 China Solution Realization Business Process Definition 解 决 方 案 层 Implementation & Extension Custom Domain Service Custom Domain Ability External Repository Dependency Custom Extension Points …… Inventory System Payment System …… Basic-Realization Default Domain Service Implementation Default Order Service 基 础 能 力 层 Promotion System 市场相关 业务实现 Default Inventory Service Trade Model Default Payment Service Default Ability Instance …… Default Order Ability Instance Trade Domain Default Inventory Ability Instance Default Payment Ability Instance …… Trade Bootstrap 可复用基础 业务实现 电商交易 规范

6. 统一业务身份 业务身份定义标准化 业务定义维度标准化 • 市场类型 垂直市场 投影 维度 人 场 货 渠道来源 基于电商本质 人、货、场 的维度抽象 业务身份定义标准化（垂直 + 水平） • • 电商链路按阶段划分，各阶段选取若干维度定义业务身份Schema。 身份证号 类比 330902199909123433 省市区 出生日期 顺序码

7. 统一业务身份 基于UIL的业务身份识别方案 总体设计原则 • Expression • 基于标准模型抽象，模型统一管理，跟具体系统无关 • 自定义语法，接近自然语言，易于理解，跟具体系统无关 Simple Expression Logical Expression 卖家 买家 订单 商品 类目 "商品" 包含商品标() "99074" and "卖家" 是天猫卖家() item.hasTag(99074) && seller.isBSeller()

8. 统一业务身份 按照业务身份维度，对业务配置、部署进行管理 推送 配置 平台 项目 环境 日常 环境 预发 环境 线上 环境 核心要素 配置隔离性 • 分环境推送：日常、预发、线上。 • 分机房隔离（欧洲/美国/国内）。 • 租户间隔离。 • 系统间隔离。 • 版本间隔离。 热部署 • 基于Diamond消息通知机 制，测试环境实时生效。 • 线上环境考虑安全问题， 强制要求重启生效。 配置回滚 • 配置版本管理。 配置确定性 • 线上推送的配置跟预发 必须一致，所发即所测。 • 配置写本地磁盘。 • 记录推送快照。

9. 管理域/运行域分离 业务管理域与运行域分离的框架，按业务视角进行全链路管理 五道口 业务 管理域 模型管理 配置管理 发布管理 配置模板管理 基础数据模型 生命周期 定义 业务身份 定义 业务对象 定义 业务场景 定义 能力域模型 基 础 服 务 运行域 模板类型 变更管理 配置视图 业务应用 管理 域模型 服务模型 业务流程 配置 业务私有 对象配置 能力模型 扩展点模 型 业务使用 产品管理 功能点& 冲突配置 插件管理 异常管理 事件管理 阿里健 康应用 极有家 应用 五道口 应用 环境管理 配置下发 业务定义 业务空间 管理 业 务 系 统 采集管理 村淘 应用 天猫国 际 阿里旅 行 OPEN SDK 业 务 平 台 交易平台 招商平台 商品管理 导购平台 会员平台 结算平台 售后管理 评价平台 采集任务管 理 模型更新规 则管理 …… 规则引擎 能 力 域 中 间 件 订单域 限购域 安全域 支付域 结算域 超时域 价格域 交付域 库存域 优惠域 售后域 资产域 TDDL …… HSF NOTIFY DIAMOND

10. 管理域/运行域分离 基于业务协议标准定义业务，执行单元按协议执行业务逻辑 核心三要素 • • 业务身份、业务叠加关系、冲突决策 • 基于执行流程串接业务执行过程 业务 定义 身份 业务 叠加 关系 冲突 执行流程 规范电商业务定义协议，基于这个协议进行业务规则定义。各执行单元按统一业务定义协议解释执行（TMF2.0提供协 议定义以及运行框架）

11. 管理域/运行域分离 业务的复杂度在于业务规则在不同维度的叠加与冲突 垂直维度，也可称之为“行业”。往往一个特定的“业务对象”（如商品），在静态期就能确认其 具体归属于哪个行业。行业与行业之间的业务规则是不会有叠加的。比如，付款超时时间，各可以 都设置为1天超时。 但“天猫汽车”把超时时间改了，一定不会联动改其他业务的超时设置 天猫生鲜 横向维度（也称产品） 特点有： 1）产品是可以被多 个垂直业务所使用的 天猫汽车 盒马新零售 航旅 ……. 聚划算 2） 一个垂直业务是 可以使用多个产品的 3）产品是否生效是 需要结合业务会话的 上下文的 比如，“电子凭证” 是否生效，要看用户 是否选择了“电子凭 证”的交付方式。 导购宝 电子凭证 一次业务会话完整的规则 = 1个垂直业务规则集合 + N个水平业务规则集

12. TMF 2.0的关键模型介绍 业 务 配 置 主 线 浏览各域可 配置功能点 配置各域的 功能点 业 务 运 行 主 线 保存、下发 配置数据 业务PD 配置模型 能力域模型 域服务 关 键 模 型 * 域 视图 * * * 业务对象 * 指令 * 产品模板 规则 1 表达式 业务配置 信息 业务模板 * * 扩展点 配置数据 模板 域能力 用户一次下 单过程 1 指令 * * 模板配置 数据 业务流程 编排数据 * 冲突优先 级配置

13. 管理域/运行域分离 业务定义可视、可管、可配  业务定义可视化： 包括系统能力可视化、业务流程可视化、 1、按业务空间进行业务管理 业务规则可视化、产品叠加可视化等 2、浏览业务流程图  业务可配置： 所见即所得的业务规则可配置能力。凡是基 于TMF2标准构建的系统，均立刻可获取业务可配置能力， 不需要做额外的开发。  3、业务规则进行配置 配置版本化： 业务配置也属于代码的一部分，针对业务配 置有完善的版本化管理机制，配置推送可实现按版本快速  生效或者回退。 4、业务叠加产品管理 业务多租户管理： 不同的业务系统之间，是可以通过租户 5、业务规则冲突优先级配置 完全隔离的。不同的租户有自己的数据空间，以及配置推 送策略。

14. 基于TMF2.0，交易平台改造效果 目标    业务方开发业务需求时，不需要修改平  • 汽车4S服务：在老系统上做了一个月（未完成），新系统7天完成 业务需求的发布不依赖于平台的发布节 • 五道口业务：在老系统中评估工作量两个月，新系统12个工作日完成 奏，业务与平台的发布节奏解耦 • 饿了么业务：老系统评估要两周，基于新系统2天完成 各业务隔离后，不对其他业务产生影响，  从架构层提供能力：可按行业进行业 务资产包的积累，形成组织过程资产  平台与业务解耦 • 目前已完成的业务，其业务定制均只存在于业务包 • 在平台未改动情况下，业务方的发布更加灵活（有多次单业务发布，不 需要其他业务方进行回归的案例） 业务需求从提出到上线平均周期缩短 至一半  业务需求平均开发周期缩短至12天 台代码，使用平台暴露的可扩展点 只需要针对修改的业务进行测试  达成情况 后续业务方参与平台“共建”，聚焦 在 “场景”级的共性业务资产积累  业务资产库 • 积累形成了50+业务资产库，新业务可快速参考类似的业务进行快速复 制、调整并发布

15. Thanks