MQ| OpenMessaging 规范

本文主要是介绍MQ| OpenMessaging 规范，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

OpenMessaging 规范解读

执照
0 概述
0.1 什么是OpenMessaging？
OpenMessaging 是一种云原生、与供应商无关的分布式消息传递开放标准。

0.2 为什么选择OpenMessaging？
0.2.1 目标
消息传递产品已广泛应用于现代架构和数据处理，用于解耦、排队、缓冲、排序、复制等。但是，当数据跨不同的消息传递和流式传输平台传输时，就会出现兼容性问题，这总是意味着很多额外的工作。虽然 JMS 在过去十年中是一个很好的解决方案，但它在 Java 环境中受到限制，缺乏针对负载平衡/容错、管理、安全性和流式传输功能的特定指南，这使得它无法满足现代云原生消息传递和流式传输应用程序的需求。而 OpenMessaging 的目标是：

与语言无关且与平台无关。消息标准支持多种平台、架构或系统。
分布式消息传递的全球性、云原生、供应商中立的行业标准。
为测试应用程序提供标准基准。
针对云数据流和消息传递需求，内置可扩展性、灵活性、隔离性和安全性，培养日益壮大的贡献开发人员社区。
0.2.1 非目标
以下内容不属于本规范的一部分：

特定于语言的运行时 API。
用于评估性能的基准界面。
用于与其他系统交换数据流的连接器接口。
0.3 OpenMessaging 术语
0.3.1 主题
封装消息传送的消息目标身份的受管理对象。

0.3.2 生产者
向某个主题的所有消费者发送消息的对象。

0.3.3 消费者
用于接收发送至主题的消息的对象。

0.3.4 队列
封装消息目标身份的受管理对象。

0.3.5 传递语义
在描述传递机制的语义时，生产者和消费者之间有三个语义保证：
至少一次：一条消息至少会被消费一次。
最多一次：一条消息最多会被消费一次，在此语义下，消息可能会丢失。
恰好一次：一条消息只会被消费一次且仅一次。

1 类型系统
以下抽象数据类型可用于属性。

String- 可打印的 Unicode 字符序列。
Binary- 字节序列。
KeyValue- -typed 或-typed 或-typed 值String的索引字典StringBinaryNumeric
Numeric：

Short- 范围在 -(2^15) 到 2^15 - 1 之间的整数（含）。 - Integer- 范围在 -(2^31) 到 2^31 - 1 之间的整数（含）。
Long- 范围在 -(2^63) 到 2^63 - 1 之间的整数（含）。
Float- 32 位浮点数（binary32 IEEE754）。
Double- 64 位浮点数（binary64 IEEE754）。
Object- 要么 a String，Binary要么 a ，KeyValue要么 aNumeric
URI- 符合RFC 3986 §4.1URI-reference 中的定义的字符串表达式。
类型是变体类型，可以采用 a或 a或 a或 aObject的形状。类型系统是有意抽象的，因此如何表示变体类型留给实现（参考CloudEvents的描述）。StringBinaryKeyValueNumericObject

2 消息模型
2.1 消息类型
2.1.1 字节消息
消息主体包含未解释字节流的消息。此消息类型用于按字面意思对主体进行编码以匹配现有消息格式。它将使用一种自定义消息类型对消息主体进行编码，供应商负责按照自定义规则解码这些字节。

2.2 消息格式
在OpenMessaging中，一条消息由4部分组成：版本，凭证，系统头，用户头和消息体。

