评：推荐做系统架构师的同学可以看一下。的确讲了一些干货，但很多内容留于表面。对于中台的定义和思考，建设中台的方法以及阿里中间件有比较完整的描述。
阿里巴巴电商系统的架构经历了烟囱式架构到分布式架构再到共享式架构的转变。#序言
阿里巴巴集团中台战略研发的思考
2015年底，启动阿里集团2018年中台战略，构建符合DT时代的更具创新性、灵活性的“大中台、小前台”组织机制和业务机制，即作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场，而中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务形成强力支撑。#3
构建业务中台的基础 —— 共享服务体系
“烟囱式”系统建设模式：普遍的企业IT建设模式，基于业务需求建设系统。导致烟囱林立。#9
SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助理业务的快速响应和创新。SOA架构的核心价值 —— 服务复用。#15
不管前端业务形态如何多样，提供的服务都能很好地包含了核心服务，让前端业务的交易信息和数据回流到对应的服务中心。#16
服务最不需要“业务稳定”。一个服务如果一味追求功能的不变，一定程度上就是固步自封，逼其他业务系统重复造轮子。#18
科学证明，人数是7个人的团队协同效率是最高的。#23
分布式服务框架的选择
微服务是SOA的一种演变后的形态，与SOA的方法和原理则没有本质上的差别。#54
共享服务中心建设原则
在阿里巴巴集团的中台战略中，共享服务中心是中台架构的基石。#57
共享服务中心的架构目的是通过业务拆分来降低系统的复杂度；通过服务共享来提供可重用性；通过服务化来达到业务支持的敏捷性；通过统一的数据架构来消除数据交互的屏障。所以，所有的原则和方法都是为了这些目标服务的 —— 以终为始。 #64
服务中心建设要考量的三个重要方面：设计（面向对象的分析和设计方法）、运营（完整的业务模型，要有数据运营和业务整合的价值）、工程（分布式架构的优点和引入的分布式事务、问题排查等难题）。#64
1 高内聚，低耦合原则 #65
高内聚是从服务中心的业务界域来说的，在一个服务中心内的业务应该是相关性很高、依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合。
2 数据完整性原则 #65
服务化架构一个很重要的业务价值就是数据模型统一。
3 业务可运营性原则 #65
服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。
4 渐进性的建设原则 #66
服务化架构本来就是一种敏捷的事件，推荐小步快跑的方式逐步推进，不是轰轰烈烈的推翻重来。
数据拆分实现数据库能力线性扩展
数据库是最容易产生性能瓶颈的服务组件。#67
采用读写分离的方式，拓展了数据库对数据读的处理能力，并且单表的数据量是有限的，达到一定数量后数据库性能会下滑。#68
当单表数据量过大时，采用水平分区的方式对数据进行拆分。确保单个数据库中保存的数据量在单机数据库能提供良好的读写性能范围之内。但对于跨库的表join、事务操作、数据统计、排序等的支持变困难了。#68
数据尽可能平均拆分
尽量减少事务边界
异构索引表尽量降低全表扫描频率（binlog）
将多条件频繁查询引入搜索引擎平台
异步化与缓存原则
业务流程异步化
阿里巴巴内部试用消息中间件的方式是实现了业务异步化。#90
数据库事务异步化
通俗来讲，就是将大事务拆分成小事务，降低数据库的资源被长时间事务锁占用而造成的数据库瓶颈。#92
事务与柔性事务
一个专业的互联网平台一定首先考虑的是系统服务能力的高可用，因为服务不可用意味着就是商业损失。#99
柔性事务如何解决分布式事务问题： #103
引入日志和补偿机制
可靠消息传递
实现无锁
在淘宝平台中，被广泛用来解决分布式事务场景的方案就是基于消息分布式事务，通过MQ事务消息功能特性达到分布式事务的最终一致。#107
绝大多数场景下，我们都不需要用两阶段提交这样低效的方式来解决分布式事务问题。为了充分发挥柔性事务框架性能的优势并实现业务的最终一致，需要采纳以下配合方案：#123
-
应用程序一定要做到幂等实现，特别是对数据库进行数据修改操作时；
-
远程模块之间用乙部消息来驱动，异步消息还可以起到检查点的作用；
打造数字化运营能力
实现分布式服务追踪系统的主要思路是通过服务调用链各服务处理节点生成响应的日志信息，通过统一请求中生成的日志具有同一ID将不同系统或服务“孤立的”日志串在一起，重组还原出更多有价值的信息。#138
TraceID，一般包含：IP地址，创建时间，顺序数。#138
RCPID，用于标识日志埋点顺序和服务调用间的嵌套关系。#139
埋点日志中会包含：
TraceID、RCPID、开始时间、调用类型，对端IP
处理耗时
处理结果
数据传输量：请求大小 / 响应大小
打造平台稳定性能力
限流和降级这两个能力是平台在服务化体系下还能保持稳定运行所必须具备的。#158
共享服务中心对内和对外的协作共享
共享服务平台的建设思路借鉴了SOA和API管理的思想。#188
业务中台与前端应用协作
业务中台是前端应用所需服务的提供者，前端应用是业务中台服务的消费者，同时前端应用对于业务中台也是需求的提供者。#196
业务中台的工作职能之一是保障中台业务核心稳固以及保持业务能力的通用性，前端应用则往往从项目实施成本和周期最快的角度来说，对业务中台提供的能力自然是越多越好，又或者对于某一业务的理解，业务中台方和前端应用放也存在差异。#197
出现中台与前端应用的争执时，一般按照业务负责的层级关系一次升级，每一层都有对该部分业务负责的业务架构师作为团队或部门的负责人。#197
如果发现有些前端应用中对于业务中台的需求确实是不同于前端应用共性的需求时，这样的需求就很适合沉淀到共享服务体系中，称为某服务中心新增的功能。#198
在进行业务沉淀到中台的工程中，采用共建的模式，业务中台和前端应用方各派出人员共同建设一个团队，一起负责该业务功能的实现以及到中台能力的沉淀。#198
业务中台绩效考核 #198
1 服务稳定是重中之重
2 业务创新推动业务发展
3 服务接入量是衡量服务价值的重要考核
4 客户满意度促动服务的提升
在此我向大家推荐一个架构学习交流群。交流学习群号： 744642380， 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良