微服务提供了巨大的优势，但也带来了巨大的新挑战。 创建基于微服务的应用程序时，微服务体系结构模式是基本支柱。
本指南的前面部分介绍了有关容器和 Docker 的基本概念。 这些信息是开始使用容器所需的最低信息。 尽管容器是微服务的启用者，并且非常适合微服务，但它们对微服务体系结构来说并不是必需的。 本体系结构部分中的许多体系结构概念可以在不使用容器的情况下应用。 然而，本指南重点关注两者的交汇点，因为容器的重要性已经被强调。
企业应用程序可能很复杂，通常由多个服务组成，而不是单个基于服务的应用程序。 在这些情况下，需要了解其他体系结构方法，例如微服务和某些 Domain-Driven 设计（DDD）模式以及容器业务流程概念。 请注意，本章不仅介绍了容器上的微服务，还介绍了任何容器化应用程序。
容器设计原则
在容器模型中，容器映像实例表示单个进程。 通过将容器映像定义为进程边界，可以创建可用于缩放或批处理进程的基元。
设计容器映像时，Dockerfile 中会显示 ENTRYPOINT 定义。 此定义定义其生存期控制容器生存期的进程。 该过程完成后，容器生命周期将结束。 容器可能表示长时间运行的进程（如 Web 服务器），但也表示短期进程，例如批处理作业（以前可能已实现为 Azure WebJobs）。
如果进程失败，则容器结束，Orchestrator 接管。 如果业务流程协调程序配置为使五个实例保持运行，一个实例失败，业务流程协调程序将创建另一个容器实例来替换失败的进程。 在批处理作业中，进程以参数启动。 该过程完成后，工作已完成。 本指南接下来将深入介绍业务流程协调程序。
你可能会发现想要在单个容器中运行多个进程的情况。 对于这种情况，由于每个容器只能有一个入口点，因此可以在容器中运行一个脚本，以便根据需要启动任意数量的程序。 例如，可以使用 监督程序 或类似的工具来处理在单个容器内启动多个进程。 但是，即使可以找到每个容器包含多个进程的体系结构，但这种方法并不十分常见。
