简介： 本文整顿自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，次要探讨了传统的消息中间件如何继续进化为云原生的音讯服务。

作者 | 周礼（不铭）阿里巴巴团体消息中间件架构师

导读 ：本文整顿自作者于 2020 年云原生微服务大会上的分享《云原生时代的消息中间件演进》，次要探讨了传统的消息中间件如何继续进化为云原生的音讯服务。

引言

本文以一张云进化历史图收场，来谈谈云原生时代消息中间件的演进路线，但本文相对不是“开局一张图，内容全靠编”。

从虚拟化技术诞生以来，IaaS / PaaS / SaaS 概念陆续被提了进去，各种容器技术层出不穷。到 2015 年，Cloud Native 概念应运而生，一时间，各种云厂商，云服务以及云利用都加上了“云原生”前缀。

咱们也始终在思考，传统的消息中间件须要做些什么能力加上云原生这个修饰词，这也是本文探讨的主题：传统的消息中间件如何继续进化为云原生的音讯服务。

云原生音讯服务

1. 什么是云原生

首先来谈谈什么是云原生，云原生是一个人造实用于云计算的架构理念，实际云原生技术理念的利用能够最大化享受云计算的技术红利，包含弹性伸缩、按量付费、无厂商绑定、高 SLA 等。

利用在实际云原生技术理念时个别会遵循四个因素：

• 采取 DevOps 畛域的最佳实际来治理研发和运维流程；
• 通过 CICD 工具链做到利用的疾速迭代和继续交付；
• 采取微服务架构；
• 采取容器及相干技术进行利用的托管。

音讯服务作为利用的通信基础设施，是微服务架构利用的外围依赖，也是实际云原生的外围设计理念的关键技术，通过音讯服务可能让用户很容易架构出分布式的、高性能的、弹性的、鲁棒的应用程序。音讯服务在云原生的重要性也导致其极可能成为利用实际云原生的阻塞点，所以音讯服务的云原生化是至关重要的。

2. 什么是云原生音讯服务

先说论断，咱们认为云原生音讯服务是云原生的通信基础设施。2015 年成立的 CNCF 基金会大范畴推广了云原生的技术理念，并提供了一套残缺的实际技术工具集，帮忙开发者落地云原生理念。这套工具集收录于 CNCF 云原生全景图，其中消息中间件处于利用定义和开发层的 Streaming 和 Messaging 类目。

消息中间件在云原生的利用场景，次要是为微服务和 EDA 架构提供外围的解耦、异步和削峰的能力，在云原生全景图定义的其它档次畛域，音讯服务还施展着数据通道、事件驱动、集成与被集成等重要作用。

另外云原生提倡面向性能设计，基于音讯队列的异步调用可能显著升高前端业务的响应工夫，进步吞吐量；基于音讯队列还能实现削峰填谷，把慢服务拆散到后置链路，晋升整个业务链路的性能。

3. 云原生音讯服务演进方向

云原生时代对云服务有着更高的要求，传统的音讯服务在云原生这个大背景下如何继续进化为云原生的音讯服务，咱们认为方向有这么几个：

1）高 SLA 

云原生利用将对音讯这种云原生 BaaS 服务有更高的 SLA 要求，利用将假如其依赖的云原生服务具备跟云一样的可用性，从而不须要去建设备份链路来进步利用的可用性，升高架构的复杂度。只有做到与云一样的可用性，云在服务就在，能力称为真正的云原生服务。

2）低成本 

在过来，每家公司自建消息中间件集群，或是自研的、或是开源的，须要投入微小的研发、运维老本。云原生时代的音讯服务借助 Serverless 等弹性技术，无需事后 Book 服务器资源，无需容量布局，采取按量付费这种更经济的模式将大幅度降低老本。

3）易用性 

在云原生时代，音讯服务第一步将进化成为一种所见即所得、开箱即用的服务，易用性极大的进步。接下来，音讯服务将以网格的模式触达更简单的部署环境，小到 IoT 设施，大到自建 IDC，都能以跟私有云同样易用的形式接入音讯服务，且能轻易地满足云边端一体化、跨 IDC、跨云等互通需要，真正成为应用层的通信基础设施。

4）多样性

云原生音讯服务将致力于建设大而全的音讯生态，来涵盖丰盛的业务场景，提供各式各样的解决方案，从而满足不同用户的多样性需要。阿里云音讯队列目前建设了多个子产品线来撑持丰盛的业务需要，比方音讯队列 RocketMQ，Kafka，微音讯队列等。

