本文作者：金吉祥， Apache RocketMQ PMC Member，阿里云智能高级技能专家
布景
首要，让咱们来看下是遇到了哪些痛点问题，促进咱们去探究一种无状况署理的RocketMQ新架构的；
RocketMQ 具有一套极简的架构，多语言客户端经过自定义的 Remoting 协议与后端 NameServer 和 Broker树立 TCP 长衔接，然后进行音讯的路由发现以及完好的音讯收发。这套架构的优势是：架构极简，客户端 与 Broker 经过 TCP 直连的形式，具有较高的功用以及较低的推迟。一起，这套架构采取的是行列模型，十分适合依据行列批量高速拉取音讯的场景。
一起，RocketMQ 在上云进程中面临了各式各样的应战。
首要，云上用户需求更为丰厚的事务语义音讯，包括事务、守时、次序以及死信等。为了满意用户的事务侧需求，需求在原先架构的客户端侧和 Broker侧分别进行开发，用户有必要晋级客户端之后才能享用新功用。
其次，上云进程需求面对更为杂乱的网络环境，不同场景下需求不同类型网络的接入。有些用户为了快捷性，希望能够交给公网的接入点，让不同地域的顾客、发送者都能衔接到同一个音讯服务；而另一种用户为了安全性，需求内网接入点来阻隔一些非法的网络恳求；RocketMQ原先的架构在应对多网络类型的接入诉求时，本钱是比较高的，多网络类型的接入有必要一起掩盖NameServer和Broker的每一台机器才行。比方咱们需求对内部 Broker进行扩容场景下，假如原先的 Broker 具有多种类型的网络接入诉求，那么新扩容的 Broker也需求额外绑定上多种类型的网络接入点之后才能正常对外交给。
做下总结，面对上云的应战，此前的架构逐步露出出了如下许多痛点：
① 富客户端形状：客户端包括了大量企业级特性。用户有必要晋级客户端才能享用新功用，进程十分漫长。且相同的功用交给有必要在多个多语言版本里都进行适配才能满意多语言客户端的接入，工作量巨大。
② 客户端与Broker一切节点的直连形式满意多类型网络接入的本钱较高。
③ 依照行列进行负载均衡和音讯拉取，后端扩缩容时会触发客户端rebalance，导致音讯推迟或重复消费，顾客会有显着的感知；此外， 依据行列的模型十分简单导致一个用户饱尝困扰的问题：单个故障顾客消费卡住会导致音讯在服务端大量堆积。
RocketMQ5.0无状况署理形式
为了处理上述痛点，RocketMQ 5.0 提出了无状况署理形式。
新架构在原先的客户端和Broker中间插入了署理层。战略上是将客户端的无状况功用尽或许下移到署理层，一起也将 Broker侧的无状况功用尽或许上移到署理层。在这儿，咱们将客户端的原有的负载均衡机制、故障阻隔、push/pop消费模型下移到了署理层，将 Broker 的拜访操控、多协议适配、客户端管理以及NameServer 的音讯路由才能上移到了署理层，终究打造出的署理层的丰厚才能，包括拜访操控、多协议适配、通用事务才能、管理才能以及可观测性等。
在构建署理层的进程中，咱们有必要坚持的一个原则便是：客户端和 Broker 往署理层迁移的才能有必要是无状况的，这样才能确保后续署理层是能够随着承接的流量巨细进行动态扩缩容的。
在引入无状况署理层后，RocketMQ原先客户端、Broker的直连架构就演变为上图的无状况署理形式架构：
从流量上看，署理层承接了客户端侧一切流量， Broker 和 NameServer 不再直接对用户露出，用户仅有能看到的组件只要署理层（Proxy）。
这儿，Proxy的职责包括以下几个方面：
-
多协议适配: Proxy具有解析和适配不同协议的才能，包括 remoting 、gRPC、HTTP 以及后续或许衍生出来的MQTT和AMQP等协议。Proxy对不同协议进行适配、解析，终究一致翻译成与后端 Broker 和 NameServer 之间的 remoting协议。
-
流量管理和流量分发: Proxy承接了客户端侧一切流量，因而能够很轻松地依据某些规则识别出当前流量的特性，然后依据一定的规则将流量分发到后端不同的 Broker集群，乃至进行精准的流量操控、限流等。
-
功用扩展：包括拜访操控比方允许哪个用户拜访后端Broker集群中的哪个 Topic、音讯轨道的一致收集以及整体的可观测性等。
-
Proxy能扮演NameServer，交给给客户端查询TopicRoute的才能。
-
Proxy能够无缝兼容用户侧的Pop或者Push消费形式：在Proxy和Broker侧选用Pop消费形式来防止单个行列被锁导致音讯在服务端堆积的历史遗留问题。
一起，咱们也能够看到Proxy具有以下两大特性：
①无状况，可依据用户以及客户端的流量进行水平扩缩容。
②计算型，比较耗费CPU，因而在布置时需求尽或许给Proxy分配多些CPU。
做下总结，无状况署理形式处理了原先架构的多个痛点：
① 将客户端大量事务逻辑下移到署理层，打造出轻量客户端。一起，依托于 gRPC协议的标准化以及传输层代码自动生成的才能，能够快速适配多种语言的客户端。
② 客户端只会与Proxy层衔接，针对多网络类型接入的诉求，能够将多网络类型绑定到Proxy层，由于Broker 和 NameServer不再直接对客户端露出，转而只需对 Proxy露出内网的衔接即可，多网络类型接入的诉求能够只在Proxy这个组件就关闭掉；一起，Proxy的无状况的特性确保了多类型网络接入是与集群规划无关的。
③ 消费形式进行了无感知切换，不管客户端侧挑选的是Pop还是Push消费形式，终究一致替换为Proxy与Broker侧的Pop消费形式，防止单个客户端消费卡住导致服务端音讯堆积的历史问题。
RocketMQ无状况署理形式技能详解
新架构在客户端和 Broker 之间引入了署理层，客户端一切流量都需求多一跳网络、多经历一次序列化/反序列化的进程，这对端到端音讯推迟灵敏的用户是极其不友好的，因而咱们规划了兼并布置形状。
兼并布置形状下，Proxy和 Broker 依照1：1的方法对等布置，且 Proxy和 Broker 完成进程内通讯，满意低推迟、高吞吐的诉求。一起，Proxy仍然具有多协议适配的才能，客户端会与一切 Proxy树立衔接进行音讯收发确保能够消费到一切音讯。
代码完成上，咱们经过构造器来完成兼并布置和别离布置的两种形状。用户可自行挑选布置形状。假如用户挑选兼并布置的形状，则在构建 Proxy处理器之前，会先构造 BrokerController，并向 Proxy的处理器注册,本质上是为了奉告Proxy处理器：后续的恳求往我这个BrokeController 发；假如用户挑选别离布置形式，则无须构建BrokerController，直接启动Proxy处理器即可。
关于这两种布置形式的比较，首要，兼并布置和别离布置一起具有了多协议的适配才能，都能够解析用户侧和客户端侧的多协议恳求；且具有模型抽象，能够处理富客户端带来的一系列痛点。
布置架构上，兼并布置是一体化的架构，易于运维；别离布置是分层的架构，Proxy组件独立布置，Proxy和 broker按事务水位分别进行扩缩。
功用上，兼并布置架构少一跳网络和一次序列化，有较低的推迟和较高的吞吐；别离布置多一跳网络和一次序列化，开支和推迟有所增加。推迟详细增加多少主要依赖于 Proxy和 Broker 之间的网络推迟。
资源调度上，兼并布置状况下比较简单获得稳定的本钱模型，由于组件单一；别离布置形状下Proxy是 CPU 密集型，Broker和NameServer 也逐步退化成存储和 IO 密集型，需求分配比较多的内存和磁盘空间，因而需求进行细粒度的分配和资源规划，才能让别离布置形状资源的利用率到达最大化。
多网络类型接入本钱上，兼并布置本钱较高，客户端需求与每一个 Proxy副本都测验树立衔接，然后进行音讯收发。因而，多网络接入类型场景下，Proxy进行扩缩容时需求为每台Proxy绑定不同类型的网络；别离布置形式本钱较低，仅需求在独立布置的 Proxy层测验绑定多网络类型的接入点即可，一起是多台Proxy绑定到同一个类型的网络接入点即可。
针对事务上的选型主张：
假如对端到端的推迟比较灵敏，或希望运用较少的人力去运维很大集群规划的RocketMQ布置，或只需求在单一的网络环境中运用RocketMQ的，比方只需内网拜访，则主张选用兼并布置的形式。
假如有多网络类型接入的诉求比方一起需求内网和公网的拜访才能或想要对RocketMQ进行个性化定制，则主张选用别离布置的形式，能够将多网络类型的接入点关闭在 Proxy层，将个性化定制的改造点也关闭在Proxy层。
社区新推出的PopConsumer消费形式和原先的PushConsumer 消费形式存在较大区别。PushConsumer 是依据行列模型的消费形式，但存在一些遗留问题。比方单个 PushConsumer 消费卡住会导致服务端侧音讯堆积。新推出的Pop消费形式是依据音讯的消费模型，PopConsumer 会测验和一切 broker 衔接并消费音讯，即便有一个PopConsumer消费卡住，其他正常的PopConsumer依然能从一切 broker里拉取到音讯进行消费，不会出现音讯堆积。
从Proxy署理层视点看，它能够无缝适配 PushConsumer 和 PopConsumer，终究将两种消费形式都映射到 Pop 消费形式，与后端 Broker 树立消费衔接。详细来看，PushConsumer 里的pull恳求会被转成PopConsumer 消费形式里的 pop 恳求，提交位点的 UpdateConsumeOffset 恳求会被转换成音讯等级的 ACK 恳求，SendMessageBack会被转换成修改音讯的不可见时间的恳求，以到达从头被消费的意图。
Proxy最上层为协议的适配层，经过不同的端口对客户端露出服务，不同协议经过不同端口恳求到Proxy之后，协议适配层会进行适配，经过通用的 MessagingProcessor 模块，将send、pop、ack、ChangeInvisibleTime等恳求转换成后端 Remoting 协议的恳求，与后端的 Broker 和NameServer树立衔接，进行音讯收发。
多协适配的优势有以下几个方面：
① 加快了RocketMQ的云原生化，比方更简单与Service Mesh相结合。
② 依据 gRPC 的标准性、兼容性及多协议多语言传输层代码的生成才能，打造RocketMQ的多语言瘦客户端，能够充分利用gRPC插件化的衔接多路复用、序列化/反序列化的才能，让RocketMQ客户端更加轻量化，将更多精力聚集在音讯领域的事务逻辑。
做下技能计划的总结：
无状况署理形式经过客户端下移、Broker侧上移无状况的才能到署理层，将拜访操控、客户端管理、流量管理等事务收敛到署理层，既能够满意快速迭代的诉求，又能对变更进行收敛，更好保证整个架构的稳定性：有了分层架构之后，更多事务逻辑的开发会聚集在 Proxy层,下一层的 Broker和 NameServer 趋于稳定，能够更多地重视存储的特性。Proxy的发布频率远远高于底层 Broker 的发布频率，因而问题收敛之后，稳定性也得到了确保。
多协议适配，依据gRPC的标准性、兼容性以及多语言传输层代码生成的才能打造RocketMQ的多语言瘦客户端。
Push 到 Pop 消费形式的无感知切换，将消费位点的维护收敛到 Broker， 处理了单一顾客卡住导致音讯堆积的历史遗留问题。
别的，咱们也测验探究了可分可合的布置形状，确保同一套代码可分可合，满意不同场景下对功用布置本钱、易运维性的差异化诉求。在大部分的场景下，依然主张挑选兼并布置的形状。假如有对多网络类型接入的诉求，或对RocketMQ 有极强的定制化诉求，则主张挑选别离布置的形状，以到达更好的可扩展性。
署理层无状况的特性，极大降低了适配多类型网络接入诉求的本钱。
未来规划
未来，咱们希望RocketMQ底层的Broker和NameServer 更多聚集在存储的特性上，比方事务型音讯存储的事务、守时、次序等，快速构建音讯索引、打造一致性多副本提高音讯可靠性、多级存储来到达更大的存储空间等。
其次，对无状况署理层依照可插拔的特性开发，比方对拜访操控、抽象模型、协议适配、通用事务才能、管理才能等按模块进行区分，使语义更丰厚，可依照不同场景的诉求可插拔地布置各种组件。
最后，咱们希望这一套架构能够支持阿里云上的多产品形状，致力于打造云原生音讯十分丰厚的产品矩阵。
加入 Apache RocketMQ 社区
十年铸剑，Apache RocketMQ 的生长离不开全球挨近 500 位开发者的积极参与奉献，相信在下个版本你便是 Apache RocketMQ 的奉献者，在社区不只能够结识社区大牛，提高技能水平，也能够提高个人影响力，促进本身生长。
社区 5.0 版本正在进行着如火如荼的开发，别的还有挨近 30 个 SIG（兴趣小组）等你加入，欢迎立志打造世界级分布式系统的同学加入社区，增加社区开发者微信：rocketmq666 即可进群，参与奉献，打造下一代音讯、事情、流交融处理平台。
微信扫码增加小火箭进群
别的还能够加入钉钉群与 RocketMQ 爱好者一起广泛评论：
钉钉扫码加群
重视「Apache RocketMQ」公众号，获取更多技能干货
