第3章 分布式服务框架的选择

第二部分 共享服务体系搭建

共享服务体系对服务中心的稳定性, 服务能力扩展性, 服务需求的快速响应能力提出了前所未有的要求, 需要有一套成熟,完善的技术体系来支持整个共享服务体系

第3章 分布式服务框架的选择

3.1 淘宝平台"服务化"历程

几百个人维护一个WAR包模式带来的主要问题

1. 项目团队间协调成本高, 业务响应越来越慢
2. 应用复杂度已超出人的认知负载

cb154abce7784468b711202a2b7d8eb2_image.png

3. 错误难于隔离
4. 数据库连接能力很难扩展

0f328f7944064c74b23a75cc0375f1fa_image.png

5. 应用扩展成本高

只能以整个WAR包的方式扩展

服务化改造之后问题都得到了很好解决

1. 降低不同模块开发团队间的协同成本,业务响应更迅捷
2. 大大降低系统间的耦合度和复杂度, 各开发团队专注于各自的业务模块
3. 避免个别模块的错误给整体带来的影响
4. 业务拆分后解放了对单一数据库集群连接数能力的依赖
5. 做到针对性的业务能力扩容, 减少不必要的资源浪费

3.2 "中心化"与"去中心化"服务框架对比

 中心化服务框架: dubbo等
 去中心化服务框架: ESB企业服务总线

SOA主要特性

1. 面向服务的分布式计算
2. 服务间松散耦合
3. 支持服务的组装
4. 服务注册和自动发现
5. 以服务契约方式定义服务交互方式

两套服务框架的根本诉求不一致

 中心化服务框架: 实现异构系统之间的交互
 去中心化服务框架: 扩展性是去中心化服务框架的首要因素

两种架构给业务带来的影响

1. 服务调用方式不同带来业务响应和扩展成本

5191a74b91dd4038b756720dab7faa0b_image.png

①服务调用者→②ESB（接受服务请求）→③服务提供者（服务处理）→④ESB（服务提供返回结果）
→⑤服务调用者（服务返回）

ff18ba3eab404c39a0f5c3e1a2524ce3_image.png

2. "雪崩"效应束缚了"中心化"服务框架扩展能力

3.3 阿里巴巴分布式服务框架HSF

c48ffc0015694e5b86e417e3a59abd92_image.png

1. 服务提供者
2. 服务调用者
3. 地址服务器: 给服务提供者和服务调用者提供配置服务器和Diamond服务器列表
4. 配置服务器: 记录所有服务发布和服务订阅的信息(IP+端口)
5. Diamond服务器: 通用佩服服务器类似阿波罗(承担了:安全管控规则,服务路由权重,服务QPS阈值等)

HFS如何提提供服务能力

1. 采用Netty+Hession数据序列化协议实现服务交互
2. 容错机制: 同一服务一定有多个提供者, 服务调用者在超时等情况时选择其他可用服务再次请求

8c7c68c2a3784cca9feb4446296067bd_image.png

3. 线性扩展支持: 

92df311d09e9493499413a20d01e5f0f_image.png

8d3bb4c2c0284e3dbd94e1ab8b3e81ec_image.png

0237345904904387ac81eb2531d6dea3_image.png

3.4 关于微服务

微服务架构的典型特征

1. 分布式服务组成的系统
2. 按照业务而不是技术划分组织
3. 做有生命的产品而不是技术
4. 智能化服务端点与傻瓜式服务编排
5. 自动化运维
6. 系统容错
7. 服务快速演化

企业微服务架构建设过程中会遇到的问题

1. 如何进行有效的服务管控
2. 分布式事务难题
3. 自动化运维和平台稳定性
4. 微服务的服务设计
5. 原有组织架构是否满足微服务架构持续发展