RobustMQ Gateway：多协议生态的极简接入层
概述
RobustMQ Gateway 是 RobustMQ broker 内部的一个模块，通过 gRPC 对外暴露三个方法：send、receive、ack。业务只需要指定 topic，不需要了解任何底层协议，直接发送和接收消息。
为什么需要它？RobustMQ 已经支持 MQTT、Kafka、NATS、AMQP、mq9 多种协议，每种协议都有完整的语义和生态。但现实中有大量业务场景不需要这些复杂性——他们只需要往某个 topic 写数据，另一端能拿到，不丢就行。选协议、学 SDK、处理上下游协议耦合，这些对业务团队来说是负担，不是价值。
Gateway 解决的就是这两个问题：降低接入门槛，解耦上下游。
单独存在，它没有竞争力，市场上简单的消息队列太多了。但放在 RobustMQ 的多协议架构里，它是一个重要的补充——send 进来的数据进入统一存储层，下游可以用 Kafka、MQTT、mq9 任意方式消费。上游改了下游不用改，下游改了上游不用改。这是 Gateway 真正的价值所在。
核心价值：上下游各自自由
Gateway 的设计目标有两个：够简单，以及上下游不用改。
数据写入 Gateway 后，进入 RobustMQ 的统一存储层。下游可以用任何协议消费——Kafka consumer、MQTT subscriber、或者通过 Gateway 的 receive。上游不需要知道下游用什么协议，下游也不需要知道上游怎么写入。
上游团队 下游团队
send(topic, data) → Kafka consumer 消费
→ MQTT subscriber 消费
→ receive(topic) 拉取
→ receive(topic, stream=True) 流式上游改了，下游不用改。下游改了，上游不用改。两端各自独立演进。
这对有历史包袱的系统尤其有价值。上游几十个服务耦合在某个协议上，迁不动——接入 Gateway 后，上游只知道一个 topic，底层协议怎么换、存储怎么迁，上游完全感知不到。
和现有协议的关系
Gateway 不是一个协议，而是一种接入方式。它和 MQTT/Kafka/NATS/AMQP/mq9 并列，但定位不同——那些是协议，Gateway 是一个极简的接入通道，底层复用 RobustMQ 的统一存储层。
MQTT | Kafka | NATS | AMQP | mq9 | Gateway
────────────────────────────────────────────────────────
统一存储层不替代，只补充。有明确协议需求的继续用对应协议，不想选协议的用 Gateway。按需选用，没有强制迁移。
服务端 gRPC
Gateway 的通信层选择 gRPC。gRPC 是成熟的生产级 RPC 框架，protobuf 定义接口，各语言 SDK 直接生成，连接管理、重试、超时、TLS 全部框架处理，原生支持 server streaming。对 Gateway 来说，gRPC 意味着零 SDK 开发成本——Python、Go、Java、Rust、JavaScript、C# 全覆盖，和 RobustMQ 现有 SDK 矩阵完全对齐。
接口定义：
service RobustMQGateway {
rpc Send(SendRequest) returns (SendResponse);
rpc Receive(ReceiveRequest) returns (ReceiveResponse);
rpc ReceiveStream(ReceiveRequest) returns (stream Message);
rpc Ack(AckRequest) returns (AckResponse);
}Receive 和 ReceiveStream 是同一语义的两种模式：拉取和流式推送。
SDK 暴露的方法
SDK 层将 gRPC 接口封装成三个方法，stream 参数决定使用拉取还是流式模式：
# 写入消息
client.send(topic, payload)
# 拉取（一次拿一批，对应 Receive）
msgs = client.receive(topic, limit=10)
for msg in msgs:
process(msg)
client.ack(topic, msg.msg_id)
# 流式（消息到达时自动推送，对应 ReceiveStream）
for msg in client.receive(topic, stream=True):
process(msg)
client.ack(topic, msg.msg_id)
# 确认消息已处理，消息不再重复投递
client.ack(topic, msg_id)没有协议选择，没有 consumer group，没有 offset 管理。一个 topic，三个方法，全部搞定。
总结
Gateway 的定位不是为了堆协议，也不是为了做一个新的消息队列产品。
单独做一个 send/receive/ack 的消息队列，没有意义。市场上这类产品太多，没有竞争力。
但从实际经历来看，这种轻量的接入方式其实很受欢迎。没那么多参数要配置，没那么多概念要理解，上下游也不用改。业务就是喜欢简单的东西。
Gateway 看中的是 RobustMQ 的多协议架构和统一存储底座。一旦有了这个能力，Gateway 的价值就完全不同了——上下游可以各自独立演进，甚至同一个项目里有的接口改、有的接口不改，都可以。完全没有改造适配成本。以前该怎么用还是怎么用，业务可以按自己的节奏逐步收敛，降低使用成本。
Gateway 只是补充，不是强制。但这个补充放在 RobustMQ 的多协议、统一存储上，就很有价值。
系统复杂度降低了，出问题的风险自然也降低了。这也是 RobustMQ 的核心价值之一：降低业务和企业的系统复杂度。不是让用户迁移到一套新的技术栈，而是在现有基础上，尽可能低成本地给用户更多选择。