5）标准化 

容器镜像这项云原生的核心技术轻易地实现了不可变基础设施，不可变的镜像打消了 IaaS 层的差别，让云原生利用能够在不同的云厂商之间随便迁徙。但实际上，很多云服务提供的接入模式并不是规范的，所以依赖这些非标准化云服务的利用造成了事实上的厂商锁定，这些利用在运行时是无奈实现真正的按需迁徙，所以只能称为某朵云上的原生利用，无奈称为真正的云原生利用。因而，音讯服务须要做到标准化，打消用户对于厂商锁定的担心，目前阿里云音讯队列驳回了很多社区规范，反对了多种开源的 API 协定，同时也在打造本人标准化接口。

总结一下，传统的音讯队列将从高 SLA、低成本、易用性、多样性和标准化几个方向继续进化为云原生的音讯服务。

云原生音讯三化

谈到云原生，离不开 Kubernetes、Serverless 以及 Service Mesh，接下来为大家分享下咱们如何利用 K8s 社区的生态红利，如何实际 Serverless 和 Service Mesh 技术理念。

1. 云原生音讯 Kubernetes 化

Kubernetes 我的项目当下相对是大红大紫，在容器编排和利用托管畛域相对的事实标准，整个社区也是生机盎然。所以，必须将咱们的音讯服务降级为 K8s 环境开箱即用的服务。

云原生音讯 Kubernetes 化是指通过自定义 CRD 资源将有状态的音讯集群托管至 Kubernetes 集群中，充分利用

K8s 提供的部署、降级、自愈等能力进步运维效率，同时尽可能享受 K8s 的社区生态红利。

咱们在 RocketMQ 开源社区也提供了 CRD 形容文件以及相应的 Operator 实现，通过这套实现，能够疾速部署 RocketMQ 集群至 K8s 环境；利用 K8s 的能力低成本运维 RocketMQ 集群；也能够应用云原生的 Prometheus 察看集群指标。

RocketMQ 实现 Kubernetes 化后，就变成了 Kubernetes 环境原生可拜访的一个音讯服务，将给开发者带来极大的便利性。

同时，在商业化环境，咱们也正在依赖 Kubeone 将音讯队列系列产品实现 Kubernetes 化。

2. 云原生音讯 Serverless 化

Serverless 最外围的理念是“按需”，云原生音讯 Serverless 化次要是从两个维度落地按需的概念：

• 一方面依据业务规模自动化扩缩容实例规格、队列数等逻辑资源；
• 另一方面，依据服务端负载自动化扩缩容计算、存储等物理资源。

1）逻辑资源按需扩缩容

在用户侧，更关怀的是音讯实例提供的逻辑资源是否短缺，比方购买的实例 TPS 规格是否足够，队列数量是否能满足扩展性需要。比方一个商业化的 MQ 实例中，能够依据用户的流量对实例规格进行主动的升降配，从 2W TPS 至 10W TPS 按需调整；也能够依据用户分布式消费者的数量规模，对逻辑队列数量进行动静调整；用户齐全不须要进行容量评估。

2）物理资源按需扩缩容

在云服务开发者侧，咱们更关怀的是如何通过 Serverless 升高运维老本，防止手动的机器购买、VIP 申请、磁盘申请以及集群扩缩容等。在 Kubernetes 化实现后，能够很轻易地依据集群 Load 等指标主动扩容 MQ 物理资源；在集群缩容的解决上，会比拟麻烦，因为每个 MQ 节点其实是有状态的，图中的某个 PV 代表了一个 CommitLog，咱们在外部通过在 ASI 上反对 PV 漂移，在 RocketMQ 存储层反对多 CommitLog 挂载来实现自动化缩容。

3. 云原生音讯 Mesh 化

Service Mesh 出发点是解决微服务架构的网络问题，将服务之间的通信问题从业务过程中进行剥离，让业务方更加专一于本身的业务逻辑。云原生音讯 Mesh 化将音讯的富客户端能力下沉至 Sidecar，将音讯的服务发现、负载平衡、流量监控等职责与业务逻辑隔离，在运行时实现通明组装，同时提供细粒度的音讯灰度和治理能力。

目前阿里云音讯队列 RocketMQ 是国内第二个胜利进入 Service Mesh 官网社区的中间件产品，在进行 Envoy 适配的过程中推动了 Envoy 社区减速对 on-demand CDS 的反对，创新性地应用 Pop 生产模式来适配 Mesh 的无状态网络模型。

