此设计确实也具有很好的扩展性。如果出现网站流量高峰，我可以在更多主机上运行更多容器，以处理传入的请求。在消息处理程序处理事件消息前，它们会一直保留在队列中。对于没有特定 SLA 的功能，可以在一个容器中运行一个消息处理程序，并依赖消息队列的保证，即所有事件最终都会得到处理。对于 SLA 驱动型功能，可以通过运行更多的消息处理程序容器来扩展暂留层。

　　本文随附的源代码包含应用程序版本 1、2 和 3 的文件夹。在版本 2 中，SignUp.aspx 页面在用户提交详细信息表单时发布事件：

　　vareventMessage = newProspectSignedUpEvent{ Prospect = prospect, SignedUpAt = DateTime.UtcNow};MessageQueue.Publish(eventMessage);

　　此外，在版本 2 中，有一个共享的消息传送项目，用于提取消息队列的详细信息；还有一个控制台应用程序，用于侦听 Web 应用程序发布的事件，并将用户数据保存到数据库。控制台应用程序中的暂留代码直接取自 Web 应用程序中的版本 1 代码，所以实现代码是一样的，不同之处在于功能设计已经过现代化。

　　应用程序的新版本是包含许多工作部件的已分发解决方案，如图 2所示。

　　图 2：经过现代化的应用程序包含许多工作部件

　　组件之间有依赖项，必须以正确的顺序启动，这样解决方案才能正常运行。这是安排跨许多容器运行的应用程序的业务流程时面临的问题之一，而为了解决此问题，Docker 平台将已分发的应用程序视作“一等公民”。

　　Docker Compose 属于 Docker 平台，主要处理对象是已分发的应用程序。在简单文本文件中将应用程序的所有部分定义为各个服务，包括组件之间的依赖项及其需要的所有配置值。下面展示了部分版本 2 Docker Compose 文件，仅包含 Web 应用程序的配置：

　　product-launch-web: image: sixeyed/msdn-web-app:v2 ports: - "80:80" depends_on: - sql-server - message-queue networks: - app-net

　　此时，我要指定要对 Web 应用程序使用的映像版本。我发布端口 80，然后显式声明 Web 应用程序依赖 SQL Server 和消息队列容器。Web 容器必须位于同一虚拟 Docker 网络中，才能访问这些容器。因此，Docker Compose 文件中的所有容器都会联接到同一虚拟网络 app-net 中。

　　在 Docker Compose 文件中的其他位置，我使用 Docker Hub 上的 Microsoft 映像定义 SQL Server 服务，并使用 NATS 消息传送系统定义消息队列服务（这是性能卓越的开放源代码消息队列）。NATS 是 Docker Hub 上的官方映像。最终定义的是消息处理程序服务，这是使用简单的 Dockerfile 打包成 Docker 映像的 .NET 控制台应用程序。

　　现在，我可以使用以下 Docker Compose 命令行运行应用程序：

　　docker-compose up -d

　　Docker Compose 会按正确的顺序启动每个组件的容器，只需一个命令就可以为我提供有效的解决方案。有权访问 Docker 映像和 Docker Compose 文件的任何人都可以运行应用程序，且行为方式是相同的，无论是在 Windows 10 笔记本电脑上，还是在数据中心或 Azure 中运行的 Windows Server 2016 计算机上。

　　对于版本 2，我稍微更改了一下应用程序代码，将功能实现代码从一个组件移到另一个组件。虽然最终用户行为方式是相同的，但现在解决方案易于扩展，因为 Web 层与数据层分离，消息队列负责处理任何流量峰值。新设计也易于扩展，因为我引入了事件驱动型体系结构，从而可以通过联接现有事件消息来触发新行为。

　　对于我的示例应用程序，我将再更改一下代码，以说明使用 Docker 平台只需极少的工作即可实现很多功能。应用程序当前使用 SQL Server 作为事务数据库，我将添加第二个数据存储作为报表数据库。这样一来，我可以单独处理报表和事务问题，并能自由选择技术堆栈。