前言
设计是把双刃剑，没有最好的，也没有更好的，而是条条大路到罗马。同时不设计和过度设计都是有问题的，恰到好处的设计才是我们追求的极致。 ---摘抄
作为一名开发老兵，在进入阿里交易团队之前所认识所有的系统的都是面条行，即从端上一条线杀到数据库完成一个操作，仅有的一些设计集中在数据库上。
因此当我们作为一个新人接手的一个新业务系统时，我们首先要了解的是业务系统的背景，作为一个分布式系统，我们通常需要了解业务系统上下游有哪些系统，之后在深入了解完接口设计文档，和数据库设计文档后便开始无止境阅读复杂业务流程是如何将接口和数据库两个端点进行实现。
中台系统
中台系统的定义
企业级能力复用平台
「企业级」定义了中台的范围，区分开了单系统的服务化与微服务；
「能力」定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
「复用」定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
「平台」定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。
理想中的中台系统
中台系统生态.png
中台系统的复杂
中台复杂来源面对的需求方更加多样化。
- 1 面对垂直业务方的需求（1688，淘宝，天猫...）
- 2 自身产品化的需求（限时购，拼团，自主订单...）
image.png
中台系统的复杂带来的挑战
-
针对不同业务方需求传统的标准化流程形成挑战。
-
不断添加的业务需求使得，平台代码和业务代码耦合严重难以分离，业务和业务之间代码交织缺少拆解.
- 平台代码 所有业务通用实现代码
- 业务需要定制化的需求实现代码
-
各个业务方的代码实际上融合在一块，在没有拆解平台代码，业务代码情况下，某一处代码变更很难度量影响到业务方，提高上线风险和测试回归成本。
-
不断添加的业务需求使得难以抽象成能力。
-
一套系统N个业务方，上下发布流程难以实现敏捷快速的发布。
-
作为中台系统，并不了解前台系统，且由于人力资源的问题无法快速响应所有的业务方，在业务交付过程中中台反而成为了瓶颈。
-
多样化配置需求
共享交易平台
早期共享交易1.0时代
1 传统三层架构，多个业务方使用同一套系统系统，系统逻辑堆砌在应用逻辑层。
分层模型——经典三层架构(集中式架构).png
共享交易2.0时代
分层模型——经典三层架构(集中式架构)改进型+流程+SPI引擎.png
解决哪些问题
1 针对针对不同业务方需求传统的标准化流程形成挑战。
针对不同业务方多样化流程梳理出可以复用的节点，针对不同业务方定制化流程特有流程，通过流程引擎驱动程序而非硬编码。这里流程通过下单打标到订单属性中。
交易流程.png
在每个流程节点中确认通用子流程，将代码实现和流程图做对应，提高了代码可读性
2 不断添加的业务需求使得，平台代码和业务代码耦合严重难以分离，业务和业务之间代码交织缺少拆解.
通过SPI机制实现,针对多业务方定制化的需求，通过SPI实现多业务多个实现规则化执行,将多个业务实现写入不同代码实现包下,具体参考这里闲鱼SWAK 框架
3 作为中台系统，并不了解前台系统，且由于人力资源的问题无法快速响应所有的业务方，在业务交付过程中中台反而成为了瓶颈。
image.png
4 一套系统N个业务方，上下发布流程难以实现敏捷快速的发布。
人力每周发布，中台每周负责核心逻辑自动化回归。
存在哪些问题
1 项目风险问题
面对1000人维护的系统，面对数每周3~4需求的上线，测试回归成本巨大，
SPI实现并没做到ClassLoader隔离，也没有IOC容器隔离，共享交易中SPI 使用装饰者模式，被装饰对象可能因为装饰者对手BUG导致系统的错误。
2 能力复用的问题
2.0时代采用还是面向数据编程，也是就所谓面向过程的编程方式，并没有使用DDD类似面向对象，面向领域对象编程，所有的逻辑依旧通过上帝之手service来处理。
3 部署上线延迟
无法做到业务方环境独立部署
共享交易3.0时代
分层模型-----DDD分层架构.png
解决哪些问题
1 能力复用的问题
将原有的三层架构改变成DDD四层架构，将业务流程保留到应用层中，将业务逻辑下层到领域层。改变原先面向数据模型编程的方式，采用面向领域对象的编程。
---- 领域对象： 抽象出来业务模型
---- 领域服务：对于一个子流程处理节点
---- 能力：针对领域对象抽象出来可复用的能力
---- 扩展点：针对不同业务方需要定制需求实现，这里实现不在使用分包而是采用分JAR包的方式，包括如下：
- 1 平台默认实现
- 2 产品扩展实现
- 3 业务扩展实现
---- 业务身份：请求业务身份标识，会在配置中心配置该业务身份需要执行业务扩展点实现，和产品的扩展点实现，以及对应优先级，
2 项目风险问题
在代码架构上将代码模块做划分，通用包，扩展包，
1 核心包：包括应用层代码，领域层代码
2 扩展模板：SPI实现模块
3
2 TMF2框架引入
TMF2.0解决的关键问题
面对这些挑战，TMF2.0框架需要六大关键问题。
业务可视化：平台能力、业务规则决定是否对外透出；
需求结构化支持：基于透出的业务能力、已有的业务规则完成需求结构化分解降低沟通成本；
业务配置化：这是可视化的前提，要在需求明确的情况下在线配置业务、快速发布上线；
业务测试一体化：根据修改的代码进行自动化用例筛选、自动化测试；
业务监控：以精细化的业务维度进行监控，而不仅仅局限于交易大盘；
故障排查：当业务故障时快速拿到故障快照、还原故障现场以及迅速定位问题原因。
网友评论