更具体的 Mesh 化介绍参考文章：Apache RocketMQ 的 Service Mesh 开源之旅

云原生音讯生态

在云原生音讯服务演进方向大节中提到，云原生音讯服务须要大而全的音讯生态来笼罩业务方丰盛的业务场景，本大节介绍咱们在生态建设方面做的一些致力。

1. 云原生音讯产品矩阵

阿里云音讯产品矩阵蕴含音讯队列 RocketMQ、Kafka、AMQP、微音讯队列 MQTT、音讯告诉服务 MNS 以及行将公布的 EventBridge，涵盖互联网、大数据、挪动互联网、物联网等畛域的业务场景，为云原生客户提供一站式音讯解决方案。

• 音讯队列 RocketMQ：阿里巴巴自主研发及 双 11 交易外围链路音讯产品，阿里云主打品牌，次要面向业务音讯解决，打造金融级高可靠消息服务；
• 音讯队列 Kafka： 聚焦大数据生态链，100% 交融 Kafka 开源社区，大数据应用领域中不可或缺的音讯产品；
• 微音讯队列 MQTT：基于 MQTT 标准协议自研，拓展音讯产品的畛域与边界，延长到挪动互联网以及物联网，实现端与云的连贯；
• 音讯队列 AMQP：100% 兼容 AMQP 事实标准协定，全面交融 RabbitMQ 开源社区生态；
• 音讯服务 MNS：聚焦云产品生态集成 & 音讯告诉服务（HTTP Endpoint、Function Compute、事件告诉、挪动推送等）；
• 事件总线 EventBridge：作为咱们下一代的音讯产品状态，原生反对 CloudEvents 规范，提供中心化事件服务能力，减速云原生生态集成，EDA 首选。

2. 云原生音讯生态

在生态建设方面，咱们在商业化和开源两个生态都获得了不错得胜利。

在阿里云音讯商业化生态中，音讯队列产品线曾经反对 11 BU，30+ 云产品或者解决方案，有些对用户是可见的，有些是不可见的，真正做到了云原生通信基础设施的定位。

在开源方面，开源 RocketMQ 曾经实现了云原生技术栈的集成，包含 Knative 中的事件源，Prometheus 的 Exporter，K8s 的 Operator 等；也反对了微服务框架 Dubbo、SpringCloud 以及函数计算框架 OpenWhisk；同时开发了很多 Connector 作为 Sink 或者 Source 去连贯了 ELK、Flume、Flink、Hadoop 等大数据和数据分析畛域的优良开源产品。

3. 云原生音讯规范

最开始咱们就提到标准化是云原生消息中间件的进化方向之一，咱们从两个维度打磨产品的标准化建设。

1）社区规范

在音讯畛域，无论是接口还是协定，社区始终有很多事实上的“规范”，比方 Kafka 提供的 API 和协定，JMS API，CloudEvents 标准，MQTT 中的协定和模型，AMQP 的协定和模型等，阿里云音讯队列产品线对这些事实标准都提供了相应的接入形式，用户能够低成本实现迁徙上云。

2）自建规范

事实上的“规范”如果太多，其实就没有规范，开源方面始终在推动自建规范 OpenMessaging，OMS 将提供六大外围个性：多畛域、流、平台无关、规范的 Benchmark，面向云，线路层可插拔。目前，国内有很多云提供商都接入了 OMS 规范。

云原生音讯外围竞争力

作为云原生的音讯，外围竞争力在哪，特地是开源生态愈发蓬勃，用户可选的解决方案十分多，如何让用户抉择咱们云原生的音讯服务，咱们认为外围竞争力次要有这么几个。

1. 当先的音讯服务能力

阿里云的音讯服务，在多个方面都具备相对当先的服务能力。

1）接入 & 迁徙 

整个产品线撑持了多协定、多 API、多语言、多终端以及多生态的接入，做到了“0”接入老本，开源或自建用户都能够无缝上云；同时寰球音讯路由也反对跨地区的音讯同步，异构的音讯迁徙同步等。

2）多租户 

阿里云音讯服务反对命名空间隔离、规范的访问控制；反对实例限流、资源隔离、多租户的海量沉积。

3）音讯类型 

在业务音讯畛域，阿里云音讯有多年的业务积淀，音讯类型上反对：一般音讯、事务音讯、定时音讯、程序音讯、重试音讯以及死信音讯等。