2.2.1 版本
类型：String
描述：OpenMessaging 标准的版本。
约束：必需
2.2.2 标头
类型：KeyValue
描述：所有消息都支持同一套头字段，这些头字段是系统使用的，通常用于识别、路由消息等。具体字段请见下一章。
约束：必需
2.2.3 扩展头文件
类型：KeyValue
描述：该字段包含消息中间件的扩展元数据，这些扩展字段不是必需的，但就目前而言，大多数消息中间件已经或多或少地实现了相关内容，并且这些字段已经被许多消息和流开发人员所熟知和理解，请参阅 ExtFields 文档了解可能的属性列表。请参阅扩展头文档了解可能的字段列表。
约束：可选
2.2.4 属性
类型：KeyValue
描述：除了系统标头之外，OpenMessaging 还提供了内置的用户属性，用于向消息中添加可选字段，这些字段以键值形式表示。
约束：必需
2.2.5 数据
类型：Binary
描述：该字段是传输数据的一部分，即实际预期的消息包含应用程序数据。
消息体对服务器完全透明，服务器无法查看或修改消息体。
约束：可选
2.3 消息头
2.3.1 消息ID
类型：String
描述：消息的唯一标识符。发送消息时，messageId 将被忽略。send 方法返回时，它包含提供者指定的值。
约束：必需且必须非空String。
2.3.2 bornTimestamp
类型：Long
描述：客户端发送的消息的时间戳。它不是消息实际传输的时间，因为实际发送可能由于事务或其他客户端消息排队而稍后发生。
发送消息时，bornTimestamp将被忽略。当发送方法返回时，该字段包含调用和返回之间的某个时间间隔内的时间值。
它表示为一个长值，定义为此时间与 1970 年 1 月 1 日午夜 UTC 之间的差值（以毫秒为单位）。
约束：必需
2.3.3 bornHost
类型：String
描述：当发送消息时，此字段将设置为客户端的本地主机信息。
约束：必需且必须非空String。
2.3.4 QoS
类型：Integer
描述：OpenMessaging 定义了三种消息传递模式，如前所述：
至少一次：如果该值设置为 0，则一条消息至少会被消费一次，该值应设置为默认值。
最多一次：如果该值设置为 1，则一条消息最多会被消费一次，在此语义下，消息可能会丢失。
恰好一次：如果该值设置为 2，则一条消息只会被消费一次。
2.3.5 压缩
类型：String
描述：该字段表示消息体的压缩算法。
供应商可以自由选择压缩算法，但必须确保将解压缩的消息传递给用户。
约束：可选
2.3.6 目的地
-类型：String -描述：此字段包含消息被发送到的逻辑目标，例如队列或主题。当发送消息时，此值设置为正确的队列，然后消息将被发送到指定的目标。当收到消息时，其目标相当于消息所在的队列。

约束：必需
符号约定
本文档中的关键词“必须”、“不得”、“要求”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选”应按照RFC 2119中的规定进行解释。

OpenMessaging 常见用例
本文档列出了 OpenMessaging 支持的最常见用例。

P2P
发布/订阅
播送
公路
流媒体
筛选
路由
RPC
P2P

P2P，点对点，最简单的一种，这种情况下，Queue 是 OpenMessaging 涉及的唯一资源，只有一个分区。简单来说，Producer 把消息发到 Queue，然后再被 Consumer 消费。

发布/订阅
这种情况下，Producer会以Round-robin或者Hash的方式将消息发送到具有多个分区的Queue中，而这些分区会定期分配给已经订阅了指定队列的消费者。

如果需要的话，主题和路由模型也可以导入到此案例中，如下所示。

播送

在广播情况下，任何发送到队列的消息都会被所有消费者消费。

公路

在高速公路情况下，SequenceProducer 的唯一关注点就是速度，Producer 总是想把大量且不太重要的消息发送到 Queue 中。Batch 是实现方式之一。

流媒体

StreamingConsumer 适用于此用例，它是一个面向流的消费者，可轻松将消息系统与 Streaming/BigData 相关平台集成。StreamingConsumer 支持从指定队列的分区（如迭代器）消费消息。

筛选
大部分情况下，原始的消息不能引起消费者的兴趣，而消费者总是想消费处理过的消息，最有用的处理方式就是Filter。

如下图所示，OpenMessaging 的 Routing 模型可以很方便地应用到 Filter 中，在本例中，消息会经过两个过滤算子路由到 Queue，保留带有 Student 标签且 age 属性在 18~23 之间的消息。

复制

有时，生产者和消费者分布在多个数据中心，OpenMessaging 提供了一种将消息从一个区域路由到另一个区域的简单方法。

RPC

在OpenMessaging中，RPC相当于同步消息，它不是传统的CS(Client2Server)模型，而是CSC(Client2Server2Client)模型。

附录
OpenMessaging API 示例
{
“message”: {
“version”:“1.0.0”,
“header”: {
“messageId”: “7F00000100002873000000000004F49C”,
“destination”: “orderQueue”,
“bornTimestamp”: 1533780827824,
“bornHost”: “172.24.0.101:10035”,
“compression”: “gzip”,
“qos”: 1
},
“extensionHeader”: {
“partition”: 1,
“storeTimestamp”: 1533780827825,
“storeHost”: “172.24.0.102:52511”,
“messageKey”: “orderId-103368921567”,
“correlationId”: “7F00000100002873000000000004F2B4”,
“delayTime”: 30000,
“transactionId”: “1E0578887D3F18B4AAC22B64D2B40A62”,
“expireTime”: 1533780830000,
“traceId”: “1E0578887D3F18B4AAC22B64D2B00A5E”,
“priority”: 1
},
“properties”: {
“service”: “helloService”
},
“data”: {}
}
}
变更历史
创建0.3.0版本，兼容现有运行时API。
创建1.0.0-预览版本，修改领域模型为基于队列的模型，增加类型系统与schema。
创建1.0.0-alpha版本，简化规范，增加扩展字段。