阿里妹导读:基于TMF 2.0关键模型,阿里交易平台实现了业务定义可视、可管、可配。今天我们来一起了解交易平台遇到的挑战、TMF2.0解决的关键问题、以及TMF 2.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+业务资产库,新业务可快速进行快速复制、调整并发布。

如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘相关推荐

  1. 3月6日云栖精选夜读:如何实现32.5万笔/秒的交易峰值?阿里交易系统TMF2.0技术揭秘...

    交易平台遇到的挑战 2017双11,交易峰值达到了32.5万笔/秒,这给整个交易系统带来了非常大的挑战. 一方面,系统需要支撑全集团几十个事业部的所有交易类需求:要考虑如何能更快响应需求.加快发布周期 ...

  2. 2017年的双十一又一次刷新了记录,交易创建峰值32.5万笔/秒、支付峰值25.6万笔/秒。而这样的交易和支付等记录,都会形成实时订单Feed数据流,汇入数据运营平台的主动服务系统中去。数据运营平台的

    2017年的双十一又一次刷新了记录,交易创建峰值32.5万笔/秒.支付峰值25.6万笔/秒.而这样的交易和支付等记录,都会形成实时订单Feed数据流,汇入数据运营平台的主动服务系统中去.数据运营平台的 ...

  3. 天猫双十一订单峰值58.3万笔/秒的背后,秘密都在这份文档里

    双十一终于落下帷幕,每年的双十一都是对各家企业系统的一次大考,今年天猫双十一的订单总和约等于2010年中国全年快递量的总和,达到22.5亿单. 11 月 11 日零点刚过 26 秒,天猫双十一订单峰值 ...

  4. 2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代

    摘要: 2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作.保证数据库的稳定性.快速发现问题是一个巨大的难题, 这也是数 ...

  5. 阿里云自研数据库支撑双11,助力电商客户订单峰值突破每秒20万笔

    简介:阿里云自研数据库产品家族全面支撑双11活动,帮助客户从容应对流量高峰. 记者采访获悉,日前阿里云自研云原生数据库PolarDB.云原生数据仓库AnalyticDB等数据库产品家族全面支撑双11活 ...

  6. 60秒链快讯 | 火牛视频投资团队信息涉嫌造假;EOS社区论坛称其日交易量接近100万笔

    [LINE宣布推出两项新的DApp服务] 据Coinpost消息,在由日经新闻和金融服务局联合举办的峰会"FINSUM"上,日本社交巨头Line宣布推出"44CAST&q ...

  7. TPC-C 中跑赢 Oracle 的 OceanBase,双 11 处理峰值达 6100 万次/秒!

    作者 | 晶少 责编 | 阿秃 出品 | CSDN云计算(ID:CSDNcloud) 就在一年一度震撼人心的双11前夕,有消息称前段时间火爆到瞬间刷屏的OceanBase已经完成了Oracle模式的研 ...

  8. 2020年中国水利工程设施发展概况分析: 已建成5级及以上江河堤防32.8万公里[图]

    水利设施对自然界的水进行控制.调节.开发.利用和保护,以减轻和免除水旱灾害,并利用水资源,适应人类社会和自然环境需要的设施. 一.堤防和水闸 截至2020年年底,全国已建成5级及以上江河堤防32.8万 ...

  9. 比特币现金压力测试结果:处理210万笔交易 费用不增反降

    根据BitInfoCharts最新披露的分析数据显示,比特币现金(BCH)网络已经启动了压力测试,并且在9月1日承受了高达210万笔交易. 根据BCH压力测试网站称,本次"压力测试" ...

最新文章

  1. qt调用c语言编写的dll文件,Qt之调用外部DLL - moki_oschina的个人空间 - OSCHINA - 中文开源技术交流社区...
  2. 【编译原理】关于解释器和编译器的讨论
  3. [EffectiveC++]item17:以独立语句将newed对象置入智能指针
  4. 通过ajax调用WebService服务
  5. 5.4. Interaction Between Devices and Kernel 设备与内核的交互
  6. 战痕————道具系统介绍
  7. 使用 C# 和 Blazor 进行全栈开发
  8. 什么是电视光端机?电视光端机是怎么分类的?
  9. 【51单片机快速入门指南】6.3:DS18B20 单总线数字温度计的多路读取
  10. 用js实现千位分隔符
  11. 实锤了?哪吒涉嫌抄袭起诉已立案:公布多张相似对比图
  12. python如何限制字符串长度_Python uuid4,如何限制唯一字符的长度 - python
  13. oracle的约束什么作用,Oracle数据库知识之约束
  14. cartographer 前端两个方法:相干性匹配与非线性优化;以及回环检测方法:利用了分枝定界的相干性匹配
  15. 【图像隐写】基于matlab GUI DCT数字水印嵌入+提取【含Matlab源码 1671期】
  16. 浅析融媒体的发展现状和未来前景
  17. jdk提供的用于并发编程的同步器有哪些
  18. php页面强制横屏,Css实现手机端页面强制横屏(仅适用与一屏页面)
  19. CentOS6.5下MariaDB日志及事物详解和基本操作语句
  20. 基于SSH开发service电子信箱(邮箱)管理系统

热门文章

  1. 如何高效学Python?好用的爬虫工具又有哪些?
  2. 毕业三年,快手总包 90W 值得去吗?
  3. 赞!Google 资深软件工程师 LeetCode 刷题笔记首次公开
  4. 电子琴节奏包制作_济南这个藏在菜市场的小饺子馆,纯手工制作,老板娘一个人不停忙...
  5. 在oracle中如何复制用户的权限不够,linux 普通用户下 移动或复制一个zip文件权限不够怎么办...
  6. 深度学习-Tensorflow2.2-模型保存与恢复{9}-保存与恢复-21
  7. 16-爬虫之scrapy框架手动请求发送实现全站数据爬取03
  8. 星外php使用教程_星外PHP5.2.17自动配置一键安装包 防phpdos v1.4
  9. 50-100G大文件的处理办法
  10. [PHP] 深度解析Nginx下的PHP框架路由实现