《阿里巴巴中台战略思想与架构实战》读书笔记
《企业IT架构转型之道-阿里巴巴中台战略思想与架构实战》读书笔记
企业IT架构转型之道-阿里巴巴中台战略思想与架构实战
共享服务体系是业务中台的核心中枢
对这些服务中心的服务稳定性、服务能力的扩展性、服务需求的快速响应能力提出了前所未有的更高要求。
构建共享服务体系，需要采用一套服务化框架来支撑整个服务体系的运转。
共享服务支持前端业务的示意图
基于共享服务体系建设的服务中心，原生就将相关业务领域的业务功能和数据做了很好的统一。
共享服务支持前端业务的示意图
服务化改造的好处：
- 降低不同模块开发团队间的协同成本，业务响应更迅捷；
- 大大降低系统间的耦合度，以及整体复杂度，各个开发团队可专注于各自的业务模块；
- 避免了个别模块的错误给整体带来的影响；
- 业务拆分后解放了对单数据库集群连接数的能力依赖；（数据层也做了相应的拆分，即每一个核心服务中心都拥有各自独立的数据库）
- 做到针对性的业务能力扩容，减少不必要的资源浪费；
共享服务中心
在阿里的中台战略中，共享服务中心是中台架构的基石，如何构建稳定可靠、最高效地支撑上层业务快速创新的共享服务能力是中台战略成功落地的关键。
淘宝的共享服务中心包括多个服务中心。最初有4大服务中心：用户中心（UIC）、商品中心（IC）、交易中心（TC）、店铺中心（SC）。
随着业务的不断发展，越来越多的服务能力沉淀到了共享服务中心。
用户中心构建了整个阿里统一的用户体系，用户中心服务提供了统一的服务接口，即简化了上层业务的使用，也方便了接下来对用户的大数据分析。
同时，成立了专门负责用户中心运营的团队后，显著提升了对业务需求的响应效率。系统解耦后，服务的稳定性和可扩展性都得到了极大的提高。
淘宝共享服务中心演变的过程
服务中心中的服务形态多样性
1. 接口是服务最主要的形式。
如果服务中心的服务都完全拘泥于接口这种形式，那又大大局限了服务中心的服务能力，或者会增加上层业务的使用成本。
2. 服务中心也可提供界面形式的服务能力。
淘宝的商品中心的商品发布能直接提供用户操作的界面，商品的类目管理也会有淘宝小二操作的界面，类似的交易中心、营销中心都有提供界面形式的服务能力。
一个服务中心可以进一步划分
服务中心是业务领域的概念，落地到业务架构上，并不需要一一对应。
服务中心是跟进业务和数据的完整性与独立性来设立的，服务中心包含的子模块更多是从系统设计和业务架构层面来考虑的。
单服务模块、多服务模块
服务中心的划分原则
架构本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡，以最高效地解决主要问题。这是一名优秀架构师的必备特质。偏执地追求一个维度的完美，肯定会在其他方面付出代价。
共享服务中心的架构的目的：
- 通过业务拆分来降低系统的复杂性；
- 通过服务共享来提供可重用性；
- 通过服务化来达到业务支持的敏捷性；
- 通过统一的数据架构来消除数据交互的屏障；
服务中心的设计--基本原则：
- 高内聚、低耦合原则；
- 数据完整性原则；（服务化架构一个很重要的业务价值，就是数据模型统一）
- 业务可运营型原则；（期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元）
- 渐进性的建设原则；（小步快跑的方式逐步推进，服务化从简单开始，只有真实的业务需求才会锤炼出稳定可靠的共享服务）
数据库事务异步化
大的数据库事务对数据库的资源占用、表记录长时间被事务锁住，带来数据库请求排队。
解决平台性能问题的核心就是数据库事务的异步化。
也就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。
CAP理论
在分布式领域，基于CAP 理论和在其基础上延伸出的BASE 理论，有人提出了“柔性事务”的概念。
CAP理论 - 分布式计算领域的公认定理。
CAP理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
BASE理论
是对CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consistency）。
BASE 是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）。
- 基本可用 -- 指分布式系统出现故障的时候，允许损失部分可用性，即保证核心可用，如服务降级。
- 柔性状态 -- 指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。MySQL Replication 的异步复制也是一种柔性状态的体现。
- 最终一致性 -- 指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。
ACID和BASE的区别与联系
ACID和BASE代表了两种截然相反的设计哲学。
ACID是传统数据库常用的设计理念，追求强一致性模型；
BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。
柔性事务 -- 是由于互联网应用的需求产生的，那么需要看互联网应用的核心诉求是什么？互联网应用的最核心需求是高可用（也就是BASE的BA）。
柔性事务如何解决分布式事务问题
- 引入日志和补偿机制；（在互联网应用中，采用日志方式实现柔性事务的比例非常大。）
- 可靠消息传递；（由于消息可能会重复投递，这就要求消息处理程序必须实现幂等，同一操作反复执行多次结果不变。）
- 实现无锁；
如何实现高可用？
高可用 = 系统构建在集群环境中 = 分布式系统
高性能 - 分布式系统的副产品
业务中台与前端应用协作
业务中台是前端应用所需服务的提供者，前端应用是业务中台服务的消费者，同时前端应用对于业务中台也是需求的提供者。
两者之间不单单是服务提供者和消费者的关系，也是服务不断对接过程中，两者相辅相成，共同发展，业务能力不断专业化的过程。
协作模式：
- 业务中台对前端核心业务的紧密沟通机制；
- 建立分歧升级机制；
- 岗位轮转推动真正换位思考；
- 业务持续沉淀及共建模式；