持续进化 | 阿里巴巴服务化架构演进

大数据技术与架构点击右侧关注，大数据开发领域最强公众号！

暴走大数据点击右侧关注，暴走大数据！

作者：朱勇，目前在阿里巴巴从事应用容器和微服务框架的开发、实施以及效率提升相关的工作。

阿里巴巴服务化架构演进

单一应用架构

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

欢迎点赞+收藏+转发朋友圈素质三连

文章不错？点个【在看】吧！ 👇