业务中台整体发展(淘系)
| 单应用 |
分布式 |
平台化 |
中台化 |
内核化(进行中) |
|
| 核心问题 |
0->1 |
业务增速&系统访问量 |
数据不互通 & 研发效率 |
各大中心较为孤立 |
1.按能力建中心，业务完整度不够。2.平台框架+业务插件（组合方式），本质上平台与业务混合。 |
| 核心思路 |
堆硬件 |
拆分子系统，Scale能力 |
整合重复系统，抽象能力中心。重点解决中心与业务开发的问题。 |
统一管理各大中心的整个研发生命周期。从需求，开发，到上线。 |
以业务为中心重点多层次抽象，外层包含内层。收敛&稳定核心。 （ps：插件不是重点，插件方式提供更丰富的继承以及进程内通讯等OO和网络特性。） |
| 核心技术 |
IOE |
分布式中间件 |
TMF（插件框架，平台能力+扩展点，业务间隔离） 各大中心孤立的可视化工具 |
各大中心统一的可视化工具 |
业务抽象系统（市场->天猫->天猫超市） |
| 演进路径 |
技术中间件 |
以能力为中心 & 工具化 |
以业务为中心，能力为支撑 |
||
交易中心系统演进（以技术驱动的重点项目为主。双11的流量高峰是推进技术的主动力）
| 非功能需求分类 |
重点项目 |
核心问题 |
核心思路 |
核心技术 |
| 维护性 |
交易系统整合（五彩石二期） |
淘宝商城b2c与淘宝c2c重复建设，各系统数据不通。 |
统一交易中心。 |
|
| 交易模块化框架（TMF） |
原有SPI方式实现插件。SPI数量大，同一SPI不同业务实现会有叠加冲突，相互影响稳定性。 |
SPI+决策树->业务/平台分离。 1.实现平台与业务隔离，2.业务与业务解耦，3.可视化配置工具。 |
平台提供OpenSDK，按业务独立部署。 确定业务身份，加载对应扩展点与配置项。 |
|
| 多端数据协议平台(奥创) |
多端API交互，数据View模型不统一。 |
Model-> ViewModel -> UIModel。翻译一层api请求至结构化数据Model，再发送至TMF接入层。 |
MVVM+SDK。 |
|
| 稳定性 |
异地多活 单元化项目 |
同城部署的稳定性弱，分布式集群规模没法无限扩大。 |
同城双单元-> 异地多活。三地四单元。 |
中间件路由+数据同步。从接入层便开始按用户ID分流。 |
| 全链路自动化压测&故障演练&系统自我保障 |
稳定性 |
工具化&自动化，不用人工介入。 |
故障演练：Chaos 自我保障：限流，降级，流量调度，负载保护，预案 |
|
| 完整性 |
实时业务审计BCP |
流程中断/异常，导致数据不一致，产生资损。 |
利用在线数据去实时对账。 |
监控实时数据流，数据比对。 |
