“扩展立方模型”是指微服务架构的在拆分时包括三个维度，如上图所示，X 轴表示水平副本，通过副本进行扩展；Y 轴表示功能解耦，通过分解功能，在不同模块之间的扩展；Z 轴是数据分区，一个系统会有一些业务和数据，微服务架构可以通过数据分区的形式进行扩展。

Docker 主要包含两个方面的技术：

一方面是容器技术，可以进行物理资源的有效分配与管理，并实现资源隔离，从这个角度看来，容器跟虚拟机的理念比较类似。容器的诞生会占 据虚拟机的一些市场，但不是完全替代虚拟机，主要是隔离强度的问题，容器技术是共享内核资源的，在一些比较严苛的状况下，虚拟机更胜一筹。

Docker 的第二个技术——镜像技术。打破了 “代码即应用” 的观念，Docker 真正实现了从系统环境开始，自底向上地打包一个软件。Docker 解决了软件的环境一致性问题，使得软件的分发与交付异常便捷。

Docker 如何让微服务架构更简单？

如下图所示，结合微服务的「扩展立方」来看，Docker 镜像的一致性可以保证水平扩展，部署秒级，扩展立方的 Y轴，是功能解耦，可以把一个系统分成不同的模块，Docker 的优势是 application-centric，Docker 镜像完全独立。在数据分区方面，Docker 与数据服务结合，在这个方面，Docker 还有一些路要走。

从扩展立方模型看微服务与 Docker 化

Docker 化实践

Docker 的本质体现在两个方面，一个是 application-centric（应用为中心），另一个是 single-process（单个进程）。

如下图所示，这个文件系统是一个涵盖用户应用的发行版，Docker 容器里面会有很多进程，容器启动以后，会有进程隔离、网络隔离（可以使用独立的网络来处理自己的逻辑）、文件系统隔离、权限控制、资源控制、资源隔离等。

App-Centric 和 Single-Process

如何 Docker 化？

• 首先，需要定义一个 Dockerfile，Dockerfile 定义了进程需要的一切东西。Dockerfile 涉及的内容包括执行代码或者是文件、环境变量、依赖包、运行时环境、动态链接库、操作系统的发行版、服务进程和内核进程（当应用进程需要和系统服务和内核 进程打交道，这时需要考虑如何设计 namespace 的权限控制）等等
• 第二个方面是 Docker 镜像，在用 Dockerfile 定义一个文件之后，dockerbuild 时会产生一个 Docker 镜像，当运行 Docker 镜像时，会真正开始提供服务
• 第三点是 Docker 容器，容器是直接提供服务的，关于容器的“单进程模式”，需要注意一点，容器里面有一个非常重要的进程——init 进程，它负责管理容器内部的所有进程，一旦该进程出现故障，系统会负责给容器内所有其他进程发送一个 kill 信号，随即容器退出运行。在实践时需要保证 init 进程不能经常出问题，当然也可以通过 Docker 层面，设置一些 restartpolicy 等策略，来保证容器能够成功恢复，不过如果容器内部已经有状态时，同样也会出现一些问题。

遗留系统如何无差异地 Docker 化，传统应用 Docker 化的两个关键——日志管理和配置管理。事实上，Docker 里面也有一个 init 进程，Dockerinit 进程跟宿主机上的 init 进程有很大的差异，Docker 的 init 进程是完成资源的初始化，然后把决策完全交给用户指定的进程。

另外，传统模式下，很多应用很多组件都会调用服务进程来完成特殊的需求，比如，如果说某一个 组件是需要完成日志的，会需要 syslog 的服务来完成这些目标，可不可以把这些放到容器中呢？如果把它们放到容器中，容器的逻辑就变得比较复杂。日志管理进程 syslog 的 Docker 化实践（参见下图）。