《企业IT架构转型之道》

作者: whybask | 来源:发表于2021-01-03 13:34 被阅读0次

任何事物都经历“萌芽、成长、稳定、老化”的过程。阿里巴巴的中台战略，从造势、到成为行业标配，热度很高。当我读完、整理读书笔记的时候，又冒出了“阿里巴巴彻底拆中台了”的新闻。

新闻中说，中台适合做“组合式创新”，但没法做“颠覆式创新”。于是需要把中台做薄，预言“碎片化中台”时代要来临了，等等等等......

但学习是值得的，谨记：当我们了解的知识越多，我们可以取舍的自由度才越大。

1. 《企业IT架构转型之道》

本书的作者是钟华，曾是阿里巴巴中间件首席架构师（花名：古谦）。

本书讲述了阿里巴巴的技术发展史，在一定程度上也反映了互联网技术架构的实践与发展史。

主要内容分为三大部分：第一部分介绍阿里巴巴集团中台战略引起的思考，以及构建业务中台的基础——共享服务体系。第二部分详细介绍共享服务体系搭建的过程、技术选择、组织架构等，如分布式服务框架的选择、共享服务中心建设原则、数据拆分实现数据库能力线性扩展、异步化与缓存原则、打造数字化运营能力的方案、平台稳定性能力的开发、共享服务中心对内和对外的开放共享等。第三部分结合两个典型案例，介绍共享服务体系项目落地的过程，以及企业进行互联网转型过程中的实践经验。

企业IT架构转型之道

2. 读书目的

因为我所在的公司也在启动“中台”项目，所以我想积累点知识。加之有同事推荐了这本书，于是就购买、并阅读。主要是想了解如下的问题：

[what]阿里巴巴启动中台战略的背景是什么？
[why]中台会给企业发展带来哪些业务价值？
[how]组织架构和体制如何更好的支撑中台？
[how]中台建设应遵守哪些重要的技术原则？
[how]构建中台应避免哪些错误的理解？

3. 读书笔记

如果有，可在此处插入全书的思维导图或代表性的精美图片。

3.1 阿里巴巴启动中台战略的背景是什么？

在2015年年中，马云带领阿里巴巴集团的高管，拜访了位于芬兰赫尔辛基的移动游戏公司Supercell。该公司的产品占据了2015年App畅销排行榜的大半江山，年税前利润15亿美元。2016年6月，中国腾讯公司以86亿美元收购了员工数不超过200人的Supercell公司84.3%的股权，每一名员工人均贡献的估值超过3.54亿人民币。

Supercell是一家典型的以小团队模式进行游戏开发的公司，一般来说2~7个员工组成独立的开发团队，称之为Cell(细胞)。团队自己决定做什么样的产品，然后最快的时间推出产品的公测版，看看游戏是否受用户欢迎。如果用户不欢迎，迅速放弃这个产品，再进行新的尝试，期间几乎没有管理角色的介入。团队研发的产品失败后，不但不会受到惩罚，甚至会举办庆祝仪式，以庆祝他们从失败中学到了东西。

这种强大的业务试错能力是Supercell相比于其他游戏公司最大的差别，也是最核心的竞争力。为什么其他游戏公司不具备Supercell这样的能力呢？以为他们忽略了Supercell所构建的“中台”能力。

3.2 企业信息化面临的挑战：

IT人员不懂业务
IT人员自认对业务系统的具体流程、操作、数据模型方面比业务部门更懂，因为这些系统是IT人员负责建设的。但真正的“懂业务”是指：对业务流程如何进一步优化、对业务的下一步发展有着自己的理解和看法，甚至能提出创新想法、为企业带来新的业务增长点。
IT部门没有平等话语权
试想一下，在企业高层领导希望各部门对业务发展各抒己见的时候，一定是业务部门的领导们基于对业务发展的理解高谈阔论之时。此时有几位CIO或信息部门的领导能在业务上提出独到的见地？结果就是业务部门因为想法被领导采纳，争取到好的建功立业的机会，也自然获取不少好感，这些都无形中增加了业务部门的话语权。而IT信息中心则获取到工作任务，即配合业务部门完成该业务目标中IT系统的建设。行政级别的平等并不代表着具有同样平等的话语权！
导致“烟囱式”系统建设
信息部门在现有的模式下已经被更高的领导层定位成了业务支持的部门，是一个花钱的成本中心。当业务部门提出业务需求，信息部门进行系统集成建设，某种程度上每个新系统的上线都预示着一座新的烟囱矗立而成，这导致了如下的弊端：
- 成本方面，重复建设和维护带来重复投资；
- 效率方面，系统间交互的集成和协作成本高昂；
- 发展方面，不利于业务的沉淀，对新需求的响应和支持越来越吃力，这是对企业伤害最大的一点。

