微服務提供絕佳的優點，但也帶來了巨大的新挑戰。 微服務架構模式是建立微服務型應用程式時的基本要素。
本指南稍早，您已瞭解容器和 Docker 的基本概念。 此資訊是開始使用容器所需的最低資訊。 雖然容器是促進微服務的工具，而且非常適合微服務，但它們並非微服務架構的必需品。 此架構一節中的許多架構概念可以套用，而不需要容器。 然而，由於已介紹容器的重要性，本指南著重於兩者的交集。
企業應用程式可能很複雜，而且通常由多個服務組成，而不是單一服務型應用程式。 在這些情況下，您必須瞭解其他架構方法，例如微服務和某些 Domain-Driven 設計（DDD）模式，以及容器協調流程概念。 請注意，本章不僅描述容器上的微服務，也描述任何容器化應用程式。
容器設計原則
在容器模型中，容器映像實例代表單一進程。 藉由將容器映像定義為進程界限，您可以建立可用來調整或批處理的基本類型。
當您設計容器映像時，您會在 Dockerfile 中看到 ENTRYPOINT 定義。 此定義會定義其存留期控制容器存留期的程式。 當程式完成時，容器生命週期就會結束。 容器可能代表 Web 伺服器等長時間執行的進程，但也代表短期進程，例如批次作業，先前可能已實作為 Azure WebJobs。
如果進程失敗，容器就會結束，協調器會接管。 如果協調器設定為讓五個實例保持執行且一個失敗，協調器會建立另一個容器實例來取代失敗的進程。 在批次作業中，進程會以參數啟動。 當程式完成時，工作就會完成。 本指南稍後會深入探討協調器。
您可能會發現您想要在單一容器中執行多個進程的情況。 針對該案例，因為每個容器只能有一個進入點，所以您可以在容器內執行腳本，視需要啟動多個程式。 例如，您可以使用 監督員 或類似的工具，在單一容器內啟動多個進程。 不過，即使您可以找到每個容器保存多個進程的架構，但這種方法並不常見。
