阿里巴巴服务化架构演进

阿里巴巴服务化架构演进

单一应用架构

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
• 云原生
• Serviceless
• ServiceMash