3.3 中台会给企业发展带来哪些业务价值？

所谓中台，是居于前端和后台之间的平台。中台倡导“共享服务理念”，其实也是SOA理念最核心的价值：松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。

共享服务体系是培育业务创新的土壤

好的创新一定是基于现状、因地制宜。这决定了提出创新的人一定对行业有过人的认识和理解，才有可能提出创新的想法。所以，企业真正需要的创新一定是来自于企业内部，而不会由外面所谓的专家告诉你如何创新。

在2014年开发了一个BCP（Business Check Platform，业务校验保障平台），使用业务规则的方式，通过BCP平台对交易进行业务和逻辑上的校验，该平台在当年的2014年双11中起到了非常重要的作用，单单在2014年双11当天就发现了超过10万个的业务不一致的订单信息，在给用户带来更好的用户体验的同时，也给集团带来了显著的业务价值，成为当年创新奖的得奖项目。这一项目也很好地诠释了之前所说的“点、线、面”的理论，在“点”（前端各类应用）上根本感知不到的问题，在“线”和“面”的平台（中台）上，更容易发现这些问题的本质，通过专业的技能解决这些问题，为企业带来实实在在的业务价值，这就是很好的创新！

中台赋予业务快速试错和创新能力

企业要想产生差异化的竞争力，必须比竞争对手有更强的业务试错能力。只有先人一步，才能帮助企业抢占商业先机的制高点。

试想一下，如果有一个好的业务想法，从头到尾建设所需的资源投入可能是100人年的时候，你会犹豫，到底投还是不投；如果告诉你100人月的时候，你会毫不犹豫地投入，所以这时候一个优秀的架构已经超出了效率本身的范畴，而是决定企业成败的关键因素。

做一个“中台”的类比：美军在二战时，以军为单位作战；到了越战时，以营为单位作战；到了中东战争时，以7人或者11人的极小班排去作战，它是今天全世界范围内最灵活的军事组织，也定核心竞争能力和打击能力最强的组织。美军之所以能灵活作战，敢放这么小的团队到前面，是因为有非常强的导弹指挥系统，有非常强大的中后台能力，能支持这样的小团队快速做判断，并且引领整个进攻完成。美军这样的战斗阵型与“大中台、小前端”战略完全一致。

中台为真正发挥大数据威力做好准备

企业实施大数据项目后，所展现的业务价值不尽如人意。主要是因为大数据项目面临两个艰巨的挑战：

数据分布广、格式不统一、不标准；
缺少能基于数据有业务建模能力的专家。

中台可以把相关业务领域的逻辑和数据融合得很好，中台的每一个服务中心提供的数据均是质量非常高的业务数据。这样在实施大数据项目时，就能简化数据标准化、数据清洗等工作。

“数据有业务建模能力的专家”也就是数据科学家，这类人才在市场上是很难找到的。而中台能很好地帮助企业信息部门培育出懂业务的专家，这些人员自身在拥有不错的技术功底的同时，逐步提升业务上的能力，具备这样能力模型的人员才有希望成为能发挥大数据平台价值的“数据科学家”。

改变组织阵型会带来组织效能的提升

如今大多企业的信息部门的职能还停留在“业务支持”的程度，是为企业的业务部门提供IT系统支持的组织。这也造成了这些企业的信息部门的员工，更多的是承担甲方项目经理的职能，很多事情本质上都是偏事务性的工作，也就是这样的工作并不会随着工作时间的长短而让人的能力得到持续性提升。这种以项目为导向的方式，使得信息部门的员工往往一个项目上线后，就会投入到下一个项目的工作中，对员工在业务或专业能力上很难得到持续的积累和沉淀，结果就是员工的积极性和创造力在逐渐被消磨，整个信息部门的生产力和创新氛围也会受到非常大的影响。

最重要的是让信息中心部门从之前在企业中“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快、更好地支持业务发展的同时，逐渐掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既精通业务，又熟悉技术”的复合型人才。企业最大的价值将会是基于这些核心业务和数据进行对外开放的运营，到那个时候，这个部门将成为企业最为宝贵的资产。

3.4 组织架构和体制如何更好的支撑中台？

阿里巴巴中台发展史

阿里巴巴的中台战略也不是一蹴而就的，从下面两个漫画图就可以看出“当初也是夹缝中求生存”。转折点是来自于业务要求、而非技术要求，即：阿里巴巴集团要求三大电商平台（淘宝、天猫、1688）如果要与聚划算平台进行业务对接，必须通过共享业务事业部！

