关于后端:基于消息队列-RocketMQ-的大型分布式应用上云最佳实践

简介：Apache RocketMQ 作为阿里巴巴开源的撑持万亿级数据洪峰的分布式消息中间件，在泛滥行业广泛应用。在选型过程中，开发者肯定会关注开源版与商业版的业务价值比照。那么，明天就围绕着商业版本的音讯队列 RocketMQ 和开源版本 RocketMQ 进行比拟，并联合实际中场景全面展现大型分布式应用的上云最佳实际。

作者|绍舒

音讯队列是分布式互联网架构的重要基础设施，在以下场景都有着重要的利用：

利用解耦
削峰填谷
异步告诉
分布式事务
大数据处理

并波及互动直播、挪动互联网 & 物联网，IM 实时通信、Cache 同步、日志监控等多个畛域。

而本文次要围绕着商业版本的音讯队列 RocketMQ，和开源版本 RocketMQ 进行比拟，并联合一些实际中的场景来展现大型分布式应用的上云最佳实际。

商业版本音讯队列 RocketMQ 相比拟开源版本 RocketMQ 和其余竞品，次要有以下几点劣势。

开箱即用、功能丰富
高性能、有限扩大能力
可观测、免运维能力
高 SLA 和稳定性保障

音讯队列 RocketMQ 提供了定时、事务、程序等多类型音讯的反对，且反对播送、集群两种生产模式；另外在协定层面，提供 TCP/HTTP 多协定反对，还提供了 TAG/SQL 属性过滤性能，极大水平地拓宽了用户的应用场景。

音讯队列 RocketMQ 禁受了阿里外围电商历年双十一洪峰的考验，反对千万级 TPS 音讯收发和亿级音讯沉积的能力，并且可能为音讯提供毫秒级端到端提早保障，另外还提供分级存储，反对海量音讯的任意保留工夫。

音讯队列 RocketMQ 提供了一个可观测性大盘，反对细粒度数据大盘，提供了音讯全链路生命周期追踪和查问能力，对各个指标提供了相应的监控报警性能；此外，还提供了音讯回溯和死信队列性能，可能保障用户的音讯可能随时回溯生产。

音讯队列 RocketMQ 的稳定性是咱们一贯、继续、稳固投入的重要畛域，提供了高可用部署和多正本写入性能；另外也反对同城多 AZ 容灾和异地多活。

接下来，咱们会从以上的产品外围能力中筛选几个剖面，并且联合具体的场景和实际来做进一步的介绍。

高可用程序音讯

商业版本音讯队列 RocketMQ 应用的程序音讯咱们称之为高可用程序音讯。在介绍高可用程序音讯之前，首先简要介绍下开源版本 RocketMQ 的程序音讯。

程序音讯分为两种类型，全局程序音讯和分区程序音讯。

全局程序音讯：在 RocketMQ 存储层只会调配一个分区，也就是说全局程序 Topic 的可用性跟繁多正本的可用性强相干，且不具备可扩大的能力。
分区程序音讯：所有音讯依据 Sharding Key 进行分区。同一个分区内的音讯依照严格的 FIFO 程序进行公布和生产。Sharding Key 是程序音讯中用来辨别不同分区的关键字段。

下图是分区程序音讯的利用场景，order ID 即为此时程序音讯的 Sharding Key。

能够看到，无论是全局程序音讯还是分区程序音讯，都依赖了繁多分区人造的 FIFO 个性来保障程序，因而程序性也只能在同一个分区内保障，当此分区所在的正本不可用时，程序音讯并不具备重试到其余正本的能力，此时音讯的程序性就难以失去保障。

为了解决这一问题，咱们设计并实现了高可用程序音讯。

高可用程序音讯有以下几个特点：

一个逻辑程序分区（PartitionGroup）下有多个物理分区。
其中任意一个物理分区是可写的，那么整个逻辑分区是可写且有序的。
咱们基于 happened-before 的准则设计了一套基于分区位点的排序算法。
依据该算法，消费者在生产某一逻辑分区时，会从其所属的各个物理分区中拉取音讯并进行合并排序，得出正确的音讯程序流。

