阿里巴巴中台战略--分布式服务框架的选择
阿里巴巴中台战略
构建服务共享体系，必然须要采用一套服务型框架来支持整个服务体系的运转。下面介绍淘宝从单一系统模式转化为服务化框架的过程。阐述为何 “去中心化”服务框架成为今天绝大数互联网公司的选择。web
-
淘宝平台“服务化”历程
2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是个几百兆的war,大小功能包含200个。几百人维护一个war，主要有如下几个问题：
1） 项目团队协做成本过高，业务响应愈来愈慢
2） 应用复杂度已超过人的认知负载
3） 错误难于隔离
4） 数据库链接能力很难扩展
5） 应用扩展成本高
以上几个问题，一部分是成本问题，一部分是对于淘宝高速发展的业务可否作出快速稳定的支持；还有一部分问题则是直接决定了技术平台是否还能支持淘宝继续发展下去的关键问题。若是沿用原来的设计架构，很快达到瓶颈，没法再对业务作出支持。
解决以上问题的关键就在于业务拆分，可是解决这一问题的不二选择就是使用SOA。因此淘宝开始了一系列基于SOA理念的服务化改造。随后淘宝拆出用户中心、交易中心、类目中心、商品中心、店铺中心等核心业务模块。在部署上，由以前的一个war包拆分出上百个war包独立部署。
随着淘宝平台的改造，以前没有拆分的问题都获得很好地解决：
1） 下降不一样模块开发团队间的协做成本，业务响应更加迅速。
2） 大大下降系统间的耦合度以及总体的复杂度，各个开发团队可专一于各自的业务模块。
3） 避免了各个模块错误给总体带来的影响。
4） 业务拆分后解放了对单个数据库集群链接数的能力依赖
5） 作到针对性的业务能力扩容，减小没必要要的资源浪费。spring -
“中心化”和“去中心化”服务框架的对比
当时SOA 的理念已经很是流行，其中以传统软件商提出的以ESB实现SOA的方案为主流。这就是为何几乎全部传统企业的客户都认为ESB是SOA理念的最佳实践。这是一种“中心化”的服务框架。
有人认为“去中心化”不是SOA架构，咱们再看一下SOA的主要特征：
1） 面向服务的分布式计算
2） 服务间松散耦合
3） 支持服务的组装
4） 服务注册和自我发现
5） 以服务契约方式定义服务交互方式
因此 “去中心化”一样符合SOA的定义，也是SOA架构。“中心化”和“去中心化”并无优劣之分，只是不一样企业的需求不一样。
1） ESB模式的“中心化”服务架构的根本诉求。
2004年左右大部分公司都采用“烟囱式”的系统建设模式，使得公司内各类系统纷繁林立，这些系统有的是购买商用软件，有的是自主研发，最终各个各个系统采用的技术平台、架构、开发语言各异。须要实现这些系统间的交互时，SOA架构相比经过系统间的“点对点”直接互通的模式，很好避免了由于此服务提供者服务接口的变化须要调用此服务的服务调用者都进行修改的现象。而只须要在ESB上进行一次调整，便实现对服务调用变化带来影响的隔离。
2）“去中心化”分布式服务架构解决的问题。
“去中心化”框架除了解决对SOA特性的实现和知足外，相比中心化的架构最重要的不一样就是服务提供方和服务调用者之间不须要任何的服务路由中介。避免由于 “中心点”带来平台能力难扩展问题，以及潜在的“雪崩”影响。“去中心化”更适用于运行在企业内部网络环境中（即不会出现内外网的服务交互），基于统一的技术接口标准、网络协议、规范进行交互。
两种架构给业务带来的影响对好比下：
1）服务调用方式的不一样带来业务的响应和扩展成本
每一次服务交互的路线以下：
2） “雪崩”效应束缚了“中心化”服务框架的扩展能力
举个例子，若是服务总线集群数量须要10台，当达到服务峰值时，每台企业服务总线的负载水平会达到80%，平常运行通常不会出问题。可是，若是某一个应用由于不规范的缘由出现故障，没法提供服务路由。这时压力就落在剩下的9台服务器上。这时每台负载水位就超过88%，个别服务可能更高。在服务器高水位运行时，出问题的概率就会增大。若是其中一台再出问题，剩下的8台就不会一台一台的出问题，而是一瞬间所有宕机。这就典型的“雪崩”效应。出现这种问题，故障修复的时间和成本都比较高昂，由于不能一台一台重启，只能所有重启好以后再提供服务。数据库 -
微服务
说到分布式框架，不得不提“微服务”。
微服务典型特征描述以下：
1） 分布式服务组成的系统
2） 按照业务而不是技术划分组织
3） 作有生命的产品而不是项目
4） 智能化服务端端点与傻瓜式服务编排
5） 自动化运维
6） 系统容错
7） 服务快速演化
从本质上说，微服务是SOA的一种演化后的形态。与SOA的方法和原则没有本质的区别。
如今不少企业使用阿里提供的dubbo框架，也有不少企业使用springCloud.服务器