《阿里中台战略思想与架构实战》读书笔记

背景

最近公司如火如荼的进行中台建设，各种业务中台涌现，迫切想知道中台的发展规划和关键解决问题，比较庆幸看到了这本书《企业IT架构转型之道-阿里中台战略思想与架构实战》应该是标题中台两个字吸引了下~

感触

最近跟朋友聊天，听书介绍，管理培训，最大的收获其实就是思维的转变，思维转变了很多事看着就会更加清晰。别有洞天的震撼。看完了后久久不能平静，里面的很多架构演进，有的比较有幸的看到了参与了，有的正在经历，有的可能即将要经历，觉得井上面的那片天有些扩大的感觉，这种感觉很奇妙~

借鉴

1.阿里中台战略的由来很有意思，是阿里高管15年参观世界上最成功的移动游戏公司supercell，这家典型的小团队模式进行开发的公司，可以最快的推出游戏内测版，不受欢迎，可以迅速的放弃这个产品再进行新的尝试，期间几乎没有管理角色的介入，团队失败后，不但没有惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。它的核心竞争力就在多年的游戏研发中积累了非常科学的研发方法和体系，也就是中台能力。以至于很多模仿者都无法替代。

2.美军在二战时，以军来为单位作战；到了越战时，以营为单位作战；到了中东战斗的时候，以7人或者11人的极小班排去作战，这是今天最灵活的军事组织，也是核心竞争力和打击能力最强的一个组织。而美军之所以能灵活作战，敢放这么小的团队到前方，是因为有非常强的导弹指挥系统，有非常强大的中台能力，能支持这样的小团队快速做判断，并且引领整个打击。

美军作战图

3.名创优品的共享思维，共享店铺，共享设计师，共享生态链

共享店铺，名创优品用匠人打造物美价廉爆款商品后迅速吸引力大批传统服装行业的店铺商拿着最好地段店铺来跟名创合作，店铺共享，极大程度降低边际成本。

共享设计师，同时名创为了将设计多元化搭建了设计师平台，设计师可以拿着自己的设计来找名创合作，一次性买断版权或者靠订单分红，聚拢了大批设计专家，当一系列生态搭建好了之后，名创开始走向了更大一步的共享共享生态链，

共享生态链，全球国家店铺加盟，遍布全球，统一的培训店长，发货供货进销存，由集团统一培养配送，店家只需要将名创当成一处投资即可。目前名创销售额约1000亿 850亿来自海外。

经典案例

阿里巴巴在2003年时成立了淘宝事业部，2008年时成立了天猫事业部，没过多久，天猫与淘宝并驾齐驱，此时淘宝的技术团队同时支持着淘宝和天猫的业务。

这样的组织架构阵型决定了技术团队会优先满足淘宝的业务需求（屁股决定脑袋，大家都懂的），使得天猫的业务团队怨声载道，严重影响了天猫的业务发展。

另一个业务架构层面的问题：当时淘宝和天猫的电商系统是完全独立的两套体系，但同时都包含了商品、交易、评价、支付、物流等相同功能。

早期淘宝与天猫

为了解决以上两大问题，在2009年，“共享事业部”应运而生，主要成员来自于之前的淘宝技术团队，在组织架构上与淘宝、天猫同级别（如上图），集团希望以这样的方式更好地让技术团队同时支持好淘宝和天猫的业务，并将两套电商的业务做了梳理和沉淀，把两个平台中公共的、通用的业务功能沉淀到了共享事业部，避免功能的重复建设和维护，更合理地利用技术资源。然而，接下来的发展事与愿违。虽然组织架构上共享事业部和淘宝、天猫平级，但在对业务的理解和贡献上来说，显然淘宝和天猫拥有更多的话语权，结果是共享事业部在两大业务部门的夹缝中生存。

到此，共享事业部的发展与大多数人的期望有很大偏差。

共享事业部同时满足着淘宝和天猫高压态势的业务支持，在资源固定的情况下，就算团队成员再怎么加班加点，也很难及时、周到地支持好两大业务部门，结果就是业务部门对共享事业部的满意度不高，而共享事业部的同学们内心有苦说不出，只能默默流泪。

2010年聚划算出现了。聚划算平台刚一上线，就展现出强大的流量吸引力，所以一时间大家趋之若鹜，纷纷对接聚划算平台。

