云原生学习路线导航页（持续更新中）

本文是 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就是它的网关