阿里巴巴微服务架构演进
阿里巴巴服务化架构演进
单一应用架构
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
声明：本号所有文章除特殊注明，都为原创，公众号读者拥有优先阅读权，未经作者本人允许不得转载，否则追究侵权责任。
关注我的公众号，后台回复【JAVAPDF】获取200页面试题！
5万人关注的大数据成神之路，不来了解一下吗？
5万人关注的大数据成神之路，真的不来了解一下吗？
5万人关注的大数据成神之路，确定真的不来了解一下吗？
