常见的应用架构

传统分层架构vs微服务

左边是单体架构
紧耦合，随着业务复杂性提升，网站的维护成本会变得很高，牵一发动全身。
后面演进成MVC架构，但是功能逻辑仍然是揉在一起，业务逻辑变复杂后，维护成本依然很高。

之后又演进成SOA架构，把业务解绑，一个大的系统分到不同的子模块，子模块与子模块直接通过API调用来交互。衍生到最后出现了系统服务总线ESB。ESB作为统一的API让所有服务相互调用，但是随着业务的复杂性提升，ESB又变得巨复杂了。

之后再演进就是右边的微服务架构。微服务架构可以理解为SOA面向服务架构的最佳实践。它没有强制通过ESB来通信，可以微服务之间点对点通信，也可以开放统一的API网关进行通信。

那么微服务架构给业务架构带来了有什么挑战？
每个微服务都需要一个IP和端口来部署，当直接在物理机部署的时候，IP是唯一的，那么端口如何分配又成了一个问题，特别是微服务多的时候。随着时间发展出现了虚拟化技术，一个物理机可以虚拟出多个虚拟机，每个虚拟机都拥有独立的操作系统，和独立的IP，通过这样的方式，我们把资源做了一个切分，服务就可以提供在默认端口上面。但是虚拟化带来的复杂性使我们的运维成本上升，应用性能下降。那么有没有更轻量级的解决方案呢？答案是容器技术Docker。

1.Docker是如何工作的？
2.Docker和虚拟机有哪些区别？
3.Docker所依赖的技术细节？

Docker

•基于 Linux 内核的 Cgroup，Namespace，以及Union FS 等技术，对进程进行封装隔离，属于操作系统层面的虚拟化技术，由于隔离的进程独立于宿主和其它的隔离的进程，因此也称其为容器。

•最初实现是基于 LXC，从 0.7 以后开始去除 LXC，转而使用自行开发的Libcontainer，从1.11 开始，则进一步演进为使用runC 和 Containerd。

•Docker 在容器的基础上，进行了进一步的封装，从文件系统、网络互联到进程隔离等等，极大的简化了容器的创建和维护，使得 Docker 技术比虚拟机技术更为轻便、快捷。

虚拟机和容器运行态的对比

每个虚拟机都要包括一个虚拟机操作系统，那么问题的分析会变得很复杂，例如出现一个网络问题，它可能出现在上面一层，也可能出现在下面一层。

调试变得很复杂，性能也不会很好，任何数据包进来都要在host os走一遍，也要在guest os走一遍，一定会有一些性能的开销。guest os 是一个完整的系统，要跑你的应用，必须预留出一些资源给guest os，资源利用率就有所降低。

而Docker容器就变得简单多了，整个物理机操作系统的资源基本上是给应用的。相对于虚拟机而言有更好的性能和资源利用率。

为什么要用 Docker

更高效的利用系统资源
更快速的启动时间
一致的运行环境
持续交付和部署
更轻松的迁移
更轻松的维护和扩展
……