---
tags:
  - MQ
create time: 2026-05-24 19:52
---

# 云消息服务

## 概述

随着云计算的成熟，越来越多企业选择托管消息服务而非自建 MQ 集群。本文梳理主流云厂商的消息服务产品（AWS、Azure、GCP、阿里云），对比自建与托管的 Trade-off，并展望云原生 MQ 的发展趋势。

## 正文

### 为什么选择托管服务

自建 MQ 集群需要运维 Broker、监控告警、扩容缩容、版本升级、故障恢复，这些工作既繁琐又需要深厚的专业知识。托管服务的核心价值在于：

- **免运维**：云厂商负责集群的部署、维护、升级和故障恢复。
- **弹性扩缩**：按需自动扩展，不需要提前规划容量。流量高峰自动扩容，低谷缩容省钱。
- **SLA 保障**：大厂通常承诺 99.95%+ 的可用性，如果达不到会赔偿。
- **开箱即用**：IAM 集成、监控告警、日志分析等能力与云平台深度集成。

> [!question]
> 你的团队有多少人？如果只有 2-3 个后端开发，自建 Kafka 集群的运维成本能承受吗？

### AWS 消息服务方案

AWS 提供了完整的消息服务产品矩阵：

**SQS（Simple Queue Service）**

AWS 最老牌的消息队列服务，标准队列模式。

- **标准队列**：最大努力排序，支持至少一次投递，吞吐无上限。适合对顺序要求不高的场景。
- **先进先出队列（FIFO）**：严格顺序 + 去重，但吞吐受限（默认 300 msg/s，批量模式 3000 msg/s）。

**SNS（Simple Notification Service）**

发布订阅服务，一条消息可以投递给多个订阅者（Fan-out 模式）。SNS + SQS 组合是最经典的 AWS 消息架构：SNS 作为消息分发中心，多个 SQS 队列作为订阅者。

**MSK（Managed Streaming for Apache Kafka）**

AWS 托管的 Kafka 服务。与原生 Kafka 100% 兼容，但免去了 ZooKeeper 管理、Broker 升级等运维工作。MSK Serverless 进一步简化，按实际使用量计费，不需要预配置集群。

### Azure 消息服务方案

**Azure Service Bus**

企业级消息服务，支持队列（点对点）和主题/订阅（发布订阅）两种模式。特色功能包括：消息会话（Message Sessions）、死信队列、消息延期投递、重复检测。

**Event Hubs**

高吞吐的事件流式服务，类似 Kafka 的设计——分区 + Consumer Group + Offset。适合日志采集、IoT 数据流、实时分析等大数据场景。标准层吞吐可达每秒数百万事件。

### Google 消息服务方案

**Google Pub/Sub**

全球分布式的消息服务，最大的特点是**自动扩缩容**和**全球消息路由**。消息自动在多个区域复制，任何区域的订阅者都能消费。默认 At-Least-Once 投递，支持 Exactly-Once（通过消息去重）。

计费模式按吞吐量（消息数量 + 数据量），没有预配置成本，对突发流量友好。

### 阿里云消息服务方案

**云消息队列（RocketMQ 版）**

基于 Apache RocketMQ 的托管服务，与开源版完全兼容。支持普通消息、顺序消息、事务消息、定时/延时消息。适合国内业务场景。

**云消息队列（Kafka 版）**

基于 Apache Kafka 的托管服务，兼容 Kafka 开源协议。适合大数据场景和已有的 Kafka 生态。

### 自建 vs 托管对比

| 维度 | 自建 | 托管 |
|------|------|------|
| 初始成本 | 低（开源免费） | 低（按量付费） |
| 规模成本 | 人力成本高 | 使用量大时费用可观 |
| 灵活性 | 完全可控 | 受限于云厂商功能 |
| 运维负担 | 重（团队需有专人） | 几乎为零 |
| 数据主权 | 数据完全自控 | 数据在云厂商处 |
| 性能 | 可深度调优 | 黑盒，调优空间有限 |

> [!question]
> 自建 Kafka 集群 vs AWS MSK，在什么规模下自建更划算？提示：计算人力成本 + 机器成本 vs MSK 的按量计费。

### 云原生 MQ 趋势

云消息服务正在向更"原生"的方向演进：

**Serverless MQ**

不需要预配置集群，按实际消息量计费。SQS、Google Pub/Sub、MSK Serverless 都是这个方向。对于流量波动大的业务特别友好。

**事件总线（EventBridge）**

AWS EventBridge 是事件驱动架构的基础设施。它不只是消息队列，而是一个完整的事件路由中心——支持事件过滤、转换、重放，以及与 30+ AWS 服务的原生集成。

**MQ + Functions 集成**

消息触发云函数（Lambda/Cloud Functions），实现真正的事件驱动计算。消息到达 → 自动触发函数 → 处理完成 → 释放资源。完全不需要管理消费者进程。

```mermaid
graph TB
    subgraph "云消息服务产品矩阵"
        subgraph "AWS"
            SQS["SQS - 标准队列"]
            SNS["SNS - 发布订阅"]
            MSK["MSK - 托管Kafka"]
            EB["EventBridge - 事件总线"]
        end
        subgraph "Azure"
            ASB["Service Bus - 企业级"]
            EH["Event Hubs - 高吞吐流"]
        end
        subgraph "GCP"
            GPS["Pub/Sub - 全球分布式"]
        end
        subgraph "阿里云"
            RMQ["RocketMQ版"]
            AK["Kafka版"]
        end
    end
    subgraph "核心能力"
        Q["队列模式"]
        PS["发布订阅"]
        STR["流式处理"]
        EVT["事件路由"]
    end
    SQS --> Q
    SNS --> PS
    MSK --> STR
    EB --> EVT
    ASB --> Q
    ASB --> PS
    EH --> STR
    GPS --> PS
    GPS --> STR
    RMQ --> Q
    RMQ --> PS
    AK --> STR
```

## 关联笔记

- [[44-MQ-高可用架构]]
- [[45-MQ-跨集群复制与容灾]]
- [[47-MQ-与微服务]]