Docker核心技术：应用架构演进
云原生学习路线导航页（持续更新中）
本文是 Docker核心技术 系列文章：应用架构演进，其他文章快捷链接如下：
- 应用架构演进（本文）
- 容器技术要解决哪些问题
- Docker的基本使用
- Docker是如何实现的
1.1.架构演进过程
-
单体架构
- 一个非常大的项目，如果是单体，经过长时间演进之后，没人知道哪一个模块是干什么的，哪个模块是谁负责的 。变更将会特别困难，没人敢做更改。
-
SOA架构
- 随着业务的复杂，架构在演进，IBM后来推进了 SOA 架构模式
- SOA（Service-Oriented Architecture，面向服务的架构），快速了解可以看https://bbs.huaweicloud.com/blogs/315752
- 所有服务之间使用ESB（Enterprise Service Bus，企业服务总线）相互调用
- 缺点：长期以往，ESB又变成了一个大的单体服务了 ，ESB的升级和变更也变得不可维护。因此SOA后来也凉掉了
-
微服务架构
- 微服务架构可以理解为 SOA 的最佳实现，基于轻量级的网络调用，比如REST API
- 强调把服务打散，服务粒度要比SOA更小，一个团队负责一个或几个服务。这样就有人为一个服务的完整生命周期负责了
- 面临的挑战：
- 有大量的网络调用
- 每个服务很小，用的资源也很少，因此一台物理机肯定会部署很多个服务，提升资源利用率。不过在一台机器上，进程间隔离性差，容易互相影响
- 虚拟化技术的出现
- 后来，将一台物理机划分为多个虚拟机，每个服务部署在一台虚拟机里，解决了隔离性问题
1.2.传统分层架构 和 微服务架构对比
- 分层架构
- 优点
- 部署测试很简单，因为只有一份代码，构建出来也只有一个进程
- 横向扩展容易，多来几台机器就可以，部署同样的代码就行
- 缺点
- 程序太大了，部署、启动很慢，任何变更都需要完整的重新部署
- 优点
- 微服务架构
- 优点
- 适合复杂架构，拆分原则：高内聚低耦合
- 微服务体量小，启动速度快
- 各个功能之间边界更清晰，可以调整公司组织架构，配合应用的结构，让具体的人为具体的功能负责
- 缺点
- 带来复杂性
- 带来复杂性
- 优点
1.3.微服务改造的原则
1.4.微服务之间的通讯：点对点、API网关
- 比如：kubernetes的api-server就是它的网关