微服务提供了巨大的好处，但也带来了巨大的新挑战。微服务架构模式是创建基于微服务的应用程序时的基本支柱。

在本指南的前面，您学习了容器和Docker的基本概念。这是开始使用容器所需的最少信息。尽管，即使容器是使能器并且非常适合微服务，它们也不是微服务体系结构的强制要求，而且此体系结构部分中的许多体系结构概念也可以在没有容器的情况下应用。然而，由于已经引入了容器的重要性，本指南将重点放在两者的交叉点上。

企业应用程序可能很复杂，通常由多个服务组成，而不是由单个基于服务的应用程序组成。对于这些情况，您需要了解其他体系结构方法，例如微服务和某些域驱动设计模式以及容器编排概念。注意，本章不仅描述容器上的微服务，还描述任何容器化应用程序。

容器架构

容器设计原则

在容器模型中，容器映像实例表示单个进程。通过将容器镜像定义为进程边界，可以创建用于缩放进程或批处理进程的基元。

设计容器映像时，您将在Dockerfile中看到入口点定义。这定义了其生存期控制容器生存期的进程。当进程完成时，容器生命周期结束。容器可以表示长时间运行的进程，如web服务器，但也可以表示短时间运行的进程，如批处理作业。

如果进程失败，则容器结束，编排器接管。如果编排器配置为使五个实例保持运行，而一个实例失败，则编排器将创建另一个容器实例来替换失败的进程。在批处理作业中，使用参数启动进程。当过程完成时，工作就完成了。本指南

稍后将深入讲解编排器。

您可能会发现需要在单个容器中运行多个进程的场景。对于这种情况，因为每个容器只能有一个入口点，所以可以在容器中运行脚本，根据需要启动任意多个程序。例如，可以使用监督人工具或类似的工具在单个容器中启动多个进程。然而，即使您可以找到每个容器包含多个进程的体系结构，这种方法也不是很常见。

最佳实践

建议优先使用容器部署应用程序

以下情况以允许使用虚拟机进行部署：

• 应用程序需要更多的控制（例如需要调整操作系统内核参数）
  
• 应用程序需要大量内存
  
• 应用程序是CPU密集型的
  
• 应用程序是IO密集型的
  
• 无法使用容器.