背景：
企业通过使用容器，日益实现成本节约、解决部署问题并改进 DevOps 和生产操作。 通过创建 Azure Kubernetes 服务、Azure Service Fabric 等产品，同时与 Docker、Mesosphere 和 Kubernetes 等行业领先者合作，Microsoft 一直在推出适用于 Windows 和 Linux 的容器创新。 这些产品提供容器解决方案，可帮助公司以云的速度和规模生成并部署应用程序，而无需考虑其选用的平台或工具。
Docker 正在逐渐成为容器行业的事实标准，受到 Windows 和 Linux 生态系统领域最重要供应商的支持。 （Microsoft 是支持 Docker 的主要云供应商之一。）将来，Docker 可能会在云端或本地的任何数据中心普及。
Docker 容器、映像和注册表
使用 Docker 时，开发人员会创建一个应用或服务，并将它及其依赖项打包到一个容器映像中。 映像是应用或服务及其配置和依赖项的静态表示形式。
若要运行应用或服务，应用的映像会实例化，以创建一个在 Docker 主机上运行的容器。 最初，会在开发环境或 PC 中测试容器。
开发人员应将映像存储在注册表中，该注册表可充当映射库并在部署到生产业务流程协调程序时使用。 Docker 通过 Docker 中心维护公共注册表；其他供应商为不同映像集合提供注册表，包括 Azure 容器注册表。 或者，企业可以拥有一个本地专用注册表，用于其 Docker 映像。
为 Docker 容器选择 .NET 5 或 .NET Framework
通过 .NET 生成服务器端容器化 Docker 应用程序时，有两种支持的框架：.NET Framework 和 .NET 5。 这两者共享许多 .NET 平台组件，可在它们之间共享代码。 但两者之间存在根本差异，可根据需要实现的目标选择框架。
官网地址：
https://dotnet.microsoft.com/download
构建基于微服务的容器化应用程序
微服务提供很多优点，但也会引起新的巨大挑战。创建基于微服务的应用程序时，微服务体系结构模式是基础支柱。
容器设计原则：在容器模型中，容器映像实例表示单个进程。 将容器映像定义为进程边界，可以创建可用于对进程进行缩放或批处理的基元。
设计容器映像时，可在 Dockerfile 中看到入口点定义。 此定义定义了一个进程，其生命周期控制容器的生命周期。 该进程完成，则容器的生命周期结束。 容器可以表示 Web 服务器等长时间运行的进程，但也可表示批处理作业等生存期较短的进程，这些进程以前可能已实现为 Azure WebJobs。
如果进程失败，则容器结束，Orchestrator 接管。 如果 Orchestrator 已配置为使五个实例保持运行，而其中一个实例失败，则 Orchestrator 会创建另一个容器实例，来替换失败的进程。 在批处理作业中，使用参数启动该进程。 进程完成，则工作完成。
基于 Docker 的应用程序的开发流程
无论你更青睐内容丰富、功能强大的 IDE 还是轻量、灵活地级编辑器，Microsoft 都可为你提供用于开发 Docker 应用程序的工具。
Visual Studio（适用于 Windows）。 使用 Visual Studio 的基于 Docker 的 .NET 5 应用程序开发需要 Visual Studio 2019 版本 16.8 或更高版本。 Visual Studio 2019 附带已内置的 Tools for Docker。 通过适用于 Docker 的工具，可以在目标 Docker 环境中开发、运行和验证应用程序。 可以按 F5，直接在 Docker 主机中运行并调试应用程序（单个容器或多个容器），也可以按 Ctrl+F5，编辑并刷新应用程序，而无需重新生成该容器。 要开发基于 Docker 的应用，此 IDE 是功能最强大的选择。
Visual Studio for Mac。 它是一个 IDE，由 Xamarin Studio 演化而来，在 macOS 中运行。 对于 .NET 5 开发，它需要版本 8.4 或更高版本。 对于使用 macOS 计算机工作而又希望使用功能强大的 IDE 的开发者而言，此工具应当是理想之选。
Visual Studio Code 和 Docker CLI。 如果更青睐支持任何开发语言的轻量级跨平台编辑器，可以使用 Visual Studio Code 和 Docker CLI。 此 IDE 是针对 macOS、Linux 和 Windows 的跨平台开发方法。 此外，Visual Studio Code 还支持 Docker 扩展（例如适用于 Dockerfile 的 IntelliSense）和在编辑器中运行 Docker 命令的快捷任务。
实现可复原的应用程序
微服务和基于云的应用程序必须允许最终必然会发生的部分故障。必须设计应用程序，使其可从这些部分失败中恢复。
恢复能力是指从故障中恢复并继续工作的能力。 这并不是指避免失败，而是接受会发生失败这一事实，并以能够避免停机或数据丢失的方式对失败做出响应。 恢复的目标是使应用程序在发生故障后回到完全正常运行的状态。
设计和部署基于微服务的应用程序已经非常具有挑战性。 然而还需要让应用程序在必然发生某种故障的环境中保持正常运行。 因此，应用程序应具有恢复能力。 应将其设计为能够处理部分故障，如网络中断或者云中节点或 VM 故障。 甚至将微服务（容器）移动到群集内的另一个节点，也可能导致应用程序出现间歇性的功能短缺故障。
在基于微服务的应用程序这类分布式系统中，经常会出现部分失败错误。 例如，单个微服务/容器可能会失败，也可能无法在短时间响应，或者单个 VM 或服务器会出现故障。 由于客户端和服务是彼此独立的流程，因此服务可能无法及时响应客户端的请求。 服务可能过载并且对请求的响应速度过慢，或者只是由于网络问题在短时间内无法访问。
例如，请查看 eShopOnContainers 示例应用程序的订单详细信息页。 如果订购微服务在用户尝试提交订单时没有响应，则客户端进程（MVC Web 应用程序）的错误实现（例如，如果客户端代码使用同步 RPC 而没有出现超时）将会无限期地阻止线程等待回应。 每个无响应的等待除了会造成不良用户体验之外，还会消耗或阻止线程，然而线程在高度可缩放应用程序中极有价值。 如果受阻止的线程数量众多，应用程序的运行时最终会耗尽所有线程。 在这种情况下，应用程序会出现全局无响应，而不只是部分无响应，如上图。
除此之外恢复能力还包括：处理部分失败的策略，实现使用指数退避算法的重试，实现复原Entity Framework Core SQL连接，使用IHttpClineFactory实现复原Http请求，通过Polly实现使用指数退避算法的Http调用重试，实现断路器模式，运行状态监视等。
更多详情：点击下载