通过这样的设计，高可用程序音讯解决了下列几点问题：

可用性问题：高可用程序音讯将具备与一般音讯统一的可用性，在某正本不可用时，可疾速重试至其它正本。
可扩展性问题：一般程序音讯，特地是一般全局程序音讯，不具备良好的扩大能力，只能固定在特定的正本中。高可用程序音讯的逻辑程序分区能够将物理程序分区扩散在多个正本中。
热点问题：一般程序音讯依据 Key 将一类音讯 Hash 至同一个分区中，热点 Key 会导致热点分区，高可用程序音讯具备横向扩大能力，能够为逻辑程序分区增加多个物理分区来打消热点问题。
单点问题：一般全局程序音讯，仅蕴含单分区，极易呈现单点故障，高可用程序音讯能够打消全局程序音讯的单点问题。

尤其须要留神的是热点问题，在阿里巴巴外部某电商业务大促时，因发送到程序 Topic 的某一特定的 ShardingKey 数量过多，集群中一个正本接管到了大量该 ShardingKey 的音讯，导致该正本超出其负荷下限，造成了音讯的提早和沉积，肯定水平上影响了业务。在应用了高可用程序音讯之后，因为其在多物理分区中的负载平衡个性，晋升了集群程序音讯的承载能力，从而防止了热点问题的呈现。

定时音讯，是指客户端以后发送但心愿在将来的某个工夫内收到的音讯。定时音讯广泛应用于各类调度零碎或者业务零碎之中。比方领取订单，产生一个领取音讯，零碎通常须要在肯定工夫后处理该音讯，判断用户是否领取胜利，而后零碎做相应解决。

开源版本的 RocketMQ 只反对几个指定的提早级别，并不反对秒级精度的定时音讯。而面向团体内和云上多样化的需要，开源版本的定时音讯并不能满足咱们的需要，因而咱们推出了秒级精准定时音讯。image.gif

如下图所示，咱们基于工夫轮设计并实现了反对任意定时工夫的秒级精准定时音讯，同时满足以下个性：

任意定时工夫
超长定时工夫
海量定时音讯
删除定时音讯
高可用
高性能

外部某用户有这样的场景，冀望在将来的某一分钟的 30s 时刻解决这样一个定时申请，开源版本的定时音讯并不合乎其须要，而秒级精准定时音讯在保障高可用、高性能的同时，满足了其业务需要。

如下图所示，在传统的事务处理中，多个零碎之间的交互耦合到一个事务中，造成整体的相应工夫长，回滚过程简单，从而潜在影响了零碎的可用性；而 RocketMQ 提供的分布式事务性能，在保障了零碎松耦合和数据最终一致性的前提下，实现了分布式事务。

音讯队列 RocketMQ 提供的事务音讯解决步骤如下：

发送方将半事务音讯发送至音讯队列 RocketMQ 版服务端。
音讯队列 RocketMQ 版服务端将音讯长久化胜利之后，向发送方返回 Ack 确认音讯曾经发送胜利，此时音讯为半事务音讯。
发送方开始执行本地事务逻辑。
发送方依据本地事务执行后果向服务端提交二次确认（Commit 或是 Rollback），服务端收到 Commit 状态则将半事务音讯标记为可投递，订阅方最终将收到该音讯；服务端收到 Rollback 状态则删除半事务音讯，订阅方将不会承受该音讯。

基于这样的实现，咱们通过音讯实现了分布式事务个性，即本地事务的执行后果会最终反馈到订阅方是否能接管到该条音讯。

音讯队列 RocketMQ 的分布式事务音讯宽泛地利用于阿里巴巴外围交易链路中，通过分布式事务音讯，实现了最小事务单元；交易系统和音讯队列之间，组成一个事务处理；上游零碎（购物车、积分、其它）互相隔离，并行处理。

背景

随着云上客户的一直增多，存储逐步成为 RocketMQ 运维的重要瓶颈，这包含并且不限于：

