企业IT架构转型之道——阿里巴巴中台战略 第三章
下面进入书的第二部分,即共享服务体系搭建
这部分偏技术细节较多,其中挺多其实也是现在业务通行的做法
分布式服务框架的选择
-
早期的淘宝平台,如果真如书中的描述来看,真的惨不忍睹,至少腾讯电商10多年前已经至少是SOA了
-
项目团队间协同成本高,业务响应越来越慢
-
应用复杂度超出人的认知负载
-
错误难以隔离
-
数据库连接能力很难扩展
-
应用扩展成本高
-
-
淘宝新平台解决的问题
-
降低不同模块开发团队间的协同成本,业务响应更迅捷
-
大大降低系统间的耦合度以及整体复杂度,各个开发团队可以专注于各自的业务模块
-
避免了个别模块的错误给整体带来的影响
-
业务拆分后解放了对单数据库集群连接数的能力依赖
-
做到了针对性的业务能力扩容,减少不必要的资源浪费
-
中心化于去中心化服务框架对比
-
ESB模式的中心化服务架构的根本诉求——实现异构系统间的交互
-
去中心化分布式服务架构解决的问题——服务间交互没有单点,扩展性更好
-
为什么中心化方式不适合互联网
-
服务调用方式不同带来业务的响应和扩展成本
-
雪崩效应束缚了中心化服务框架的扩展能力
-
阿里巴巴分布式服务框架HSF
-
HSF包含的主要组件
-
服务提供者,一个虚拟机部署一个tomcat容器
-
服务调用者,
-
地址服务器,提供所有配置服务器和diamond服务器的列表信息
-
配置服务器,记录服务路由信息,推送路由信息到服务节点上,信息均保存在内存中
-
diamond服务器,通用的配置管理服务,给应用内部提供统一的配置设置和推送服务
-
-
HSF框架给服务提供的能力
-
采用Netty+Hession数据序列化协议实现服务交互
-
框架的容错机制,调用失败自动重试其他服务提供者,长连接秒级感知服务故障
-
框架的线性扩展支持,即可以平行扩展
-
微服务
-
Martin Fowler对于微服务架构典型特征的描述
-
分布式服务组成的系统
-
按照业务而不是技术来划分组织
-
坐有生命的产品而不是项目
-
智能化服务端点与傻瓜式服务编排
-
自动化运维
-
系统容错
-
服务快速演化
-
阿里巴巴构建共享服务体系过程中遇到的问题
-
微服务化的应用架构如何进行有效的服务管控
-
分布式服务难题
-
自动化运维和平台稳定性
-
微服务的服务设计
-
原有组织架构是否满足微服务架构持续发展的需要