使用 .NET 容器时定位的操作系统

由于 Docker 支持多种操作系统，且鉴于 .NET Framework 和 .NET Core 之间的差异，应根据所使用的框架，面向特定操作系统和特定版本。

对于 Windows，可使用 Windows Server Core 或 Windows Nano Server。 这两种 Windows 版本分别提供 .NET Framework 和 .NET Core 各自所需的特征（Windows Server Core 中的 IIS 与 Nano Server 中自承载的 web 服务器，如 Kestrel）。

对于 Linux，正式的 .NET Docker 映像（如 Debian）中提供并支持多个发行版本。

部署旧的 .NET Framework 应用程序时，必须以与旧应用程序和 IIS 兼容但具有更大映像的 Windows Server Core 为目标。 部署 .NET Core 应用程序时，可以针对已经过云优化、使用 Kestrel、更小且启动速度更快的 Windows Nano Server。 还可以面向 Linux，支持 Debian、Alpine 和其他操作系统。 也使用 Kestrel、更小且启动速度更快。

如果想使用不同的 Linux 发行版本或要使用 Microsoft 不支持的映像版本，还可以创建自己的 Docker 映像。 例如，可以使用 ASP.NET Core 创建一个在传统 .NET Framework 和 Windows Server Core 上运行的映像，但这不是常见的 Docker 方案。

与完整的 Windows 映像相比，使用 Windows Server Core 映像时，你可能会发现缺少某些 DLL。 可以通过创建自定义 Server Core 映像，在映像构建时添加缺失的文件来解决此问题，如​​本 GitHub​​ 注释中所述。

将映像名称添加到 Dockerfile 文件后，可根据所使用的标记选择操作系统和版本，如下例所示：

构建基于微服务的容器化应用程序

微服务提供很多优点，但也会引起新的巨大挑战。 创建基于微服务的应用程序时，微服务体系结构模式是基础支柱。
本指南前面部分介绍了有关容器和 Docker 的基本概念。 要开始使用容器，至少要了解这些基本信息。 虽然容器为实现微服务提供可能，并且非常适用于微服务，但微服务体系结构并不强制使用容器。本节介绍体系结构，但即使不使用容器，其中许多体系结构概念仍然适用。 然而，由于已介绍容器的重要性，本指南将重点介绍两者交叉部分。
企业应用程序可能会很复杂，它们通常由多个服务组成，而不是基于单个服务的应用程序。 对于这些情况，需要了解其他体系结构方法，如微服务和某些域驱动设计 (DDD) 模式以及容器业务流程的概念。 请注意，本章节不仅介绍容器上的微服务，还介绍任何容器化应用程序。

容器设计原则

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

设计容器映像时，可在 Dockerfile 中看到入口点定义。 这定义了一个进程，其生命周期控制容器的生命周期。 该进程完成，则容器的生命周期结束。 容器可以表示 Web 服务器等长时间运行的进程，但也可表示批处理作业等生存期较短的进程，这些进程以前可能已实现为 Azure WebJobs。

如果进程失败，则容器结束，Orchestrator 接管。 如果 Orchestrator 已配置为使五个实例保持运行，而其中一个实例失败，则 Orchestrator 会创建另一个容器实例，来替换失败的进程。 在批处理作业中，使用参数启动该进程。 进程完成，则工作完成。 本指南接下来将深入介绍业务流程协调程序。

某些情况下，可能需要在单个容器中运行多个进程。 对于这种情况，因为每个容器只有一个入口点，所以在可根据需要启动任意数目的程序的容器中运行脚本。 例如，可以使用 Supervisor 或类似的工具处理在单个容器内启动多个进程的情况。 尽管可以找到用于在每个容器中承载多个进程的体系结构，但这种方法并不常见。

容器化整体式应用程序

你可能想构建单个整体部署的 Web 应用程序或服务，并将其部署为容器。 应用程序本身在内部可能并非整体式，只是结构化为多个库、组件甚至层（应用程序层、域层、数据访问层等等）。 但在外部，应用程序则是单个容器 - 单个进程、单个 Web 应用程序或单个服务。

若要管理此模型，可部署单个容器来表示应用程序。 若要增加容量，可进行横向扩展，即，只需添加更多副本并将负载均衡器置于前面。 为了简单起见，在单个容器或 VM 中管理单个部署。

容器化整体式应用程序的体系结构示例

如图中所示，可以在每个容器添加多个组件、库或内部层。 整体式容器化应用程序将其大部分功能集中在一个具有内部层或库的容器中，并通过在多个服务器/VM 上克隆容器来进行横向扩展。 然而，这种整体式模式可能违背了容器原则（“一个容器在一个进程中做一件事”），但在某些情况下没有关系。
如果应用程序在增长，需要它进行缩放，这种方法的缺点就会变得显而易见。 如果整个应用程序都可缩放，这就不是问题了。 但是，在大多数情况下，应用程序中只有少数几个部分需要进行缩放，而其他组件很少用到。
例如，在典型的电子商务应用程序中，很可能需要缩放产品信息子系统，因为更多的顾客仅浏览产品而非购买产品。 使用购物车的顾客比使用付款管道的多。 较少的顾客会评论或查看购买记录。 而且你可能只需要少量的员工管理货物和营销活动。 如果缩放整体式设计，则会多次部署并按相同等级缩放这些不同任务的所有代码。
缩放应用程序的方法有多种，如：水平复制、拆分应用程序的不同区域，以及分割类似的经营理念或数据。 但除了缩放所有组件的问题外，更改单个组件还需要完全重新测试整个应用程序，以及完全重新部署所有实例。
然而，整体式方法非常常见，因为应用程序的开发最初比微服务方法更容易。 因此，许多组织都使用此体系结构方法进行开发。 一些组织获得了不错的成效，而其他组织却快要达到极限。 许多组织使用这种模型设计应用程序，因为几年前的工具和基础结构难以构建面向服务的体系结构 (SOA)，而且在应用程序增长之前他们也没有发现这种需要。
从基础结构的角度来看，每台服务器可以在同一台主机上运行多个应用程序，在资源使用率中具有可接受的效率比率，如下图 所示。

整体式方法：主机运行多个应用，每个应用作为一个容器运行

将整体式应用程序部署为容器

使用容器管理整体式应用程序部署具有一些益处。 缩放容器实例比再部署另外的 VM 要快得多，也容易地多。 即使是使用虚拟机规模集，启动 VM 也需要时间。 部署为传统应用程序实例而非容器时，管理应用程序的配置就属于 VM 的一部分，这并不是理想的方式。
将更新部署为 Docker 映像会快得多，并且网络效率更高。 Docker 映像通常会在几秒内启动，加快了推出速度。 拆除 Docker 映像实例与发出 docker stop 命令一样简单，通常在一秒钟以内便可完成。
因为容器设计为不可更改，所以不必担心损坏的 VM。 与此相反，VM 的更新脚本可能会忘记某些特定配置的帐户或磁盘上的剩余文件。
虽然整体式应用程序可以从 Docker 中获益，但我们仅涉及到这些益处。 管理容器的其他益处来自于使用容器业务流程协调程序进行部署，此协调程序负责管理每个容器实例的各种实例和生命周期。 将整体式应用程序分解为可以单独缩放、开发和部署的子系统是进入微服务领域的切入点。