阿里巴巴共享业务事业部的发展史1

阿里巴巴共享业务事业部的发展史2

目前阿里巴巴集团前端超过25个业务单元（如淘宝、天猫、聚划算、去啊等大家熟知的业务）均不是独立地构建在阿里云的云平台之上，在后端阿里云技术平台和前端业务间有了一个“共享业务事业部”，将阿里巴巴集团前端业务中公共、通用的业务沉淀到了这个事业部，包含了用户中心、商品中心、交易中心、评价等十几个中心，而共享业务事业部正是“厚平台”的真实体现，为阿里巴巴各种前端业务提供着相应服务中心领域内最为专业、稳定的业务服务。

阿里巴巴业务架构

中台与前端的协作模式

中台将会是前端应用所需服务的提供者，为保障中台和前端相辅相成，共同发展，应建立如下的机制：

紧密沟通机制：中台核心架构师和运营人员定期参与前端业务方的业务会议，以及参与重要项目的研讨会。通过这样的方式，让业务中台对于前端重要应用的业务发展动向有一个准确、及时地了解，从而为业务中台如何更好地支撑这些业务做好准备和服务能力的提升。
建立分歧升级机制：因为中台和前端业务所处岗位的诉求差别，所以难免会出现对于将一个业务功能的实现是放到业务中台的服务中心去实现，还是在前端应用中去实现产生分歧。所以，一定要引入分歧升级以及最终仲裁的机制，不能将问题永远停留在无休止的讨论甚至争吵中。
建立岗位轮岗机制：通过这样的方式，让原本口头上说起来容易的“换位思考”在现实中落地，对于公司培养综合性管理人才以及业务中台与前端应用方更顺畅的协同协作都起到了非常积极的作用。
建立业务共建机制：对于要沉淀到业务中台的业务，如果人员没有足够的业务理解和能力，此时，就会采用共建的模式。业务中台和前端应用方各自派出人员共同组建一个团队，一起负责该业务功能的实现以及到中台的能力沉淀。

业务中台绩效考核

业务中台处在服务稳定和业务创新间平衡的一个处境中，正因为这一特殊处境，才有了针对业务中台的考核维度：

服务稳定是重中之重（40%）：事故等级及次数，都会给服务运营团队带来绩效上最大的影响；
业务创新推动业务发展（25%）：为了避免服务运营团队单纯地追求稳定运行，而减少业务的创新和尝试，所以会有专门针对业务创新的考核；
服务接入量是衡量服务价值的重要考核（20%）：除了对服务功能的不断完善和专业化，服务运营团队同时也需要做内部的营销，让更多的前端应用接入、使用服务；
客户满意度促动服务的提升（15%）：为避免故步自封、骄傲自大，也应该考核服务运营团队是否能对前端的业务方和合作方提供更好的支持和服务。

3.5 中台建设应遵守哪些重要的技术原则？

采用“去中心化”的分布式服务框架

一个互联网平台的业务发展得再好，一旦有更多的用户访问后，这个平台如果没法再进行扩展的话，这将给平台带来灾难性的后果。这就是为什么今天几乎所有互联网公司均基于“去中心化”分布式服务框架建设系统，其根本原因就在于扩展性是首要的。

所以“去中心化”分布式服务框架除了对于SOA特性的实现和满足外，相比“中心化”服务架构最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，避免因为“中心点”带来平台能力难扩展问题，以及潜在的“性能雪崩”影响。

服务提供的技术方式具备多样性

依赖于接口的服务：这类服务是上层应用提供编程接口，接口可以是RPC，也可以是基于Web API的，从整体上来看，这里尽量统一会带来整体结构的简化。
依赖于工具的服务：这类服务有两类，一类用于提供定制的配置服务，比如淘宝商品中心要设置前台类目体系，交易中心要配置业务的交易流程；另二类是运营管理类的工具，比如商品巡检服务。
依赖于数据的服务：这里的服务主要是指对大数据的分析能力，实时交易型的数据能力一定要通过接口服务对外暴露。

划分服务中心应考量的维度

中台架构设计的目的是：

通过服务共享来提供可重用性；
通过服务化来达到业务支持的敏捷性；
通过统一的数据架构来消除数据交互的屏障。

中台建设也需要通过业务拆分来降低系统的复杂性，形成一个个“共享服务中心”。划分服务中心应考量的维度有三个：