4）生产 & 治理

 
在生产和治理畛域，云音讯服务反对 Pub / Sub 模式，播送 / 集群生产模式，生产过程中反对 Tag 过滤、SQL 过滤。在运维时，提供了音讯轨迹、音讯查问以及音讯回放等治理能力。

5）服务能力 

阿里云音讯的服务能力是通过多年锻炼的：

• 高可用：外围交易链路 12 年，双十一 10 年历程，在云上承诺的可用性 SLA 为 99.95%，可靠性 8 个 9；
• 高性能：双 11 音讯收发 TPS 峰值过亿，日音讯收发总量 3 万亿；领有寰球最大的业务音讯集群之一；
• 低提早：在 双 11 万亿级数据洪峰下，音讯发送 99.996% 在毫秒级响应；音讯公布均匀响应工夫不超过 3 毫秒。

2. 对立的音讯内核

阿里云音讯队列的另一外围竞争力为对立的音讯内核，整个音讯云产品簇都建设在对立的 RocketMQ 内核之上，所有的云产品提供统一的底层能力。

RocketMQ 内核次要蕴含以下几个模块：

1）富客户端 

RocketMQ 提供一个轻量级的富客户端，裸露 Push、Pull 以及 Pop 三种生产模式，同时内置了重试、熔断等高可用性能，产品簇的泛滥客户端都是通过对内核的富客户端进行二次开发的。

2）注册核心 

也就是 RocketMQ 开发者熟知的 NameServer，以简略牢靠的形式提供集群治理、元数据管理、Topic 路由和发现等性能，节点无状态，最终统一的语义确保 NameServer 具备超高的可用性。

3）计算节点 

Broker 中的计算局部蕴含一个高性能的传输层，以及一个可扩大的 RPC 框架，以反对各个产品的丰盛的业务需要。

4）存储引擎 

Broker 中的外围为存储引擎，通过多年锻炼的存储引擎蕴含几个外围特点：

• 低提早读写互斥：通过在 PageCache 层实现音讯的读写互斥，来大幅度保障写链路的低提早；
• 日志与索引拆散：整个存储层将音讯以 Append-Only 的形式集中式存储在 CommitLog 中，同时以索引派发这种可扩大的办法来反对事务、定时、查问以及百万队列等高级个性；
• 一致性多正本：提供多套一致性多正本实现来满足不同的部署场景和需要，比方 Master-Slave 架构、基于 Raft 的 Dleger 和正在自研的秒级 RTO 多正本协定；
• 多模存储：在将来存储的形式必定是多样化的，存储引擎形象来对立的存储接口，并提供了本地块设施、云存储以及盘古原生存储等实现。
• 多级存储：越来越的用户对音讯生命周期有了更高的要求，在过来，音讯作为利用开发的中间状态，往往只会被存储数天，通过 Deep Storage，将以低成本的形式大幅缩短音讯的生命周期，将音讯转化为用户的数据资产，以开掘更多的诸如音讯剖析、音讯计算需要。

3. 全方面的稳定性建设

稳定性永远是后面的 1，业务倒退和翻新是前面的 0。
—— 叔同

稳定性的重要性是显而易见的，稳定性是用户做技术和产品选型的时候考查第一因素，阿里云音讯队列在稳定性方面做了全面的建设。

阿里云音讯队列次要从以下几个维度进行稳定性建设：

1）架构开发

整个零碎是面向失败设计的，除了最外围的组件，所有的内部依赖都是弱依赖；在产品迭代阶段，建设了欠缺的 Code Review、单元测试、集成测试、性能测试以及容灾测试流程。

2）变更治理

危险往往来自于变更，咱们对变更的要求是可灰度、可监控、可回滚以及可降级的。

3）稳定性防护

限流、降级、容量评估、应急计划、大促保障、故障演练、预案演练、定期危险梳理等都是咱们的稳定性防护伎俩。

4）体系化巡检

分为黑盒巡检和白盒巡检，黑盒巡检会站在用户视角对产品性能进行全方面扫描，蕴含了 50+ 检测项；白盒巡检会自动化检测 JVM 运行时指标、内核零碎指标、集群统计指标等，并在指标异样时及时预警。

5）故障应急

咱们建设了一套残缺的故障应急流程，从监控报警 -> 故障产生 -> 疾速止血 -> 排查根因 -> 故障复盘，整个链路都是顺畅的。

云原生音讯瞻望

在音讯产品矩阵大节中提到，EventBridge 是作为咱们下一代的音讯产品状态，该产品也行将迎来公测，本章节次要介绍 EventBridge 的产品定位。

