读《阿里巴巴中台战略思想与架构实战》有感

最近在读一本书，叫作《企业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，等我看完再继续吧...哈哈。

有痛点才有创新，一个技术确定都是为了解决某个痛点才出现的。 请帮忙转发一下，若是想第一时间学习更多的精彩的内容，请关注微信公众号：1点25