Apache RocketMQ 的 Service Mesh 开源之旅

Apache RocketMQ 的 Service Mesh 开源之旅

作者 | 凌楚   阿里巴巴开发工程师

导读：自 19 年末开端，支撑 Apache RocketMQ 的 Network Filter 历时 4 个月的 Code Review（Pull Request），于本月正式合入 CNCF Envoy 官方社区（RocketMQ Proxy Filter 官方文档），这使得 RocketMQ 成为继 Dubbo 之后，国内第二个成功进入 Service Mesh 官方社区的中间件产品。

Service Mesh 下的音讯收发
首要流程如下图：

 图 1

简述一下 Service Mesh 下 RocketMQ 音讯的发送与消费进程：

Pilot 获取到 Topic 的路由信息并经过 xDS 的方法下发给数据平面/Envoy ，Envoy 会署理 SDK 向 Broker/Nameserver 发送的一切的网络恳求；
发送时，Envoy 经过 request code 判别出恳求为发送，并依据 topic 和 request code 选出对应的 CDS，然后经过 Envoy 供给的负载均衡战略选出对应的 Broker 并发送，这儿会运用数据平面的 subset 机制来确保选出的 Broker 是可写的；
消费时，Envoy 经过 request code 判别出恳求为消费，并依据 topic 和 request code 选出对应的 CDS，然后和发送相同选出对应的 Broker 进行消费（与发送相似，这儿也会运用 subset 来确保选出的 Broker 是可读的），并记载相应的元数据，当音讯消费 SDK 宣布 ACK 恳求时会取出相应的元数据信息进行比对，再经过路由来精确将 ACK 恳求发往前次消费时所运用的 Broker。
RocketMQ Mesh 化所遭受的难题
Service Mesh 常常被称为下一代微服务，这一方面提醒了在前期 Mesh 化浪潮中微服务是肯定的主力军，另一方面，微服务的 Mesh 化也相对愈加便当，而跟着音讯行列和一些数据库产品也逐步走向 Service Mesh，各个产品在这个进程中也会有各自的问题亟需处理，RocketMQ 也没有破例。

有状况的网络模型
RocketMQ 的网络模型比 RPC 愈加杂乱，是一套有状况的网络交互，这首要体现在两点：

RocketMQ 现在的网络调用高度依靠于有状况的 IP；
原生 SDK 中消费时的负载均衡使得每个顾客的状况不可以被疏忽。
关于前者，使得现有的 SDK 彻底无法运用分区次序音讯，因为发送恳求和消费恳求 RPC 的内容中并不包括 IP/(BrokerName + BrokerId) 等信息，导致运用了 Mesh 之后的 SDK 不能确保发送和消费的 Queue 在同一台 Broker 上，即 Broker 信息本身在 Mesh 化的进程中被抹除了。当然这一点，关于只要一台 Broker 的大局次序音讯而言是不存在的，因为数据平面在负载均衡的时分并没有其他 Broker 的挑选，因而在路由层面上，大局次序音讯是不存在问题的。

关于后者，RocketMQ 的 Pull/Push Consumer 中 Queue 是负载均衡的基本单位，原生的 Consumer 中其实是要感知与自己处于同一 ConsumerGroup 下消费同一 Topic 的 Consumer 数目的，每个 Consumer 依据自己的方位来挑选相应的 Queue 来进行消费，这些 Queue 在一个 Topic-ConsumerGroup 映射下是被每个 Consumer 独占的，而这一点在现有的数据平面是很难完成的，并且，现有数据平面的负载均衡无法做到 Queue 粒度，这使得 RocketMQ 中的负载均衡战略现已不再适用于 Service Mesh 系统下。

此刻咱们将目光投向了 RocketMQ 为支撑 HTTP 而开发的 Pop 消费接口，在 Pop 接口下，每个 Queue 可以不再是被其时 Topic-ConsumerGroup 的 Consumer 独占的，不同的顾客可以一起消费一个 Queue 里的数据，这为咱们运用 Envoy 中原生的负载均衡战略供给了或许。

 图 2

图 2 右侧即为 Service Mesh 中 Pop Consumer 的消费状况，在 Envoy 中咱们会疏忽掉 SDK 传来的 Queue 信息。