后来1688也参与其中，三大电商运营人员各展所长，争占聚划算平台上的有利资源，面对如洪流般的业务对接需求，当时刚成立不久的聚划算团队应接不暇（图）。

这时，集团要求三大电商平台如果要与聚划算平台进行业务对接，必须通过共享事业部！正是有了这“点睛之笔”，共享事业部便有了一个极强的抓手，将原本与三大电商平台对话权不平等的情况拉平，这使得“共享事业部”成为了阿里巴巴集团的核心业务平台。

从2009年开始建设的“共享事业部”为阿里巴巴的架构转型奠定了基础。

2015年年底，当大多数企业忙着进行年度总结和规划时，阿里巴巴集团宣布全面启动“中台战略”，构建符合DT时代的“大中台、小前台”组织机制和业务机制：作为前台的一线业务会更敏捷、更快速适应瞬息万变的市场；中台将集合整个集团的运营数据能力、产品技术能力，对各前台业务进行强力的支撑。

收获烟囱式架构

早期淘宝天猫1688三套电商体系架构完全独立，各自应用独立运维和开发，三座“烟囱”分别矗立支撑着当时阿里集团最为核心的电商业务。

原因：1.开发团队思考的电商模式不同，需要独立建设2.新业务团队认为在之前基础上搭新业务会有太多的技术和业务的历史包袱，还不如重新构建弊端：1.重复功能建设和维护带来重复投资2.打通烟囱式系统间交互集成协作成本高昂而比如订单信息 用户信息不得不打通后获取全局会员及消费数据3.不利于业务的沉淀和持续发展

专家的养成

我们从小学开始学习很多基础知识，更多的是知识点的掌握；随着我们掌握知识点的增多，我们开始有意识地将一些知识点组合在一起，解决一些复杂的问题，关联这些知识点的过程实际上是将这些相关的知识点串成了知识线；随着在知识领域的继续积累，越来越多知识线的汇聚，我们有机会更全面地了解到这一知识领域（知识面），从而构建了对这一领域自身的知识体系，而这时的你相信已经成为这个领域的专家。

可以看到上图中共享交易事业部对于不同业务中交易场景的支持，1688（B2B）淘宝（B2C）天猫（B2C)的各自业务架构师对各自负责的交易流程的业务会非常的精通，不过在某种程度上看到的都只是哥哥业务场景中对交易业务的点，而图片下方的交易中心中的业务架构师所接触的来自不同业务模式下的所有交易相关的需求，这样的阵型是的负责交易中心的相关人员更容易扩展到线和面的维度全面掌握交易的业务。结合上面的理论，共享服务体系能很好的培养出特定领域的专家。

专人做专事？

整个技术团队作为一个组合精密的流水生产线，源源不断的业务需求涌进这条生产线后团队各司其职的人员协同配合，争取最快实现业务需求的满足。优点是可以不断打磨梳理出一套合理且高效的组织架构，但是弊端也会使流水线上的不同角色人员的技能的持续提升会出现发展瓶颈，做了3年开发跟做了5年开发人员可能在开发能力上灭有太大的区别，根本原因就是这两年的差别仅仅是用自己熟练的技能多生产出几个不同的系统。

业务架构师

业务架构师是共享服务中心发展的领路者，也是保障服务中心核心业务保持业务通用性和公共性的最重要捍卫者，能力模型是典型的即懂技术，也对负责的业务领域有相当理解的，通过共享技术的不断沉淀让部门从企业中的“业务支持”的组织职能，转变为基于企业核心业务和数据运营的团队，这个团队会更快更好的支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。在接下来整个社会进入开放共享的时代，这种人才的价值将成为公司最宝贵的资产。

业务架构师一般会一直关心和思考以下问题：

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

中心化与去中心化

中心化ESB企业服务总线实现的SOA方案根本诉求是实现异构系统（自研应用，商用套件应用，定制开发应用）间的交互，降低了系统间的耦合，更方便高效的实现了对新系统的集成。弊端“中心点”带来平台能力难扩展问题业务响应慢，由于需要跟企业总线多次交互，对总线的访问和计算压力都很大，以及潜在的“雪崩”影响去中心化分布式框架除了对SOA特性的实现和满足外，有效的避免了中心热点，雪崩等弊端。

共享服务化中心设计原则

