微服务消息队列与持续交付全解析
1. 消息队列与消息推送的选择
在可以直接将消息推送给接收者时，为何还要将消息添加到队列中呢？SNS 存在一个问题，它只能通过 HTTP 向可公开访问的服务进行消息传递。如果内部工作进程未连接到公共互联网，那么基于拉取的方式可能就是唯一的选择。从队列中读取消息对于管理大量消息流而言，可能是更好的办法。多数情况下，无需担忧 SQS 的可用性，而且对于简单的可轮询队列的应用工作进程，也无需实现 HTTP 接口。
2. Google Cloud Pub/Sub 介绍
Google Cloud Pub/Sub 与 AWS SNS 类似，是一种消息中间件，允许创建带有发布者和订阅者的主题。目前，Google Cloud 上没有类似 SQS 的正式产品，但利用现有的众多数据存储选项，实现类似功能并非难事。
3. 持续交付的概念
持续交付是指持续且良好地构建和部署代码的过程，目标是尽可能高效、有效地将代码从开发环境迁移到生产环境。
传统的瀑布式工作流程中，版本发布通常围绕主要功能或更新的完成。大型企业每季度发布一次版本并不罕见，其主要原因在于风险和工作量。发布存在风险是因为对软件的信心不足，而工作量大则是由于质量保证和软件发布的操作方面大多依赖手动流程。
手动部署存在诸多问题：
- 部署步骤的顺序和时间安排可能出现问题。
- 文档需要全面且及时更新。
- 严重依赖手动测试。
- 应用服务器状态不一致。
随着系统复杂度的增加，部署代码所需的步骤也会增多，手动部署过程可能会成为负担。例如，部署应用更新时，需要在所有应用服