弹内海量的 Topic 路由信息
在集团内部，Nameserver 中保存着上 GB 的 Topic 路由信息，在 Mesh 中，咱们将这部分笼统成 CDS，这使得关于无法预先知道运用所运用的 Topic 的景象而言，操控平面只能全量推送 CDS，这无疑会给操控平面带来巨大的稳定性压力。

在 Envoy 更前期，是彻底的全量推送，在数据平面刚启动时，操控平面会下发全量的 xDS 信息，之后操控平面则可以自动操控数据的下发频率，可是无疑下发的数据依旧是全量的。后续 Envoy 支撑了部分的 delta xDS API，即可以下发增量的 xDS 数据给数据平面，这当然使得关于已有的 sidecar，新下发的数据量大大下降，可是 sidecar 中具有的 xDS 数据依然是全量的，对应到 RocketMQ ，即全量的 CDS 信息都放在内存中，这是咱们不行承受的。所以咱们期望可以有 on-demand CDS 的方法使得 sidecar 可以只是获取自己想要的 CDS 。而此刻正好 Envoy 支撑了 delta CDS，并仅支撑了这一种 delta xDS。其实此刻具有 delta CDS 的 xDS 协议本身现已供给了 on-demand CDS 的才干，可是无论是操控平面仍是数据平面并没有露出这种才干，所以在这儿对 Envoy 进行了修正并露出了相关接口使得数据平面可以自意向操控平面主张对指定 CDS 的恳求，并根据 delta gRPC 的方法完成了一个简略的操控平面。Envoy 会自动主张对指定 CDS 资源的恳求，并供给了相应的回调接口供资源回来时进行调用。

关于 on-demand CDS 的叙说对应到 RocketMQ 的流程中是这样的，当 GetTopicRoute 或许 SendMessage 的恳求抵达 Envoy 时，Envoy 会 hang 住这个流程并主张向操控平面中相应 CDS 资源的恳求并直到资源回来后重启这个流程。

关于 on-demand CDS 的修正，之前还向社区主张了 Pull Request ，现在看来其时的主意仍是太不成熟了。原因是咱们这样的做法彻底疏忽了 RDS 的存在，而将 CDS 和 Topic 完成了强绑定，乃至称号也一模相同，关于这一点，社区的 Senior Maintainer @htuch 对咱们的主意进行了辩驳，粗心便是实际上的 CDS 资源名或许带上了负载均衡方法，inbound/outbound 等各种 prefix 和 suffix，不能直接等同于 Topic 名，更重要的是社区赋予 CDS 本身的界说是脱离于事务的，而咱们这样的做法过于 tricky ，是与社区的初衷各走各路的。

因而咱们就需求加上 RDS 来进行笼统，RDS 经过 topic 和其他信息来定位到详细所需求的 CDS 名，因为作为数据平面，无法预先在代码层面就知道所需求找的 CDS 名，那么如此一来，经过 CDS 名来做 on-demand CDS 就更无从谈起了，因而从这一点动身只能承受全量计划，不过好在这并不会影响代码奉献给社区。

route_config:
name: default_route
routes:

• match:

    topic:

  exact: mesh

    headers:

  • name: code
    exact_match: 105

    route:
    cluster: foo-v145-acme-tau-beta-lambda

    上面可以看到关于 topic 名为 mesh 的恳求会被 RDS 路由到 foo-v145-acme-tau-beta-lambda 这个 CDS 上，事前咱们只知道 topic 名，无法知道被匹配到的 CDS 资源名。

现在站在更高的视角，发现这个过错很简略，可是其实这个问题咱们直到后续 code review 时才及时纠正，的确可以更早就做得更好。

不过从现在社区的动态来看，on-demand xDS 或许现已是一个 roadmap，最少现在 xDS 现已全系支撑 delta ，VHDS 更是首度支撑了 on-demand 的特性。

Mesh 为 RocketMQ 带来了什么？
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

这是 Service Mesh 这个词的创造者 William Morgan 对其做出的界说，归纳一下：作为网络署理，并对用户通明，承当作为基础设施的责任。

 图 3

