在设计基于微服务架构的 Web 应用时，您需要确定如何将应用的功能拆分成各个微服务，以及如何在应用中调用这些微服务。对于长时间运行的服务，建议您使用异步服务调用。此参考架构讨论了如何部署容器化应用以异步调用长时间运行的进程。
本参考架构文档适用于希望使用先进技术（包括 Google Kubernetes Engine [GKE] 和 Pub/Sub）异步实现微服务的开发者和架构师。本文档假定您整体上熟悉微服务，以及 Google Cloud 上的 Pub/Sub 和 GKE。
架构
下图展示了应用生成缩略图的示例场景。生成缩略图可能是一项资源密集型任务，因此可能需要一些时间。
图 1. 基于使用虚拟机的原始图片处理架构。
在上图中，应用从客户端接收图片文件，然后生成缩略图。在此架构中，应用是使用 Compute Engine 上的虚拟机 (VM) 实例以及 Cloud Storage 上的后端文件存储实现的。应用使用 Cloud Storage 存储元数据。Cloud Load Balancing 将请求分布到多个虚拟机。
如需减少维护虚拟机的操作开销，请将此系统迁移到不使用虚拟机的新架构。
下图展示了如何通过使用通知和微服务的代管式服务在系统组件之间实现异步调用来实现此流程。
图 2. 基于使用容器和异步消息传递的新图片处理架构。
在新架构中，客户端将图片提交到应用，接着应用将图片上传到 Cloud Storage。然后，Pub/Sub 通知将消息排入 Pub/Sub 消息队列中。该消息调用 GKE 上运行的微服务。微服务从 Cloud Storage 检索图片、生成缩略图，并将缩略图上传到 Cloud Storage。
设计考虑事项
以下准则可帮助您开发满足组织的运营效率和性能要求的架构。
运营效率
新架构具有以下优势：
独立的可扩缩性：在原始架构中，Compute Engine 上运行的应用负责处理两个核心任务。一个任务是接收文件，另一个任务是根据原始图片生成缩略图。接收上传的文件时会消耗网络带宽，而生成缩略图是一项 CPU 密集型任务。Compute Engine 实例生成图片时可能会耗尽 CPU 资源，但仍具有足够的网络资源来接收文件。在新架构中，Cloud Storage 和 GKE 共同承担这些任务，使它们能独立扩缩。
轻松添加新功能：在原始架构中，如果您要添加功能，必须将其部署到相同的 Compute Engine 实例上。在新架构中，您可以开发一个应用并单独添加，例如，您可以添加邮件发件人应用，以便在生成新缩略图时收到通知。Pub/Sub 可以异步连接到缩略图生成应用和邮件发件人应用，而无需修改在 GKE 上运行的原始代码。
降低耦合性：在原始架构中，一个常见的问题是时间耦合。如果邮件中继服务器不可用，则当应用尝试发送通知时，通知将会失败。这些进程是紧密耦合的，客户端可能无法从应用获得成功的响应。在新架构中，客户端会获得成功的响应，因为生成缩略图和发送通知是松散耦合的。
这种新架构具有以下缺点：
需完成额外的工作对应用进行现代化改造：对应用进行容器化处理耗时耗力。新架构使用的服务更多，需要一种不同的可观测性方法，包括对应用监控、部署流程和资源管理的更改。
要求在应用端处理重复项：Pub/Sub 保证消息至少传送一次，这意味着可能会发送重复消息。应用必须对这种可能性进行处理。
性能
新架构可让您高效使用资源：在原始架构中，如果扩容 Compute Engine 实例，则需要使用更多资源来运行操作系统。借助 GKE，您可以高效使用在几个服务器上运行多个容器的服务器资源（装箱）。您可以快速扩容和缩容容器，使新架构能够处理短暂的突发高负载，并在任务完成时快速缩容。
Deployment
如需部署实现此架构的示例应用，请参阅部署使用 Pub/Sub 和 GKE 的微服务。
后续步骤
- 了解 DevOps，并详细了解与此参考架构相关的架构功能。
- 进行 DevOps 快速检查，了解您与业界其他公司相比所处的位置。
- 如需查看更多参考架构、图表和最佳实践，请浏览云架构中心。