1. 音讯与事件

音讯和事件是两种不同状态的形象，也意味着满足不同的场景：

1）音讯

音讯是比事件更通用的形象，罕用于微服务调用之间的异步解耦，微服务调用之间往往须要等到服务能力不对等时才会去通过音讯对服务调用进行异步化革新；音讯的内容往往绑定了较强的业务属性，音讯的发送方对音讯解决逻辑是有明确的预期的。

2）事件

事件绝对于音讯更加具像化，代表了事件的发送、条件和状态的变动；事件源来自不同的组织和环境，所以事件总线人造须要跨组织；事件源对事件将被如何响应没有任何预期的，所以采纳事件的利用架构是更彻底的解耦，采纳事件的利用架构将更加具备可扩展性和灵活性。

2. EventBridge：中心化事件总线

EventBridge 作为咱们行将公布的新产品，其外围能力之一便是提供中心化的事件总线能力。

EventBridge 将提供云产品之间、云利用之间、云产品与云利用之间，以及它们与 SaaS 提供商之间的集成与被集成能力。

在中心化事件总线中有几个重要的概念：

• 事件源 ：事件源能够是阿里云服务，比方对象存储、ECS、数据库等，也能够是用户的应用程序或者第三方 SaaS，这些事件源将提供丰盛的业务事件、云产品运维事件、事件流等；
• 资源管理 ：EventBridge 外部将提供总线治理、规定治理以及 Schema 治理，提供全托管的事件服务；
• 事件处理 ：EventBridge 将提供事件传输、事件过滤、事件路由、事件查问、回放、重试、追踪等外围的事件处理能力；
• 事件指标 ：事件最终投递的指标服务无所不包，既能够触发一个 Serverless 的 Function，也能够投递至音讯队列其它产品，运维事件还能够通过短信、邮件以及日志服务触达运维人员。

3. EventBridge：EDA 服务框架

EventBridge 另一个外围能力是 EDA 服务框架。微服务有两种驱动形式：申请驱动和事件驱动。在申请驱动模式下，服务之间调用是同步调用，这种模式长处是提早低，然而服务之间的耦合是比拟重的，相比之下事件驱动有几个长处：

• 异步化 ：所有的调用通过事件异步化驱动，服务之间没有显示的依赖关系；
• 松耦合 ：通过事件总线解除所有服务之间的耦合关系；
• 可扩大 ：可扩大能力十分强，基于总线和事件 Schema 实现业务的扩大非常简单；
• 零革新 ：申请驱动的微服务，在遇到服务之间能力不对等时，往往须要进行基于音讯异步化革新，防止慢调用、超时等异常情况在整个分布式集群触发雪崩效应。基于事件驱动的微服务人造具备力异步、削峰等能力，所以在业务规模扩充时不会带来额定的革新老本。

上图是构想的一个采纳 EDA 的利用架构图：

• 基于 EventBridge 能够实际风行的 CQRS 和 Event Souring 范式；
• 能够从 IoT 端设施上接入 Event Streaming；
• 基于事件驱动的微服务程序也能够通过 API 网关裸露传统的 Request 申请形式，供前端拜访；
• EventBridge 还能够连贯第三方 SaaS 提供商，云提供商，不同组织的观察者，与分布式的事件微服务集成；
• 事件驱动和申请驱动是相辅相成的关系，通过对立 Event APIs 和 REST APIs 买通事件驱动的微服务与申请驱动的微服务，来进行架构上的交融与对立。

4. EDA 成熟度模型

咱们通过 Gartner 报告总结的 EDA 成熟度模型，瞻望以下 EDA 架构的将来：

• Incidental：偶发性地应用事件告诉机制来进行一些状态的捕捉，没有明确的事件处理策略；
• Brokered：提供托管的事件代理服务，组织中局部利用开始采纳基于音讯或者事件的异步化架构；
• Centralized：以策略的模式提出中心化的 EDA 解决方案，有专门的组织团队提供 EDA 实现，EDA 架构开始宽泛被采纳；
• Advanced：EDA 架构开始触达更多的业务畛域，比方流计算，数据分析，AI，以及 API 市场等，跨组织的事件生态开始造成并进行扩张；
• Pervasive：事件变得无处不在，宏大的事件生态造成，组织间的隔离被事件彻底买通，企业的要害业务都将采取 EDA 架构；事件驱动与申请驱动两个生态实现交融。

阿里云音讯团队在 EDA 畛域的摸索目前是处于第三个阶段，将来还有很长的路要走。