1.高内聚，低耦合原则2.数据完整性原则这个原则与“高内聚，低耦合”一脉相承，是把这个思想穿透到数据模型层面，因为服务化架构一个很重要的业务价值就是数据模型统一。这里特别强调大数据的思维，不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。3.业务可运营性原则服务中心首先是从业务出发，单纯的技术层面抽象出来的服务框架一般不作为一个可运营的服务中心。期望服务中心是承载业务逻辑，沉淀业务数据，产生业务价值的业务单元

数据分久必合合久必分

尽可能水平拆分1.基本拆分 主从同步读写分离2.水平拆分 基于ID进行hash取模方式实现3.异构索引表 降低全表扫描

精卫同步可图形界面配置化一站式同步全链路监控任务调度平台

多条件频繁查询引入搜索引擎平台

采用异构索引的方式在实战中基本能解决和避免90%以上的跨join或全表扫描的情况，是在分布式数据场景下，提升数据库服务性能和处理吞吐能力的最有效技术手段，但是对于多条件频繁搜索则不建议异构索引，而是建议将数据同步至专业搜索引擎平台，入Lucene,Solr,ElasticSearch等。

异步化1.业务流程异步化

对于有严格先后调用关系的服务保持顺序执行，对于能够同步执行的所有服务均采用异步化方式处理

2.数据库事务异步化

将大事务拆成小事务，降低数据库的资源被长时间事务锁占用而造成数据库瓶颈，就能大大提升平台的处理吞吐量和事务操作的响应时间。

3.事务与柔性事务传统事务

CAP 一个分布式系统最多只能在同时满足Consistency一致性 Availability可用性 Partition tolerance分区容错性这三项中的两项

BASE 是指基本可用（Basically Available） 柔性状态(Soft State) 最终一致性(Eventual Consistency)

一阶段事务 二阶段事务 比起一阶段提交，二阶段提交在执行同样的事务时会耗时更多时间，而事务执行时间的延长意味着锁资源发生冲突的概率增加，当事务的并发量打到一定数量的时候，就会出现大面积事务积压甚至出现死锁，系统性能和处理吞吐率就会严重下滑

柔性事务

1.引入日志和补偿机制事务日志记录事务的开始结束及参与者，参与者节点需要根据重做回滚记录到REDO/UNDO日志，当事务重试回滚时，可以根据这些日志最终将数据恢复到一致状态2.可靠消息传递要求消息至少投递一次，需要消费幂等3.实现无锁由于锁占用大量数据库资源，那么选择放弃锁也是解决问题的一种思路，通过其他手段保证最终一致性和隔离性4.乐观锁

事务消息

柔性事务的思路，消息服务在其中扮演了事务日志的职能，对全局事务有一个统一的记录和调度能力，事务的参与者通过对消息订阅关系建立了事务间的关联。在采用消息服务实现分布式事务的场景如果出现异常时，一般会采用正向补偿方式，即不会像传统事务方式出现异常时依次回滚，会通过从消息的不断重试或人工干预让事务链路继续朝前执行，而避免出现事务回滚。

事务消息应用

事务消息回滚

总结：其实都不需要两阶段提交这样低效的方式来解决分布式事务问题，可以结合配合方案

1.应用程序一定要做幂等实现，特别是对数据库进行数据修改操作时2.远程模块之间用异步消息来驱动，异步消息还可以起到检查点的作用

业务一致性平台

服务依赖链路众多，业务域数据不一致问题涌现，业务稳定性保障迫在眉睫，要解决这个问题，就需要实现业务处理的过程中，实时监测到业务不一致的问题，在消费者发现该问题之前系统就应该发出了报警，并且转交相关人处理。也许在用户开始投诉前，这个问题就被纠正过来了，这样影响面也就很小了。

目标：

1.高实时的发现业务脏数据或者错误逻辑实现，第一时间发现并及时通知技术保障人员，而不是等待客户反馈。2.方便的接入各种业务规则，通过脚本规则编写的方式，让各应用快速接入3.整合订正工具，形成规范的脏数据订正流程4.业务上线的实时监控，新上线业务可以方便的进行校验

为了避免对业务的侵入，采用的是实践模式，把业务数据变化触发的消息转换为相应业务类型的事件，放入到事件执行队列进行规则检查，实现将数据变更日志接入平台。通过事件的类型和状态，从规则库中获取对应的业务规则去做业务校验。

思维脑图