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