本文是 Docker核心技术 系列文章:应用架构演进,其他文章快捷链接如下:
- 应用架构演进(本文)
- 容器技术要解决哪些问题
- Docker的基本使用
- Docker是如何实现的
1.1.架构演进过程
![在这里插入图片描述](https://i-blog.csdnimg.cn/direct/22331c844e344a938c3d021b73a7dcc0.png)
单体架构
- 一个非常大的项目,如果是单体,经过长时间演进之后,没人知道哪一个模块是干什么的,哪个模块是谁负责的 。变更将会特别困难,没人敢做更改。
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就是它的网关