阿里巴巴中台战略
构建服务共享体系，必然需要采用一套服务型框架来支持整个服务体系的运转。下面介绍淘宝从单一系统模式转化为服务化框架的过程。阐述为什么 “去中心化”服务框架成为今天绝大数互联网公司的选择。
-
淘宝平台“服务化”历程
2007年，淘宝已经拥有超过500人的技术团队规模，整个淘宝网站是个几百兆的war,大小功能包含200个。几百人维护一个war，主要有以下几个问题：
1） 项目团队协作成本太高，业务响应越来越慢
2） 应用复杂度已超过人的认知负载
3） 错误难于隔离
4） 数据库连接能力很难扩展
5） 应用扩展成本高
以上几个问题，一部分是成本问题，一部分是对于淘宝高速发展的业务能否做出快速稳定的支持；还有一部分问题则是直接决定了技术平台是否还能支持淘宝继续发展下去的关键问题。如果沿用原来的设计架构，很快达到瓶颈，无法再对业务做出支持。
解决以上问题的关键就在于业务拆分，但是解决这一问题的不二选择就是使用SOA。所以淘宝开始了一系列基于SOA理念的服务化改造。随后淘宝拆出用户中心、交易中心、类目中心、商品中心、店铺中心等核心业务模块。在部署上，由之前的一个war包拆分出上百个war包独立部署。
随着淘宝平台的改造，之前没有拆分的问题都得到很好地解决：
1） 降低不同模块开发团队间的协作成本，业务响应更加迅速。
2） 大大降低系统间的耦合度以及整体的复杂度，各个开发团队可专注于各自的业务模块。
3） 避免了各个模块错误给整体带来的影响。
4） 业务拆分后解放了对单个数据库集群连接数的能力依赖
5） 做到针对性的业务能力扩容，减少不必要的资源浪费。 -
“中心化”和“去中心化”服务框架的对比
当时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.
扫一扫
1170
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