从设计层面来看，主要是要遵循面向对象的分析和设计的方法，即业务和系统建模遵循面向对象的基本原则，这些是多年软件工程学的沉淀，服务化不是开创一套新的设计方法，而是一个指路的明灯。
从运营层面来看，服务中心应该是一个完整的业务模型，要有数据运营和业务整合的价值。比如淘宝的商品中心，绝对不只是简单的商品增删改查的服务接口，而是建立一个全球最大的商品库，同时提供该商品库的管理运营的方法和配套工具服务。
从工程层面来看，共享服务的架构是基于分布式架构，分布式架构解决了一体化架构在大规模应用上的问题，但是也引入了分布式事务、问题排查等方面的一些难题，所以在规划服务中心的时候，一定要综合评估业务层对服务中心在数据库、业务以及运营方面的需求和技术上需要的投入。不能图一时之快把业务拆得非常彻底，到最后却不得不用很大资源投入来解决技术上面对的问题。

划分服务中心应遵循的原则

高内聚、低耦合原则：这是众所周知的、但又经常被违背的一个基本原则，怎么强调都不为过。点击查看“高内聚低耦合”的解释。
数据完整性原则：服务化架构一个很重要的业务价值就是数据模型统一。这里特别想强调大数据的思维：不光只是业务逻辑的关键数据，还要考虑到业务的相关性数据；不光是实时在线数据，还要考虑到离线计算的数据。
业务可运营原则：单纯的技术型的服务中心可以存在，但不是重点。我们期望服务中心是承载业务逻辑、沉淀业务数据、产生业务价值的业务单元。业务的运营性有两个层面含义，一是指业务本身的活力，当业务处于快速生长期，这时候的运营目标是满足上层的业务需求，这个时候属于沉淀阶段；第二个层面的运营是指业务内部的孕育出来的创新想法，比如淘宝基于大数据分析技术生长起来的商品巡检技术、前台类目自动聚合推荐技术等。数据模型统一之后，可用很低成本把大数据技术引入到服务中心的架构中，让数据来源、数据分析、业务生产可以自然形成闭环。所以能否用大数据能力提升运营水平是服务中心原则之一。
渐进性的建设原则：渐进性的建设原则是从降低风险和实施难度这个角度出发，服务化架构本来就是一种敏捷的实践，我们是推荐小步快跑的方式逐步推进，不是轰轰烈烈地推翻重来。其实在分布式架构体系下，在企业互联网架构体系下，试错的成本已经降到足够低，渐进式的建设也是服务中心建设的一个重要原则。

实现数据库能力线性扩展

数据库瓶颈会严重阻碍中台服务的持续发展。扩展数据库性能的技术有：

数据库的读写分离：扩展性一般；
对数据量大的单表进行水平分区：扩展性一般；
采用分布式数据库系统：扩展性高。

书中介绍了阿里巴巴的“分布式数据平台的发展和演变历程”。从产品角度来说，目前市场上有较多可供选择的“分布式数据库产品”。不管采用哪种分布式数据库产品，都需要关注以下的建议：

数据尽可能平均拆分。大量的数据尽可能的平均拆分到后端的数据库中，如果拆分得不均匀，还会因为增长过快产生数据访问热点，造成性能瓶颈。
尽量减少事务边界。所谓事务边界是指单个SQL语句在后端数据库上同时执行的数量。事务边界的数量越大，系统的锁冲突概率越高，整体性能就会受到巨大影响。
用异构索引表降低全表扫描频率。在买家查看自己订单的业务场景中，就出现了全表扫描的情况，而且买家查看自己订单的请求是非常频繁的，会造成性能的问题。针对这类场景问题，最常用的是采用“异构索引表”机制，将原表内的每一次创建或更新，都换另一个维度保存一份完整的数据表或索引表。本质上这是“拿空间换时间”。
将多条件频繁查询交给搜索引擎平台。众所周知，对商品进行高级搜索会组合非常多的查询条件，采用传统的SQL搜索会导致全表扫描，会带来数据库性能压力和链接资源压力。因此，建议采用专业的搜索引擎平台来行使这样的职能。

用柔性事务替代强事务

数据库事务的核心是体现ACID（原子性、一致性、隔离性、持久性），有关的资料很多，请自行查找。简单来说：只有某次交易中的所有的操作都成功了，对数据的修改才会永久更新到数据库中。任何一个操作失败，对于数据库的修改都会回滚恢复到以前的状态。

要保证业务的一致性，传统的ACID理论确实很好。但在互联网大并发、分布式领域，要实现强一致性非常难，于是出现了“柔性事务”的概念。

