你可能想要构建一个单一部署的 Web 应用程序或服务，并将其部署为容器。 应用程序本身可能不是内部整体的，而是构建为多个库、组件甚至层（应用程序层、域层、数据访问层等）。 但在外部，它是单个容器（单个进程、单个 Web 应用程序或单个服务）。
若要管理此模型，请部署单个容器来表示应用程序。 若要增加容量，请通过横向扩展来实现，也就是说，只需在负载均衡器前添加更多副本。 简单性来自管理单个容器或 VM 中的单个部署。
图 4-1. 容器化整体应用程序的体系结构示例
可以在每个容器中包含多个组件、库或内部层，如图 4-1 所示。 单一容器化应用程序在单个容器中具有大部分功能，具有内部层或库，并通过克隆多个服务器/VM 上的容器进行横向扩展。 但是，这种整体模式可能与容器原则冲突，“容器执行一件事，并在一个进程中执行此作”，但在某些情况下可能没问题。
如果应用程序增长，此方法的缺点就会变得很明显，并且需要进行扩展。 如果整个应用程序可以缩放，则这不是一个问题。 但是，在大多数情况下，应用程序的几个部分只是需要缩放的阻塞点，而其他组件则使用较少。
例如，在典型的电子商务应用程序中，可能需要缩放产品信息子系统，因为更多的客户浏览产品而不是购买产品。 相比使用支付流程，更多的客户使用他们的篮子。 较少客户添加评论或查看其购买历史记录。 你可能只有少数需要管理内容和营销活动的员工。 如果扩展单体设计，则会多次部署这些不同任务的所有代码，并在同一等级进行扩展。
有多种方法可以缩放应用程序水平重复、拆分应用程序的不同区域以及分区类似的业务概念或数据。 但是，除了缩放所有组件的问题外，对单个组件的更改还需要对整个应用程序进行完整重新测试，以及所有实例的完整重新部署。
但是，整体方法很常见，因为应用程序的开发最初比微服务方法更容易。 因此，许多组织都使用此体系结构方法进行开发。 虽然一些组织取得了足够的结果，但其他组织却达到了极限。 许多组织使用此模型设计了他们的应用程序，因为几年前的工具和基础结构使得构建面向服务的体系结构（SOA）变得太困难了，在应用程序增长之前，他们才看到需要。
从基础结构的角度来看，每个服务器都可以在同一主机中运行许多应用程序，并在资源使用效率方面具有可接受的比率，如图 4-2 所示。
图 4-2. 整体方法：托管运行多个应用，每个应用作为容器运行
可以使用每个实例的专用 VM 部署 Microsoft Azure 中的整体应用程序。 此外，使用 Azure 虚拟机规模集可以轻松缩放 VM。 Azure 应用服务 还可以运行整体式应用程序并轻松缩放实例，而无需管理 VM。 自 2016 年以来，Azure 应用服务还可以运行 Docker 容器的单个实例，从而简化部署。
作为 QA 环境或有限的生产环境，可以部署多个 Docker 主机 VM 并使用 Azure 均衡器进行平衡，如图 4-3 所示。 这样就可以使用粗粒度方法管理缩放，因为整个应用程序都位于单个容器中。
图 4-3. 多个主机纵向扩展单个容器应用程序的示例
可以使用传统的部署技术进行到各个主机的部署管理。 可以使用诸如 docker run 或 docker-compose 手动执行的命令管理 Docker 主机，也可以通过自动化（例如持续交付（CD）管道进行管理。
将单体应用程序部署为容器
使用容器管理整体应用程序部署有好处。 与部署其他 VM 相比，缩放容器实例要快得多且容易。 即使使用虚拟机规模集，VM 也需花费时间才能启动。 部署为传统应用程序实例而不是容器时，应用程序配置作为 VM 的一部分进行管理，这并不理想。
将更新以 Docker 映像形式部署不仅速度快，而且网络资源利用效率很高。 Docker 映像通常能在几秒内启动，从而加快部署速度。 拆解 Docker 映像实例与发出 docker stop 命令一样简单，通常只需不到一秒即可完成。
由于容器在设计上是不可变的，因此无需担心损坏的 VM。 相比之下，VM 的更新脚本可能会忘记考虑磁盘上留下的某些特定配置或文件。
虽然整体式应用程序可以从 Docker 中受益，但我们只涉及优势。 管理容器的其他好处包括使用容器业务流程协调程序进行部署，后者管理每个容器实例的各种实例和生命周期。 将整体应用程序分解为可以单独缩放、开发和部署的子系统是微服务领域的入口点。
将基于单容器的应用程序发布到 Azure 应用服务
无论是要验证部署到 Azure 的容器，还是当应用程序只是单容器应用程序时，Azure 应用服务都提供了一种提供可缩放的单容器服务的好方法。 使用 Azure 应用服务非常简单。 它提供与 Git 的出色集成，以便轻松获取代码、在 Visual Studio 中生成代码并将其直接部署到 Azure。
图 4-4. 从 Visual Studio 2022 将单容器应用程序发布到 Azure 应用服务
如果没有 Docker，如果需要 Azure 应用服务中不支持的其他功能、框架或依赖项，则必须等到 Azure 团队更新应用服务中的这些依赖项。 或者，必须切换到其他服务（例如 Azure 云服务或 VM），可在其中进一步控制，并且可以为应用程序安装所需的组件或框架。
Visual Studio 2017 及更高版本中的容器支持使你能够在应用程序环境中包括所需的内容，如图 4-4 所示。 由于在容器中运行它，因此，如果将依赖项添加到应用程序，则可以在 Dockerfile 或 Docker 映像中包含依赖项。
如图 4-4 所示，发布流通过容器注册表推送映像。 这可以是 Azure 容器注册表（靠近 Azure 中的部署的注册表，并由 Azure Active Directory 组和帐户保护），也可以是任何其他 Docker 注册表，例如 Docker Hub 或本地注册表。
