3.1、淘宝平台“服务化”历程
大约2007年，淘宝500人团队，维护一个war包，200多个功能模块。
1）项目团队协同成本高，业务响应越来越慢
2）应用复杂度超出人的认知负载。
3）错误难于隔离【同一个环境，一个jvm】
4）数据库连接能力很难扩展：每一个机器只有10个，但是应用机器过于多，也达到了5000多连接
5）应用扩展成本高
2007年10月，开始进行基于SOA理念新一代服务化框架研发以及采用业务模块逐步迁移的方式进行应用架构的改造。在未来的14个月中将单一应用模式改造成基于SOA理念的分布式服务架构。在应用部署上，由之前一个几百兆的war包部署模式改造成上百个war包独立部署的服务化框架。结果是：
降低不同模块开发团队间的协同成本，业务响应更迅捷。
大大降低系统间的耦合度以及整体复杂度，各个开发团队可专注各自的业务模块。
避免了个别模块的错误给整体带来的影响。
业务拆分后解放了对单数据库集群连接数能力的依赖。
做到针对性的业务能力扩容，减少不必要的资源浪费。
3.2、中心化 与 去中心化 服务框架的对比
SOA主要特性：
面向服务的分布式计算
服务间松散耦合
支持服务的组装
服务注册和自动发现。
以服务契约方式定义服务交互方式
传统的SOA是以基于ESB总线方式，而互联网是以去中心化服务框架。
1）ESB模式的中心化服务框架的根本诉求
实现异构系统之间的交互
2）去中心化分布式服务架构解决的问题
一般是运行在企业内部网络，基于统一的技术接口标准，网络协议，规范进行交互，已使服务的交互效率最高。
对比
1.服务调用方式的不同带来业务的响应和扩展成本。
每一次的交互过程：服务调用者→ESB（接收服务请求）→服务提供者（服务处理）→ESB（服务提供者返回结果）→服务调用者（服务返回）
经过服务总线路由过的服务交互，共出现4次网络回话创建和数据传输，而去中心化服务框架中服务交互，一次服务的调用只有两次网络会话创建和数据传输，在网络上的开销减少了一半。
2.雪崩效应束缚了中心化服务框架的扩展能力
3.3、分布式服务框架HSF、Dubbo
HSF服务框架包含以下主要组件：
服务提供者，在服务框架中真正提供服务功能实现的应用实例，一般是集群部署，每一个HSF的应用均是以war包形式存在，运行在阿里优化定制的tomcat容器中，在tomcat容器层集成了HSF服务框架对服务提供者或者服务调用者进行配置服务容器发现、服务注册、订阅、失效转移等相关功能。只需配置即可，无需引入jar依赖包。
服务调用者，同服务提供者类似。
地址服务器，在HSF服务框架中肩负着给服务提供者和服务调用者提供部署环境中所有配置服务器和DIamond服务器的服务器列表信息。是由Nginx提供该能力。再部署HSF服务环境时，会将整个环境中的配置服务器集群（服务器IP列表）和Diamond服务器集群信息设置在地址服务器上，在实际生产部署中，也会部署多台地址服务器提供负载均衡和高可用性的服务，服务提供者会通过统一域名的方式访问这些地址服务器，通过DNS轮询，实现地址服务器访问的高可用。
配置服务器，配置服务器主要负责记录环境内所有服务发布（服务提供者的IP地址和服务端口信息）和服务订阅（服务调用者的IP地址和服务端口信息）信息，并将服务相关信息推送到服务节点上。为了追求服务发布和订阅推送效率，所有的服务发布和订阅信息均是保存在内存中。
Diamond服务器。是一个通用的统一配置管理服务（类似zookeeper）给应用提供统一的配置设置和推送服务。
HSF优点：
1、采用Netty+Hession数据序列化协议实现服务交互
2、容错机制
3、线性扩展支持，启动容器后自动注册
3.4、关于微服务
1.1、Martin Fowler描述：
1、分布式服务组成的系统
2、按照业务而不是技术划分组织
3、做有生命的产品而不是项目
4、智能化服务端点与傻瓜式服务编排
5、自动化运维
6、系统容错
7、服务快速演化
1.2、微服务面对的问题
1、微服务化的应用架构如何进行有效的服务管控
2、分布式事务难题
3、自动化运维和平台稳定性
1.3、微服务要求
1、服务设计：服务边界的划分一定是从业务的维度。
以什么样的服务颗粒定义服务。以什么样数据模型支撑服务能力的线性扩展？如何保持设计出的服务具有很好的业务前瞻性？在满足业务需求下，服务能力的通用性？其他业务接入的扩展能力？
2、原有组织架构是否满足微服务架构持续发展的需要。