最近在读一本书，叫做《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》，在写此文时本书还没有看完，因为担心如果把书全部看完后再来写这篇文章，很多精彩的内容可能已经忘记了，所以中途先写一篇来分享给大家。
中台战略
阿里巴巴在2003年成立的淘宝事务部，如图一。
2008年，B2C业务火热，阿里巴巴成立天猫，初期叫淘宝商城，当时作为淘宝事业部中的一个部门运营，如图二。
随着B2C业务的不断增加，天猫开始独立，阿里巴巴单独成立了天猫事业部，与淘宝事务部并列，如图三，此时淘宝技术部分同时支持着两大事业部，这种组织架构决定了技术团队肯定会优先满足来至淘宝的业务需求，严重影响了天猫业务的发展。用过天猫和淘宝的人应该都能发现天猫和淘宝这种电商平台都包含了商品、交易、评价、支付、物流等功能。
2009年，共享业务事业部应运而生，主要成员来至淘宝技术团队，在组织架构上单独成为了一个跟淘宝、天猫同样级别的事业部，如图四。集团希望能通过这种方式让技术团队同时支持天猫和淘宝业务，同时对公共的、通用的业务进行沉淀，更合理的利用资源。
但是实际上在当时共享业务事业部是“听命于”天猫和淘宝，共享业务事业部需要同时满足者天猫和淘宝的大量需求，团队成员经常加班加点可能也达不到天猫和淘宝的需求，这样就导致天猫和淘宝的业务部门对共享业务事业部不太满意，同时共享业务事业部的同事也只能有苦说不出。
2010年，团购业务聚划算出现了，聚划算拥有强大的流量吸引能力，所以天猫、淘宝、1688都想对接聚划算平台从而扩大自己的流量，聚划算突然面对这么大的对接需求也是应接不暇，这时集团要求三大电商平台如果要对接聚划算平台，必须通过共享业务事业部！正是有了这个政策，使得共享业务事业部有了一个极强的业务抓手，将原本与三大电商平台话语权的不平衡拉到了一个相对公平的水平。从而奠定了今天大家所看到的共享业务事业部成了阿里巴巴集团业务中的核心业务平台，如下图：
上图清晰的描述了阿里巴巴“厚平台，薄应用”的架构形态，而共享业务事业部正是“厚平台”的真实体现，“厚平台”为阿里巴巴各种前端业务提供了最为专业、稳定的业务服务，这就是中台。我们可以发现中台战略并不是一蹴而就，2009年开始建立共享业务事业部时，就已经为中台战略打下了一定的基础，但同时也需要集团的强力支持才能将中台搭建起来，一旦中台成形，就为业务的腾飞打下了坚实的基础。
烟囱式架构
2008年淘宝的技术团队同时支持着淘宝和天猫两大电商平台，同时1688有自己的技术团队，架构如下图：
这种架构就是烟囱式架构，每个业务部门和他们对应的业务部门像烟囱一样伫立在那里，并且如果依照这个架构，当企业需要扩展新业务时，就会出现一个新的业务部门以及对应的新的技术部门，也就是多了一个烟囱。那么这种架构到目前为止其实还是有很多企业是这样的，这种架构之所以出现肯定是有它的好处：
企业考虑到业务模式不同，所以独立建设
新的业务团队认为在之前的业务的基础上改造会有太多的技术和业务的历史包袱，还不如重新构建
只是这种架构的缺点要远大于它的优点：
重复功能建设和维护带来重复性的工作和投资。重复建设能给企业减少风险，但是会增加重复的成本。
“烟囱式”系统间如果要进行交互，那么协作的成本是高昂的。
不利于业务的沉淀和持续发展。一个烟囱上线后进入到了运维阶段，此时如果需要在此基础上去修改业务到发布业务会需要一段很长的时间。
在互联网时代，更好的整合企业内部资源、降低企业成本、实现各个系统间的交互是必然的。面对这种情况，2004年，业界就已经提出了SOA理念来解决“烟囱式”系统间交互的问题。
SOA
SOA的核心功能点：
面向服务的分布式计算
服务间松散耦合
支持服务的封装
服务注册和自动发现
以服务契约的方式定义服务交互方式
中心化的SOA
很多企业都是通过ESB来实现SOA的，这是一种中心化的SOA。
ESB是企业服务总线，顾名思义，ESB系统能够对企业里的各种各样的服务进行统一管理，ESB的架构很好的屏蔽了服务接口变化给服务消费者带来的影响，是解决不同系统间实现互联互通的很好的架构，如下图：
2004年，很多大型软件公司已经发现，越来越多的企业在多年的IT建设过程中，逐渐构建了越来越多的IT系统，这些IT系统都是采用烟囱式系统建设模式而建立的，使得企业内的系统纷繁林立，这些系统有的是购买商用套件，有的是自主研发，有的是找外包公司所开发，最终的结果就是各个系统所采用的技术平台、框架、语言各不相同。所以软件公司就开发出了ESB系统来帮助这些企业解决这些问题。
服务提供方只需在ESB系统上定义好接口以及该接口的访问路径即可，具体谁是这个服务的消费它不需要关心了，并且对于这个服务的修改只需要在ESB中进行一次调整，便实现了对服务接口变化带来影响的隔离。ESB降低了系统间的耦合，更方便、高效的实现了系统的集成，同时在服务负载均衡、服务管控等方面提供了相比“点对点”模式更专业的能力。
ESB提供了诸如对各种技术接口（HTTP、Socket、JMS、JDBC等）的适配接入、数据格式转换、数据剪裁、服务请求路由等功能，目的是让企业客户能基于这些功能提高开发效率，更快的实现项目落地。
所以，ESB的方式成为这一时期的SOA实现的主流，它很好的解决了异构系统之间的交互。
去中心化的SOA
“去中心化的SOA”是由互联网行业带来的，因为在互联网行业中用户群体是整个互联网公众，所以系统架构设计人员首先要解决的是系统扩展性的问题，以更快的进行业务响应、更好的支持业务创新等。
所以“去中心化”除开满足SOA的核心功能点之外，还要避免“中心化”带来的难扩展性问题，以及潜在的“雪崩”影响。
“去中心化的SOA”是一种“点对点”的架构，它没有中心，如下图：
那么可能有疑问，SOA的出现是为了解决烟囱式架构所带来的问题，而烟囱式系统之间的调用就是“点对点”的呀，这样不是在倒退吗？在互联网行业，去中心化服务框架是运行在企业内部的，很少出现跨内外网的服务交互，另外服务是以契约先行的方式进行了服务接口功能的约定，在某种程度上很好的保障了服务接口的稳定性，同时去中心化服务框架加上对多版本、负载均衡等功能的支持，从本质上屏蔽掉了之前“点对点”模式下的各种系统不稳定问题。
在“中心化架构”中，整个架构的中心是ESB，所有的服务调用和返回都要经过ESB，这样服务调用者在调用某个服务时多了很多的网络开销，而在“去中心化架构”中则不会出现这个问题。
另外，所有的服务调用都经过ESB，所以ESB进行集群部署是必然的，另外为了保障ESB不会出现问题，部署ESB系统的服务器配置或网络配置也会更好，这使得一旦企业想扩容ESB时，会带来软件和硬件上成本的显著增加。
另外就算ESB系统使用集群部署以保障高可用，但还是可能出现“雪崩”效应，一旦出现“雪崩”就会导致企业中所有服务都不可用。
雪崩
我们假设ESB集群中每台服务器最大的并发量为100，假设现在集群中有10台服务器，在日常用户请求量平稳的时候，经过负载均衡后每台服务器平均的并发量为80，但是如果集群中某一台服务器突然出现故障，此时就需要另外9台来承担之前的并发量，那么剩余的9台服务器的并发量就会增加，从而很有可能导致9台中的某一个服务器被压垮，从而导致剩余的8台服务器相继被压垮，这就是“雪崩”。而一旦出现“雪崩”故障，就算你去重启服务器也是很难解决的，因为很有可能服务器刚启动完成就被流量所压垮，所以这个时候你只能禁止外界的流量流入你的系统中，等所有服务器都成功启动后再放流量进来。并且当出现这种情况时，你可能都没有时间去定位问题所在，重新启动好的集群实际上还是在一个“脆弱”的状态。
这就表示“中心化”架构不能很好的解决系统扩展性这个问题，而“去中心化”的架构则会更好，因为就算出现上面这种情况，也不会影响所有服务。所以这就是为什么互联网行业会选择“去中心化”架构。
下面我们介绍阿里巴巴分布式服务框架HSF，等我看完再继续吧...哈哈。
有痛点才有创新，一个技术肯定都是为了解决某个痛点才出现的。
想要这本书的朋友转发＋关注然后私信回复“架构”，我可以送您一本完整的书籍PDF文档。
当然更加支持购买实体书，获得文档后看着觉得有收获的朋友也可以购买支持！
《Java学习、面试；文档、视频资源免费获取》