内存大小无限，服务端不能将所有用户的数据全副缓存在内存中；在多租户场景下，当有用户拉取冷数据时，会对磁盘造成较大 IO 压力，从而影响共享集群的其余用户，亟需做到数据的冷热拆散。
云上有单租户定制化音讯存储时长的需要。而 RocketMQ Broker 中所有用户的音讯是放在一个间断文件中进行存储的，无奈针对任何繁多用户定制存储时长，即现有的存储构造无奈满足这样的需要。
如果能对海量数据提供更低成本的存储形式，能够大幅升高云上 RocketMQ 的磁盘存储老本。

基于以上现状，分级存储计划应运而生。

架构

分级存储的整体架构如下：

connector 节点负责将 broker 上的音讯实时同步到 OSS 上
historyNode 节点将用户对冷数据的拉取申请转发至 OSS 上
在 OSS 中是依照 Queue 粒度来组织文件构造的，即每个 Queue 会由独立的文件进行存储，从而保障了咱们能够针对于租户定义音讯的存储时长。

通过这样的设计，咱们实现了音讯数据的冷热拆散。

应用场景

基于分级存储，咱们进一步拓展了用户的应用场景：

自定义存储工夫：在音讯数据的冷热拆散之后，咱们将冷数据存储到 OSS 这样的存储系统中，可能实现用户自定义的存储工夫。
音讯审计：在音讯的存储之间从数天扩大到自定义后，音讯的属性从一个临时性的直达数据变成了用户的数据资产，而音讯零碎也从数据中枢转变成了数据仓库；用户可能基于数据仓库实现更多样的审计、剖析、解决性能。
音讯回放：在流计算场景中，音讯回放是十分重要的一个场景；通过拓展音讯的存储工夫之后，流计算可能实现更加丰盛的计算剖析场景。

稳定性

音讯队列 RocketMQ 的稳定性是咱们一贯、继续、稳固投入的重要畛域。在介绍咱们在稳定性的最新工作之前，首先带大家回顾下 RocketMQ 高可用架构的演进路线。

高可用架构演进路线

2012 年，RocketMQ 作为阿里巴巴全新一代的音讯引擎问世，并随后开源至社区，第一代 RocketMQ 高可用架构也随之诞生。如下图所示，第一代高可用架构采取过后风行的 Master-Slave 主从架构，写流量通过 Master 节点同步至 Slave 节点，读流量也通过 Master 节点并将生产记录同步至 Slave 节点。当 Master 节点不可用时，整个正本组可读不可写。

2016 年，RocketMQ 云产品正式开始商业化，云时代单点故障频发，云产品须要齐全面向失败而设计，因而 RocketMQ 推出了第二代多正本架构，依靠于 Zookeeper 的分布式锁和告诉机制，引入 Controller 组件负责 Broker 状态的监控以及主备状态机转换，在主不可用时，备主动切换为主。第二代架构是音讯云产品规模化过程中的外围高可用架构，为云产品规模化立下了汗马功劳。

2018 年，RocketMQ 社区对 Paxos 和 Raft 引入分布式协定有极大的激情，RocketMQ 研发团队在开源社区推出了基于 Raft 协定的 Dledger 存储引擎，原生反对 Raft 多正本。

RocketMQ 高可用架构曾经走过了三代，在团体、私有云和专有云多样场景的实际中，咱们发现这三套高可用架构都存在一些弊病：

第一代主备架构只起到了冷备的作用，且主备切换须要人工染指，在大规模场景下有较大的资源节约以及运维老本。
第二代架构引入了 Zookeeper 和 Controller 节点，架构上更加简单，在主备切换做到了自动化，但故障转移工夫较长，个别是 10 秒左右实现选主。
第三代 Raft 架构目前暂未在云上和阿里团体内大规模利用，且 Raft 协定就决定了须要选主，新主还须要被客户端路由发现，整个故障转移工夫仍然较长；另外，强统一的 Raft 版本并未反对灵便的降级策略，无奈在可用性和可靠性之间做灵便的衡量。

