开发者学堂课程【消息队列 RocketMQ 全类型业务消息学习课程 ：Apache Rocket MQ 阿里云大规模商业化实践之路（二）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1200/detail/18161
Apache Rocket MQ 阿里云大规模商业化实践之路
五、Rocket MQ5.0云原生架构升级之路
1、MQ5.0诞生的背景
在云原生时代大家都知道，云原生这个理念其实逐渐的深入人心，那云上的用户就是对云产品这个服务化的程度，包括弹性能力和关注性能力以及韧性都有更高的要求。在这个背景之下，对 MQ 进行了一个云原生价格升级，这也是 MQ5.0诞生的背景。
2、MQ5.0架构全景
这是装配5.0的一个价格全景，就是大概在几个方面对 MQ 做了一个比较大的升级。
（1）轻量级 SDK
第一块就是轻量级 SDK，基于云原生通信标准 gRPC 开发了一种轻量级 SDK，能够做到和当前客户端做了一个优势互补。
（2）无状态消息网关
同时在核心数据电路推出了一个无状态的消息网关，通过搭建一个无状态的服务的节点 Proxy，然后再通过 LB 进行一个服务暴露，将存储节点进行分离，来独立负责一个核心的消息存储和高可用。Proxy 和 Store 节点能够做到一个分离部署和独立弹性。
（3）Leaderless 高可用架构
在可用性方面推出了 Leaderless 高可用架构。整个架构的一个特点，就是 Store 节点的身份完全对等，完全是 Leaderless 化的，去 ZK 和 HA 管控节点，能够做到非常高的可用性和故障转移能力。同时相比传统的协议，该 Leaderless 架构能够做到副本数的灵活选择。同步异步能够做到一个自动升降级，做到秒级故障转移。
整个高可用架构目前也正在与开源的 DLedger 相融合。
（4）云原生基础设施
包括整个可观测性能力云原生化，OpenTelemetry 标准化，整体架构走向 Kubernetes 化，充分利用售卖区的弹性能力。
3、全新轻量级多语言 SDK
一直以来 MQ 推荐的结构方式主要是富客户端，富客户端其实提供了一个诸如客户端侧的负载均衡、消息缓存、故障转移等一系列企业级特性。在云原生时代，轻量级高性能的客户端其实更加容易被云原生的技术栈集成的。MQ5.0非常重要的一块就是推出了全新的多元的轻量级的 SDK，它包括以下几部分：
（1）全新极简的 API
首先是一套不可变的 API，有完善的错误处理。多元的 SDK 也保障 API 在 native 层面对齐，同时引入了全新的消费者，引入了一个 全新的 Simple Consumer，能够支持按消息模型进行消费。用户不需要在关心消息对立，只需要关注消息。
（2）通信层采取 gRPC
拥抱云原生通信标准 gRPC，使得服务更容易被集成。多语言 SDK 通讯层代码也可以通过 gRPC 能够快速生成，更加 native，把多语言 SDK 开发出来。
（3）轻量级实现
另外采取了一个轻量级实现，采用无状态的消费模式能够大幅度降低客户端的实现复杂度。因为客户端更加轻量，集成的应用也更容易 Severless 化，Mesh 化。
（4）云原生可观测性
在云原生可观测化方面，客户端完全实现了 OpenTelemetry 标准，支持以 OpenTelemetry 的形式导出 Metrics 和Tracing。
4、无状态的消费模型
另一块比较重大的升级是引入了一个全新的无状态的消费模型。该消费模型的是完全构建在原来的一个队列模型之上的。那先简单介绍一下对立模型。它是与存储模型一致的一个消费模型，也就是说消费者是完全按照对列去做，负载均衡也按照对列去做一个消息拿取。所以这种消费模型是非常适合一个批量的高速拿取。对单条消息状态不敏感的场景，比如说云计算的场景。5.0推出一个 pop 机制，还是巧妙的在对列模型之上构建了一个消息模型，可以说是鱼和熊掌兼得。就在这个消息模型的设计上业务是只关心消息，可以不关心对列。所有的 API 都是能够支持一个单条消息级别的消费从事，包括修改不可见时间，包括删除。比如说一条消息的一个状态，在消息模型实际上是这样的。首先消息发送过来被传输过后，对消费者就是可见的。当消费者通过 receive API 将消息消费过后，这个消息进入一个定时不可见的状态。当这条消息超时过后这条消息又会重新处于一个可见的状态，又能被其他消费者所消费走。那当某一个消费者对这类消息确认过后，服务端就会对该消息进行删除，删除过后消息就不可见了。这是一个基于消息模型的消费的流程，APS 完全是面向消息，而不是面向队列的。当 pop 这种无状态的消息消费方式遇见了无状态的Proxy，可以发现整个设计除了存储层，客户端是无状态的，连接也是无状态，可以任意在 Proxy 上作为漂移。消费也是无状态的，真正做到一个非常轻量级的状态的设计。
5、Logging，Tracing&Metrics
在可观测性方面，刚才讲的在4.0时代做了很多的探索积累，今天经过同一个重构啊，走向了一个云原生的标准。那包括以下几部分。
（1）Metrics：Dashborad 大盘
设计了更丰富的指标，包含消息量、堆积量、各个阶段的耗时等指标，每个指标能够做到从实例 Topic 消息消费 GroupID 多维度的一个聚合和展示。同时基于这份数据也利用 Grafana 对它做一个展示。消息团队配了一个最佳时间模板，在控制台上其实完全是可以自定义展示大盘。
（2）Tracing：消息轨迹
在消息轨迹这一块，将 MQ4.0的缺失的标准其实合并到一个 OpenTelemetry 标准当中，其实对一些 messaging Tracing的定义也合得了开源社区当中，被 OpenTelemetry 社区所接纳了。另外的话在消息领域对 Tracing 也做了一个定制化的展示，比如说按照消息维度重新组织抽象的一个示范数据来展示一对多的消费，多次消费信息能够非常直观，容易被用户理解。同时的话，在 SDK 测也能够将 Tracing 数据能够 explode 出去，方便用与自己的其他系统做一个集成。
（3）Logging：客户端日志标准化
在日志这一块的话，客户端日志走向标准化，包括有完整的一个 error code 的设计，所有的 SDK 都会对这份设计做一个对齐，包括error message，error level走向标准化。
6、计算、存储与网络
在弹性方面的话，其实 MQ5.0的商业版能够充分撬动阿里云这边的一个超大规模的资源池。
（1）计算
比如说在计算方面，整个 MQ5.0所有的一个工作负载完全是部署在 ACK 之上的。充分利用 ACK 的弹性能力，能够去撬动 ECS这个弹性资源。这里面首先会依赖 ACK 两项技术，一项是弹性资源池，一项是 HPA，能够支持一个计算能力和快速弹性。同时 ACK 也会在 ECS 之上做一个跨可用区的步数来提供高可能的保障。
（2）网络
在网络层面的话，MQ5.0也会充分去利用阿里云的一个网络设施，能够给用户提供一个更便捷的一个网络访问能力。比如说 MQ5.0的一个实例会支持一个公网随开随用，当需要依赖公网作业测试的时候，可以方便的打开。测试完毕后可以立刻把公网关掉，能够做到一个安全和方便间距。同时也支持多种私网类型的一个网络形态，包括Private Link。另外也基于 CEN 构建了一个全球互通的学习网络。
（3）存储
在存储这一块的话，MQ5.0商业版是率先议论一个多级层次的概念，基 OSS 构建的一个二级存储，能够充分利用 OSS 弹性原理。同时存储的计费也走向了一个按量付费，用户能够在 MQ 之上去自定义的一个消息存储市场。比如说将消息从三天的有效时长延长至30天，能够真正的让用户将消息变为一个数据资产。同时利用二级存储能力可以将两个数据进行分离，能够为用户提供一致的冷读 SLA。这是MQ5.0在弹性方面做的一些努力，能够充分去利用与那个弹性能力去撬动一些计算、存储和网络的池化资源，能够满足阿里云上企业用户的一个各类产业需求。
六、Rocket MQ5.0商业版发布预告
MQ4.0其实已经经历五年的发展，到今天开源和商业共同迈入5.0时代。阿里云消息队列会基于开源版将发布一个全新的5.0的商业化版本。新的商品相对于4.0的实例主要有几大改变。
1、新版本、新售卖，更便宜
第一个是新的版本它采取了一个全新的纪念方式，有包年包月型的，有按量付费型的，然后部分的比如包括存储、功耗流量能走向了一个弹性计费。同时也有更全的一个售卖体系，比如说新增的专业版的一个实例能够满足部分用户的需求，同时每个商品系列都新增了一个测试管理的专用实力，能够方便用户以低售卖的方式去搭建自己的开发环境。
2、更强弹性，降本提效利器
第二块的话是有一个更强的弹性能力，包括存储完全走向了弹性，能够通过采取按使用量付费的方式。计算弹性这一块首先是有两部分，一个是预留弹性，实例基础规格上是支持实时升降配的。用户可以很方便的在流量到来之前立刻去做个弹性，就比如说有些业务知道自己是中午12点有流量高峰，可以立刻来去做一个升配，高峰过后可以做一个降配。
3、全新架构，增强可观测运维
对于突发流量的话，其实专业版也是支持一个突发流量弹性的，能够解决一个线上的风险。刚刚采取了一个全新的5.0的架构啊，包括无状态的消息模型，能够解决一些4.x的版本的痛点。同时在可观测性方面是全面采取了云原生的旧账。整个的5.0的一个商品预计在七月底，八月初就会正式发布，到时候欢迎大家在线上使用。
七、消息的全新形态：事件总线 Event Bridge
1、Event Bridge：RocketMQ 之上的事件驱动架构实践
这一块为大家介绍的是阿里云的消息的全新形态事件总线，该产品目前也开源到 MQ 社区当中了。今天其实重新提试验区段的一个重要原因其实在于云原生时代事件是无处不在的，同时云的计算资源也散落在各个地方，那在开源和云的大家可以看到各类生态孤岛是随处可见的，所以说以事件和事件驱动的方式来集成这一切的是一个理所当然的事情。以基于这个背景阿里云推出了一个全新的世界性产品，整个产品其实也是构建在 MQ 之上的，那把它作为 MQ 之上的事件区的那个架构实践。
（1）事件源
首先简单为大家介绍一下这个产品的一个模型。整个产品的资源模型分为几类。第一类是世界语言，那世界语言类型有很多啊，包括阿里云的语音服务的一些管控事件，比如说资源变更事件、审计事件，包括配置变更事件，或者是说阿里云的云服务的一些数据事件，例如数据库中的数据，消息里面的数据。另一个还包括自定义应用，应用可以自己发现事件包括 SaaS 应用也在时刻产生事件，这些都可以作为Event Bridge的事件源，那这就是 Event Bridge 的一端。
（2）事件目标
它的另一端就是事件目标，那事件通过Event Bridge进行处理过后可以投递到事件目标。阿里云 Event Bridge 现在集成了大量的事件目标，包括计算类型的函数计算和消息类型的消息服务。也包括自建的网关HTTP（S），同时也包括一些通知型目标，比如短信、邮箱、钉钉。那在世界源到世界目标之间会经历完整的一个事件的处理。
比如事件源接入到 Event Bridge 过后，它可以对这个事件做一些过滤和转换，也可以对事件做一些归档和回放。同时事件在 Event Bridge 的整个流程当中也完善了一个可观测性的设计，包括实践查询，包括链路追踪。
（3）事件接入方式
事件的接入方式也是非常多的，比如说包括可以通过Open API的接入。官方也发布了七种多语言SDK，同时也支持 CloudEvents 社区的 SDK，也支持通过控制台去发一个事件，通过 hook 去接入这些事件。
（4）Event Bridge 的特点
①减少用户开发成本
一个是能够大幅度减少用户开发成本，通过用户无需额外的一个开发，通过创建 Event Bridge 的事件源、事件目标、事件规则等资源，就能够去实现一个实践区的架构。比如说用户可以去编写一个事件规则，对事件做一些过滤，针对利用性的过滤，包括对事件做一些丰富的转换能力。
②原生 Event Bridge 支持
第二块的话，整个 Event Bridge 是提供一个原生的 CloudEvents支持。拥抱了 CNCF 社区，能够无缝对接社区的 SDK。整个标准协议也统一阿里云的实践规范。
③事件 Schema 支持
第三块的话，是支持一个事件 Schema 的支持，包括能够支持事件Schema 的一个自动的探测和校验。Source 和 Target能够支持 Schema 的绑定。
④全球事件任意互通
第四个特点是基于阿里云的一个声音网络能力，组建了一个全球世界事件任意互通的网络，就是组建了一个跨地域跨账户的事件网络，能够支持跨云跨数据中心的一个事件路由。这是 Event Bridge 基于 MQ 构建的一些模型实践与价格实践。
2、Event Bridge 云上生态初具规模
（1）云产品集成生态
目前 Event Bridge 在云上的生态其实已经初具规模了，在原产品集成的这一块，集成了255+云产品事件源，同时包含1000+种事件类型。
（2）消息生态融合
另外的话 Event Bridge 率先对消息生态做了一个融合，阿里云的六款消息产品，整个消息产品矩阵的生态都通过一对一做了完全融合，所以任何一款消息产品和另一款消息产品的数据是互通的，同时依靠 Event Bridge 的全球的事件网络，为所有的消息产品都赋予了全球消息都有的能力。
（3）ISV 生态
第三块生态是 ISV 生态，Event Bridge 目前已经比如在内部已经接入了一个钉钉 ISV。同时一些外部的50+SaaS 系统都可以通过 Webhook 的方式接入到 Event Bridge 当中。
（4）事件驱动生态
在事件驱动生态这一块，海量的事件源都可以触达10+种事件目标，现在已经对接了全量的、全系列的云产品的 API，任何一个事件都可以驱动全量的云产品 API，整个驱动能力即将上线。
整个 Event Bridge 的简单的介绍就到这里，Event Bridge 目前也是在开源的状态，也欢迎各个开发者一起来共建 Event Bridge 的一个实验生态。
