阿里巴巴服务化架构演进
单一应用架构
All In One
整个网站几个应用
前台 web + 后台 ops + tasks
业务 web + service/dao 各自开发
一起集成发布
技术战：Webx、Spring Ibatis、Jboss、Oracle存在的问题：合并时经常代码冲突、发布相互制约效率低下、应用代码庞大臃肿维护困难。
垂直应用架构
按应用拆分Service / DAO / Impl 都以二方库 jar 包的形式提供出去
代码拆分，独立部署，流程隔离，技术栈没有太大变化
应用相互之间直接依赖二方库
问题：
升级困难，要全网推动
数据库连接池压力大
分布式服务架构
API 与实现分离
使用 RPC 进行通信，服务端升级方便
各种服务中心出现，会员中心，商品中心，交易中心等
技术栈：
Ali-tomcat
Pandora
Dubbo
HSF
存在的问题：
依赖冲突
中间件升级困难
应用配置服务
应用开发效率低下
微服务架构
拥抱微服务，提升开发体验和效率
应用更轻量、开发更简单
配置
编码
开发
调试
部署
技术栈：
Pandora Boot
Spring Boot
容器隔离Pandora
为什么需要隔离？
Pandora的容器架构如下：
Pandora 结构与部署形式：
与应用 tgz 包部署在一起
应用可单独升级 pandora.sar
应用容器识别 –Dpandora.location，便于本地开发
现有架构的不足：
pandora 使用方式新人难理解，本地开发麻烦，需要配置 JVM 参数或借助 IDE
mvn 依赖与 pandora 实际运行版本不一致导致调试时行号对不上，或源码找不到
pandora.sar 全家桶用户无法按需选择，应用启动慢
新应用创建时多为复制老应用，遗留问题始终得不到清理解决，形成恶性循环
启动脚本、自检、dockerfile 配置、上线流程复杂繁琐
应用状态不透明，容器及中间件状态是黑盒
微服务框架 Pandora Boot
微服务运维及诊断
未来发展方向
Spring Boot 2.0
JDK9 Jigsaw
Serverless/RxJava