为了应答云上日益增长的业务规模、更严苛的 SLA 要求、复杂多变的专有云部署环境，以后的音讯零碎须要一种架构简略、运维简略、有基于以后架构落地门路的计划，咱们将其称作秒级 RTO 多正本架构。

新一代秒级 RTO 多正本架构

秒级 RTO 多正本架构是消息中间件团队设计实现的新一代高可用架构，蕴含正本组成机制、Failover 机制、对现有组件的侵入性批改等。

整个正本组有以下特点：

Strong Leader/No Election：Leader 在部署时确定，整个生命周期内不会产生切换，但可在故障时被替换。
仅 Leader 反对音讯写入：每一个正本组仅 Leader 承受音讯写入，Leader 不可用时，整个正本组不可写入。
所有的正本反对音讯读取：尽管 Leader 上领有全量的音讯，Follower 上的音讯量不对等，但所有的正本都反对音讯的读取。
灵便的正本组数量：能够基于可靠性、可用性和老本自由选择正本组的数量。
灵便的 Quorum 数量：最终所有的音讯都会同步到整个正本组上，但正本组内能够灵便配置写胜利最小正本数。例如 2-3 模式，3 正本状况下，2 正本胜利即为写胜利。同时，在正本不可用的状况下，Quorum 数量也能够动静自行降级。

在上述正本组的概念下，故障转移能够复用以后 RocketMQ 客户端的机制来实现。如下图所示：

Producer 在主不可用时，灵便疾速地切换至另一个正本组。
Consumer 在某个正本不可用时可疾速切换至同正本组另一个正本上进行音讯生产。

衰弱大盘

咱们在可观测性方面也做了大量的工作，为用户提供了一个音讯零碎的可观测性健康数据大盘。如下图所示，用户可能清晰的看到实例级别、topic 级别、group 级别的各种监控数据，可能全方面地监控、诊断问题。

音讯链路追踪

另外咱们还基于音讯轨迹提供了音讯全链路轨迹追踪性能。如下图所示，用户可能在管制台上看到残缺的音讯生命周期、从音讯的发送、存储、到生产，整个链路都能被残缺地记录下来。

利用场景

客户痛点：业务呈现生产沉积的用户须要依据音讯轨迹抽样数据，综合剖析后能力大抵判断引起问题起因，排查艰难。

外围价值：进步线上运行问题排查的效率，和问题定位的准确性。间接在衰弱大盘上疾速发现危险最高的 Topic 和 Group，并依据各个指标的变动状况疾速定位起因。例如音讯解决工夫过长能够扩容消费者机器或优化生产业务逻辑，如果是失败率过高能够疾速查看日志排除谬误起因。

大家肯定十分相熟 Gartner，在 2018 年的一个评估报告里，Gartner 将 Event-Driven Model，列为了将来 10 大策略技术趋势之一，并且，做出了两个预测：

2022 年，超过 60% 的新型数字化商业解决方案，都会采纳事件告诉的软件模型。
2022 年，超过 50% 的商业组织，将会参加到 EDA 生态系统当中去。

同一年，CNCF 基金会也提出了 CloudEvents，意在标准不同云服务之间的事件通信协定规范。到目前为止，CloudEvents 也曾经公布了多个消息中间件的绑定标准。

可见事件驱动是将来业务零碎的一个重要趋势，而音讯人造具备和事件的亲热性，因而音讯队列 RocketMQ，是坚定拥抱事件驱动的。

谈到音讯和事件，这里做一个简略的论述：音讯和事件是两种不同状态的形象，也意味着满足不同的场景：

音讯：音讯是比事件更通用的形象，罕用于微服务调用之间的异步解耦，微服务调用之间往往须要等到服务能力不对等时才会去通过音讯对服务调用进行异步化革新；音讯的内容往往绑定了较强的业务属性，音讯的发送方对音讯解决逻辑是有明确的预期的。
事件：事件绝对于音讯更加具像化，代表了事件的发送、条件和状态的变动；事件源来自不同的组织和环境，所以事件总线人造须要跨组织；事件源对事件将被如何响应没有任何预期的，所以采纳事件的利用架构是更彻底的解耦，采纳事件的利用架构将更加具备可扩展性和灵活性。

