关于阅读业务中台的总结思考

目前正在做业务中台，但是面对较多接入方（有前面的也有后面的），感觉做的非常的累，看不到自己在做什么（只有无穷多的需求）？业务中台到底解决了什么问题？

所以在建设中台前，第一个要问自己的就是：我们建设中台，愿景是什么？而且更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。

明确中台的用户和客户是谁？（避免被动）

中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题（避免成为各方的外包，要听得进别人的化，但是还要明确自己的目标，走自己的路）

中台的目标怎么验证？

阿里中台考核（不能完全借鉴）： 40%稳定 + 25%业务创新 +20%服务接入量 + 15%客户满意度

中台边界确认

1. 业务通用，众多业务线通用能力
2. 多业务，业务线多
3. 下沉机制，自顶向下层推动

业务中台定义（引用他人）：

我们常提到的业务中台，是狭义层面的业务概念，业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。

目的

1.在当年这样一个互联网时代，用户才是商业战场的中心，为了快速响应用户的需求，借助平台化的力量可以事半功倍。
2.提高用户响应力，不断抽象沉淀自己核心的底层能力，通过平台化包装，得以更好地赋能前台业务，用底层的确定性来帮助企业对前台业务以及最终用户需求的不确定性。
3.平台化，并且让不断对自身进行治理演进、打破技术边界、逐渐拥抱业务、容纳业务、具备更强的业务属性的过程。中台关注为前台赋能，真正为前台而生。

前台：由各类前台系统组成的前端业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机 App、微信公众号、小程序等都属于前台范畴。

后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。

并不是主要服务于前台系统的业务创新，而是为了后端资源的电子化管理，解决企业管理的效率问题。大多数企业已有的后台，要么前台根本就用不了，要么不好用，要么更新速度就根本跟不上前台的业务发展的节奏。总结“慢”和“贵”。

背景历史：

Middle Office （阿里）2018，天猫+淘宝，重复减少涉的问题，烟囱式系统架构->重复建设和资源浪费->重复组织和系统进行整合。阿里共享事业部诞生，为各个前台系统公告部分进行平台化改造->痛苦，夹缝->聚划算爆发的契机->阿里共享事业部重要地位。

思考：

1.互联网龙头企业（阿里、京东、腾讯）的样板效应。
2.互联网企业进入传统行业的一个非常好的切入点，将互联网技术和实践带到传统行业，中台是一个非常好的抓手和利器。消费侧战场激烈，求助于供给侧。
3.烟囱林立、数据孤岛等痛点。
4.底层原因，最近两年经济形势不好，但是把能力进行沉淀和复用，应对未来。

疑问

1.中台化与平台化的区别是什么？
2.中台化和服务化的区别是什么？
3.中台该怎么建设？

1.企业级（只支持一条业务线和产品线，那就不是中台），并不是技术问题，而是企业架构问题。需要跨业务线的能力沉淀。
2.能力 中台的主要承载对象，能够有怎样的能力决定了该中台
3.复用 易用性+用户体验（响应 平稳）
4.平台 中台的主要形式，区别于传统的应用系统拼凑，更细粒度能力的识别与平台化沉淀

利用平台化的思维和手段梳理、识别、沉淀与复用企业级核心能力的过程

不同中台：

1.业务中台
2.数据中台

业务中台生产数据，数据中台对数据二次加工，并将结果再服务于业务，为业务进行数据和智能的赋能。

业务中台下业务根据领域模型分为各大中心:

交易中心
支付中心
订单中心
商品中心

会员中心
评价中心

柔性事务

1.引入日志和补偿机制
2.可靠消息传递 - 要求消息至少被投递一次，需要消费幂等
3.实现无锁
4.乐观锁

目前能够清楚的：
1.当前的业务流程设计中，我依赖了哪些应用，哪些服务？
2.整个链路的依赖路径是怎么样的？哪些服务对当前业务处理来说是最为核心的？这些依赖如果出错，会有什么影响？
3.一次业务请求处理的时间到底花在了什么地方？是因为某一个服务耗时很长，还是因为某一个数据库的访问操作？
4.我所负责的业务链路中，过去一段时间哪些服务是出错率比较高的，哪些服务是业务链路的处理瓶颈。

数据库异构难题，阿里解决方案-精卫：
精卫平台通过抽取器（Extractor）获取到订单数据创建在MySQL数据库中产生的binlog日志，转换为event对象，用户可以通过精卫自带的过滤器（Filter）对event对象中的数据进行处理，最终通过分发器（Applier）将结果转换为发送给DRDS的SQL语句，实现异构索引数据。

分布式事务一致性淘宝XTS框架：
支付宝XTS分布式事务框架是基于BASE的思想实现的一套类似两阶段提交的分布式事务方案。
用来保障在分布式环境下高可用性、高可靠性的同时兼顾诗句一致性的要求。相比消息实现的分布式事务仅支持正向补偿，XTS可同时支持正向和反向补偿。XTS是TCC(try/confirm/cancel)型事务，属于典型的补偿性事务。