在分布式计算领域，CAP理论被认为是定理：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availablility）、分区容错性（Partition tolerance）这三项中的两项。

一致性是指：操作成功后，所有的分布式节点在同一时间的数据完全一致；
可用性是指：用户在访问数据时可以得到及时的响应；
分区容错性是指：分布式系统在遇到某节点或网络分区故障的时候，仍然能够对白提供满足一致性和可用性的服务。

可以看出CAP理论很严格，于是出现了BASE理论。BASE是指基本可用（Basically Available）、柔性状态（Soft State）、最终一致性（Eventual Consistency）：

基本可用是指：分布式系统在出现故障的时候，允许损失部分可用性，优先保障核心可用。如：大促时，引导部分用户到降级页面。
柔性状态是指：允许分布式系统存在中间状态，且该中间状态不会影响系统整体可用性。如：允许异步机制，容忍不同节点间副本同步的延时。
最终一致性是指：系统中所有数据副本经过一定时间后，最终能够达到一致的状态。

BASE理论的核心思想是：既然无法做到强一致性，那么就采取合适的方法达到最终一致性。

ACID和BASE代表了两种截然相反的设计哲学。ACID是传统数据库常用的设计理念，追求强一致性模型；BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。

3.6 构建中台应避免哪些错误的理解？

服务最不需要“业务稳定”！

一个服务如果一味追求功能的不变，一定程度上就是固步自封，这样的做法是在逼着其他系统去建同样的“轮子”，当越来越多的系统都采用自建“轮子”的方式满足自身系统对这部分业务的需求时，之前的这个服务慢慢就少有人问津，当有更好的服务出现或该服务完全满足不了当前业务发展的要求时,也就是这个服务离开历史舞台的时刻。

服务需要的是不断改进，只有在新业务的滋养中才能从最初仅提供单薄业务功能的服务逐渐成长为企业最为宝贵的IT资产。

要点是：1.避免用项目制“建设服务能力”的误区，应有专门的组织机构来保障、长期建设；2.不能因为服务功能简单、不稳定、体验糟糕，就放弃使用这些服务，而是要不断优化。

SOA的理念过时了

SOA，即面向服务架构，该理念早已在业界非常流行。

早间传统软件厂商提出的以ESB(企业服务总线）实现SOA的方案为主流，这也是为什么几乎所有传统企业的客户都认为ESB是SOA理念的最佳实践，甚至是唯一的实现。因为ESB是一种“中心化”服务框架，所以大家认为SOA也过时了。

但先看看SOA的主要特性：

面向服务的分布式计算；
服务间松散耦合；
支持服务的组装；
服务注册和自动发现；
以服务契约方式定义服务交互方式。

可以看出SOA并没有定义一定是基于ESB总线的方式。所以，SOA的理念并不过时，可以理解为：ESB是SOA的“中心化”实现案例；中台是SOA的“去中心化”（分布式服务）实现案例。

4. 收获与行动

收获知识、付出行动、体现价值

4.1 啊哈

我的感受是，最大的浪费不是重复建设，而是不断重复建设。在早期往往一个新业务的上线除了数据可以被重复使用之外，服务却不能被重复使用。其实服务的重用将比数据重用带来更多好处，数据只是原始生产资料，服务则包含逻辑，是工厂的加工车间，如果加工过程也一样可以复制，将带来生产效率的大幅度提升。

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

科学证明，人数是7个人的团队协同效率是最高的。当团队进行作战时，最短时间内达成意见的统一和行动步调的一致，是团队强大战斗力充分展现的必要条件。

一个优秀的数据科学家需要具备的素质有：懂数据采集、懂数学算法、懂数学软件、懂数据分析、懂预测分析、懂市场应用、懂决策分析等。

架构设计本来就是一个追求平衡的艺术，不仅是设计原则上的平衡，还要在技术、成本、资源、性能、团队等各方面进行平衡。如果不能兼得，就需要最高效地解决主要问题。

服务化应从简单开始、不断优化，只有真实的业务需求才会锤炼出稳定可靠的共享服务。

4.2 下一步行动：在实际项目中运用

在实际项目中，把上述所学的要点，加以印证、运行。尤其是关注：

分布式消息系统：实现分布式事务处理；
分布式缓存系统：进一步增加吞吐量性能，支持秒杀活动；
分布式海量日志平台：提升数字化运营能力；
限流控制系统（集群）：实现流量调度、黑白名单等安全策略。

4.3 下一步行动：学习微服务入门

找到视频教学资源，学习微服务知识，并作出一个类“hello world”的案例。

再好的技术和框架如果不给企业带来业务价值，就没有意义。