在 2020 年，阿里云公布了事件总线 EventBridge 这一产品，其使命是作为云事件的枢纽，以标准化的 CloudEvents 1.0 协定连贯云产品和云利用，提供中心化的事件治理和驱动能力，帮忙用户轻松构建松耦合、分布式的事件驱动架构；另外，在阿里云之外的云市场上有海量垂直畛域的 SaaS 服务，EventBridge 将以杰出的跨产品、跨组织以及跨云的集成与被集成能力，助力客户打造一个残缺的、事件驱动的、高效可控的上云新界面。

而借助事件总线 EventBridge 提供的事件源性能，咱们可能买通音讯到事件的链路，使得音讯队列 RocketMQ 具备事件驱动的能源，从而拥抱整个事件生态。接下来咱们将借助一个案例，如下图所示，为大家展现这一性能。

创立音讯队列 RocketMQ 主题

创立指标服务

咱们基于容器服务疾速创立一个事件驱动的服务，计算负载 Deployment 的 yaml 如下，该服务可能响应事件并将后果打印到规范输入中。

apiVersion: apps/v1 # for versions before 1.8.0 use apps/v1beta1
kind: Deployment
metadata:
  name: eventbridge-http-target-deployment
  labels:
    app: eventbridge-http-target
spec:
  replicas: 2
  selector:
    matchLabels:
      app: eventbridge-http-target
  template:
    metadata:
      labels:
        app: eventbridge-http-target
    spec:
      containers:
      - name: eb-http-target
        # 下述镜像裸露了一个 HTTP 地址 (/cloudevents) 用于接管 CloudEvents，源码参考：https://github.com/aliyuneventbridge/simple-http-target
        image: registry.cn-hangzhou.aliyuncs.com/eventbridge-public/simple-http-target:latest
        ports:
        - containerPort: 8080

返回容器服务控制台，进入服务与路由的服务页面，创立一个私网拜访类型的 Service，并做好端口映射。

创立事件总线 EventBridge 自定义总线

咱们来到事件总线 EventBridge 控制台，创立一个自定义总线 demo-with-k8s。

创立事件总线 EventBridge 自定义总线规定

咱们为总线 demo-with-k8s 创立一个规定，并抉择 HTTP 作为事件指标，抉择专有网络类型，选中对应的 VPC、VSwitch 以及平安组，并指定指标 URL，如下图所示：

创立事件总线 EventBridge 事件源

咱们为该自定义事件总线增加音讯队列 RocketMQ 版的自定义事件源。

发送 RocketMQ 音讯

接下来咱们回到音讯队列 RocketMQ 控制台，通过控制台的疾速体验音讯生产性能发送一条内容为 hello eventbridge 的音讯到对应的主题中去。

接下来咱们就能够发现，这条 RocketMQ 音讯，以 CloudEvent 的模式被投递到了对应的服务中去，咱们从而买通了音讯到事件的链路。同时，基于咱们上述提到的分级存储性能，音讯队列 RocketMQ 转变成了一个可能源源不断提供事件的数据仓库，为整个事件生态提供了更加广大的场景。

事件驱动是将来商业组织和业务零碎的重要趋势，而音讯队列 RocketMQ 会动摇地拥抱这一趋势，将音讯融入到事件的生态中。

咱们选取了音讯队列 RocketMQ 的几个产品剖面，从多音讯类型、分级存储到稳定性、可观测性，再到面向未来的事件驱动，并联合与开源 RocketMQ 的比照，及具体利用场景的剖析，为大家展现了基于音讯队列 RocketMQ 的大型分布式应用上云最佳实际。

原文链接
本文为阿里云原创内容，未经容许不得转载。

关于后端:基于消息队列-RocketMQ-的大型分布式应用上云最佳实践

前言

外围能力

开箱即用、功能丰富

高性能、有限拓展能力

可观测、免运维能力

高 SLA 和稳定性保障

产品剖面

多音讯类型反对

秒级精准定时音讯

分布式事务音讯

分级存储

可观测性

事件驱动

总结