RocketMQ Schema——让消息成为流动的结构化数据

本文作者：许奕斌，阿里云智能高级研发工程师。

Why we need schema

RocketMQ 目前对于消息体没有任何数据格式的约束，可以是 JSON ，可以是对象 toString ，也可以只是 word 或一段日志，序列化与反序列化过程完全交给用户。业务上下游也需要对于消息体的理解达成一致，方可基于 RocketMQ 进行通讯。而以上现状会导致两个问题。

首先，类型安全问题。假如生产者或消费者来自完全不同的团队，上游对数据格式进行了微小但不兼容的改动，可能导致下游无法正常地处理数据，且恢复速度很慢。

其次，应用扩展问题。对于研发场景，虽然 RocketMQ 实现了链路上的解耦，但研发阶段的上游与下游依然需要基于消息理解做很多沟通和联调，耦合依然较强，生产端的重构也需要连累消费端一起变更。对于数据流场景，如果没有 schema 定义，每次在构建ETL时需要重写整个数据解析逻辑。

RocketMQ schema 提供了对消息的数据结构托管服务，同时也为原生客户端提供了较为丰富的序列化/反序列化 SDK ，包括 Avro、JSON、PB等，补齐了 RocketMQ 在数据治理和业务上下游解耦方面的短板。

如上图所示，在商业版 Kafka 上创建 topic 时，会提醒维护该 topic 相关 schema。如果维护了 schema ，业务上下游看到该 topic 时，能够清晰地了解到需要传入什么数据，有效提升研发效率。

我们希望 RocketMQ 既能够面向 App 业务场景，也能够面向 IoT 微消息场景，还能面向大数据场景，以成为整个企业的业务中枢。

加入 RSQLDB 之后，用户可以用 SQL 方式分析 RocketMQ 数据。RocketMQ 既可以作为通信管道，具备管道的流特性，又可以作为数据沉淀，即具备数据库特性。如果 RocketMQ 要同时向流式引擎和 DB 引擎靠近，其数据定义、规范以及治理变得异常重要。

面对业务消息场景时， 我们期望 RocketMQ 加入 schema 之后能够拥有以下优势：

①数据治理：避免消息脏数据产生，避免 producer 产生格式不规范的消息。

②提升研发效率：业务上下游研发阶段或联调阶段沟通成本降低。

③托管“契约”：将契约托管后，可以实现真正意义上的业务上下游解耦。

④提升整个系统的健壮性：规避下游突然无法解析等数据异常。

面对流场景，我们期望 RocketMQ 具备下列优势：

①数据治理：能够保证整条链路数据解析的流畅性。

②提升传输效率：schema 独立托管，无需附加到数据之上，提升了整个链路传输的效