这儿的责任在 RocketMQ 中包括服务发现、负载均衡、流量监控等责任，使得调用方和被署理方的责任大大下降了。

当然现在的 RocketMQ Filter 为了确保兼容性做出了许多退让，比方为了确保 SDK 可以成功获取到路由，将路由信息聚合包装成了 TopicRouteData 回来给了 SDK ，可是在抱负状况下，SDK 本身现已不需求关怀路由了，纯为 Mesh 情形规划的 SDK 是愈加精简的，不再会有消费侧 Rebalance，发送和消费的服务发现，乃至在未来像音讯体紧缩和 schema 校验这些功用 SDK 和 Broker 或许都可以不必再关怀，来了就发送/消费，发送/消费完就走或许才是 RocketMQ Mesh 的终极形状。

 图 4

What's Next ?
现在 RocketMQ Filter 具有了一般音讯的发送和 Pop 消费才干，可是假如想要具有愈加完好的产品形状，功用上还有一些需求弥补：

支撑 Pull 恳求：现在 Envoy Proxy 只接纳 Pop 类型的消费恳求，之后会考虑支撑一般的 Pull 类型，Envoy 会将 Pull 恳求转换成 Pop 恳求，然后做到让用户无感知；
支撑大局次序音讯：现在在 Mesh 系统下，尽管大局次序音讯的路由不存在问题，可是假如多个 Consumer 一起消费大局次序音讯，其间一个顾客忽然下线导致音讯没有 ACK 而会导致另一个顾客的音讯发生乱序，这一点需求在 Envoy 中进行确保；
Broker 侧的 Proxy：对 Broker 侧的恳求也进行署理和调度。
弯曲弯曲的社区进程
起先，RocketMQ Filter 的初度 Pull Request 就包括了其时简直悉数的功用，导致了一个超越 8K 行的超大 PR，感谢@天千 在 Code Review 中所做的作业，十分专业，协助了咱们更快地合入社区。

别的，Envoy 社区的 CI 实在太严厉了，严厉要求 97% 以上的单测行覆盖率，Bazel 源码级依靠，纯静态链接，本身无 cache 编译 24 逻辑中心 CPU 和 load 均打满至少半个小时才干编完，社区的各种 CI 跑完一次则少说两三个小时，多则六七个小时，并对新提交的代码有着极端苛刻的语法和 format 要求，这使得在 PR 中修正一小部分代码就或许带来很多的单测变化和 format 需求，不过好的是单测可以很方便地协助咱们发现一些内存 case 。客观上来说，官方社区以这么高的规范来要求 contributors 的确可以很大程度上操控住代码质量，咱们在补全单测的进程中，仍是发现并处理了不少本身的问题，总得来说仍是有必定必要的，究竟关于 C++ 代码而言，一旦出产环境出问题，调试和追寻起来会困难得多。

最终，RocketMQ Filter 的代码由我和@叔田 共同完成，关于一个没什么开源阅历的我来说，为这样的抢手社区奉献代码是一次十分名贵的阅历，一起也感谢叔田在此进程中给予的协助和主张。

相关链接
Official docs for RocketMQ filter
Pull request of RocketMQ filter
RocketMQ filter's issue
On-demand CDS pull request for Envoy
First version of RocketMQ filter's proposal
阿里巴巴云原生中间件团队招人啦
这儿有满意多的事务场景、满意大的音讯生态、满意深的分布式技能等着咱们前来探究，假如你满意：

至少通晓一种编程言语，Java 或 C++；
深化了解分布式存储理论，微服务优化实践；
核算机理论基础厚实，例如对操作系统原理、TCP/IP 等有比较深化的了解；
具有独立规划一款出产环境高可用高牢靠的中间件才干，例如 RocketMQ；
了解高并发、分布式通讯、存储、开源中间件软件等相关技能者更佳。
欢迎参加并参加新一代云原生中间件建造！简历提交地址：yangkun.ayk@alibaba-inc.com。

课程引荐
为了更多开发者可以享受到 Serverless 带来的盈利，这一次，咱们集结了 10+ 位阿里巴巴 Serverless 范畴技能专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云核算的新范式——Serverless。

点击即可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless

原文地址https://my.oschina.net/u/3874284/blog/4279489