《企业架构转型之道-阿里中台战略思想与架构实践》读书心得

    最近团队组织研讨关于系统服务化迁移的工作，找机会学习了一下钟华的阿里中台战略思想与架构实践，全书分三部分，分别介绍了阿里中台战略起源、共享事业部发展过程；阿里共享服务体系搭建实践；以及国内其他传统企业服务化转型实施，也是阿里中台战略实施后的能力输出。

    整体看完了全书三大部分内容，今天的学习作业主要总结记录书中前四章，两大块内容，其一是关于阿里中台起源、共享事业部发展历程、服务化架构相比传统架构优势及价值所在；其二，关于阿里分布式服务框架、共享服务中心的建设原则；这四章的内容对于当前我们处在服务架构研讨、选型有非常大的指导意义。后面章节内容技术性比较强，主要介绍how层面的内容，具体如何实践，内容包括分布式数据库数据拆分和数据库能力扩展、异步化缓存、服务化运营能力和平台建设、服务平台稳定性等，这对于后续我们实施中台及服务中心建设是有非常大的借鉴和学习意义的，建议我们的技术和业务架构人员学习。

    阿里中台战略思想起源阿里高层15年拜访Suppercell公司说起，Suppercell是一家位于芬兰、好称世界上最成功的移动游戏公司，以部落战争、海岛奇兵等游戏闻名，16年被腾讯以86亿美金收购超过80%的股份，公司人数总共不超过200人，人均贡献价值超过3.5亿人民币。而他们正是采用中台的思想，在6年成长及开发过程中，对于公共、通用游戏开发素材、算法做了很好的沉淀；一般来说，他们2或5名、最多不超过7人的团队，能够在两三周的时间内快速推出游戏公测版本试用，然后看是否受用户欢迎，如果用户不欢迎，能快速放弃，这中间没有任何管理人员介入，能够快速试错，产品失败非但不会受到惩罚，有时甚至还为失败举办庆祝仪式；这些快速响应、应对变化的能力正是归功于他们强大的中台能力，这一点，在当时给阿里高层很大的震撼，所以阿里集团在拜访结束的半年后正式启动“2018年中台战略”，伴随着的是组织架构的变化和调整，也诞生了阿里集团同淘宝、天猫事业部并驾齐驱的共享服务事业部，它正是今天我们学习模仿的对象。

    共享事业部的发展历程能清晰的折射出当前国内很多传统企业的信息中心面临的窘境，IT部门在公司内部始终作为支撑团队，没有话语权，在夹缝中艰难的生存着，纠其原因作者认为是因为我们的IT根本不懂业务；这个观点可能很多人并不认同，因为我们认为对于自己负责的业务系统，无论是在流程、操作、数据模型上，IT人员都比业务更懂；所以作者说他指的懂业务是指：能对业务下一步的发展有自己的理解和看法，对业务流程如何进一步优化能更好地提升业务，甚至对企业现有的业务提出创新的想法，给企业带来业务增长点。

      纠其症结在于我们传统项目制系统建设的模式上是“烟囱式”的业务系统架构，这让IT信息化部门一直处于“业务支持”的职能位置，大多数员工关注项目管理、紧盯进度，一个项目上线后又开始投入到下个项目中，我们在特定专业领域的知识得不到沉淀，慢慢的随着时间流逝，我们失去了对工作的积极性和创造性，对业务知其然，而不知其所以然，更谈不上业务领域专家，也不可能对业务发展有创新想法和独到见解，阿里当时的业务系统建设模式、组织架构模式包括遇见的问题，跟我们很多企业都是一样的，所以他们如何摆脱这样困境的成功实践是我们当今还在困境中的企业应该去学习和借鉴的。

      阿里伴随着几大电商平台的发展而进步，天猫成立是从淘宝的一个部门开始的，后面业务逐渐壮大才剥离出来独立运作，而IT技术团队起初也是由淘宝开发团队同时支撑着，我们都知道“屁股决定脑袋的道理”，这样模式导致天猫业务团队对IT支持怨声载道，信息化跟不上业务的发展；在这样的背景下集团成立了共享事业部，接下来的发展却事与愿违，组织架构上共享事业部和天猫、淘宝平级，但对业务理解和业务贡献来说没有话语权，结果就是共享事业部在天猫和淘宝两大业务部门的需求下艰难的生存着，而此时系统建设模式也还是之前传统烟囱式的建设方式，这样的方式最大的弊端在于：1、重复功能建设和维护带来的重复投资；2、打通“烟囱式”系统间交互的集成和协作成本高昂；3、不利于业务的沉淀和持续发展。传统ESB服务建设模式本质的问题是系统所提供的服务能力根本没有随着企业业务的发展而得到与时俱进。2010年出现了历史性转折，当时团购盛行，聚划算的出现让这一切出现改变，淘宝天猫都希望能业务上接入聚划算平台，当时集团就要求无论淘宝、天猫需要跟聚划算平台进行业务对接，必须通过共享事业部，阿里“厚平台薄应用”服务化架构建设也正是从这时候开始迈出重要的一步。

      共享服务架构的建设使阿里摆脱了“烟囱式”系统建设方式带来的发展桎梏，最终成为阿里中台战略的核心组成；我们知道服务的本质是重用，所以SOA最核心的价值是：松耦合的服务带来业务的重用，通过服务的编排助力业务的快速响应和创新；传统上我们无论从开发和运营上都期望服务是稳定的，而作者认为，服务的本质是要应对变化，服务需要不断的业务滋养，服务是最不需要业务稳定的；所以传统服务建设的方式会不断面临推到重建的遭遇；共享服务体系需要业务快速创新和试错的能力；而大数据服务平台也将给企业创新发展、业务和营销决策提供强有力支撑。共享服务体系的建设，伴随着人员组织架构的调整，让信息中心部门从之前“业务支持”的组织职能，转变为基于企业核心业务和数据进行运营的团队，这个团队会更快更好地支持业务发展的同时，逐步掌握企业最核心的业务和数据，逐步培养出企业最稀缺的“既懂业务，又熟悉技术”的复合型人才，作者认为这样的人才我们无法寄希望于外部招聘或者业务单位能培养出来；在将来，企业核心的业务和数据将是企业运营最为宝贵的资产。

    阿里共享服务体系搭建，依赖一套服务化框架来支撑运转，HSF分布式服务框架正是阿里的选择，这是一套“去中心化”的服务框架，“去中心化”分布式服务框架最重要的不同就是服务提供者和服务调用者之间在进行服务交互时无需通过任何服务路由中介，这就避免了因为中心点带来的平台能力难以扩展的问题，存在潜在的“雪崩”影响，ESB总线框架最大的局限性就在于总线的扩展性，这是传统企业架构暴露出来的硬伤。，而“中心化”或“去中心化”的服务框架都是SOA的实现，本身没有优劣之分。

    关于阿里HSF分布式服务框架，包括以下主要组件：1、服务提供者：在服务框架中真正提供服务功能实现的应用实例，为保障高可用性，一般是集群部署；2、服务调用者：作为服务的消费方，一般以独立应用运行在容器中；3、地址服务器：在HSF中肩负着给服务提供者和调用者提供部署环境中所有配置服务器和Diamond服务器的服务器列表信息，一般由Nginx提供该服务能力；4、配置服务器：主要负责记录环境内所有服务发布、服务订阅信息，并将服务相关信息推送到服务节点上，为了保证效率，一般服务发布和订阅信息都保存在内存中；5、Diamond服务器：是一个通用的统一配置管理服务，给应用提供统一的配置设置和推送服务；主要承担服务调用过程中对于服务调用安全管控的规则、服务路由权重、服务QPS阈值等配置规则；6、服务节点对配置服务器列表的获取：服务调用者和服务提供者以域名的方式获取到可用的地址服务器，包括配置服务器和Diamond服务器IP列表；7、服务的注册发布：服务提供者向配置服务器发送当前应用中服务提供者相关信息（包括：接口全名、服务版本、服务组等），连同服务器IP、端口等信息进行服务注册发布；8、服务的订阅：服务调用者启动时与配置服务器交互，发送服务消费者相关信息到配置服务器进行服务的订阅；9、服务规则的推送（如果需要）：对于需要服务安全管控、流量控制时，使用Diamond服务器管控；10、服务交互：服务调用者从当前节点已经保存的服务提供者服务器列表中选择其中一台进行点对点服务请求发送。

    在阿里战略中，共享服务中心是中台架构基石，如何构建稳定可靠、高效的支撑上层业务快速创新的共享服务能力是中台战略成功落地的关键。而共享服务中心提供的服务能力包括两个层次：第一个层次是底层PaaS能力，解决大型架构在分布式、可靠性、可用性、容错、监控及运维层面上的通用需求；第二个层次是业务能力，这块直接决定了能否真正支持上层业务达到敏捷、稳定、高效。

      关于服务中心，概念上有几点：1、服务中心一定是不断发展的；2、服务中心中的服务形态存在多样性；服务能力不拘泥于形式，主要分为三类：依赖于接口的服务、依赖于工具的服务、依赖于数据的服务，形式上可能有接口类，也可能有界面类形式；3、服务中心是可以进一步划分的；

    服务中心的划分原则，从设计上需要兼顾三方面需求：1、设计层面：要遵循面向对象的分析和设计方法，即业务和系统建模遵循面向对象的基本原则；2、从运营层面：服务中心是一个完整的业务模型，要有数据运营和业务整合的价值；3、从工程层面：共享服务的架构是基于分布式架构，分布式架构解决一体化架构在大规模应用的问题。

    所以阿里总结出来的设计基本原则有：1、高内聚、低耦合原则；2、数据完整性原则；3、业务可运营行原则，我们期望服务中心承载业务逻辑、沉淀业务数据、产生业务价值的业务单元；4、渐进性建设原则，推荐服务从简单开始，只有真实的业务需求才会锤炼出稳定可靠的共享服务。

    以上内容正是关于阿里中台共享服务在WHY、WHAT两个层面相关内容，后面章节更多涉及如何实施，也就是HOW层面的内容，涉及比如数据库拆分、异步化与缓存原则、打造数字化运营能力、打造平台稳定性能力，技术性比较强，建议技术人员深入学习。