消息中间件一直是企业核心架构的重要组成，消息系统的高性能和稳定迭代时刻的影响着业务核心系统的稳定性。
正所谓十年磨一剑，阿里云消息队列RocketMQ 也拥有着久远的迭代历程，过程中经历了几个核心的高光时刻。 2007 年，淘宝电商做微服务拆分，诞生了第一代 RocketMQ 的原型消息，奠定了 RocketMQ 扎根于核心业务交易链路的集成基因。 2012 年， RocketMQ 正式发布，诞生之初即为开源、开放的内外一体演进方式，阿里巴巴自此之后也一直坚持三位一体的发展思路，将内部的生产经验带到开源社区以及阿里云上的企业客户群体，RocketMQ 同时在三种场景下进行持续打磨和演进，服务了数十万开发者和企业群体。
去年，社区发布了 Apache RocketMQ 5.0 版本，RocketMQ 升级为消息事件流一体的处理平台。2022年8月，阿里云在全球的云厂商中率先实现了 5.0 系列的商业化。
伴随全球经济形势的变化以及企业IT架构演进的诉求。 RocketMQ5.0商业版的核心使命是为企业提供更加实惠、好用、便捷的消息服务，拥有降本提效、弹性扩展、方便易用、轻量集成几个关键能力。
新系列的售卖策略优化了产品的售卖形态，计费策略和定价相比上一代更加简单、弹性和多样，综合成本最高可降低50%。团队在计费项目上做了大幅简化，降低了开发者的理解成本。
新系列的计费由计算、存储、网络三个部分组成。
计算规格指付费实例将按照集群的峰值吞吐 TPS 来估算，这一点也与大多数运维人员的心智比较匹配。提供了从 2000 - 100万 TPS的规格，客户可以按照自己的业务规模选择合适的规格，后续可随时进行配置变更和升降配
存储指用户在实例里实际消耗的存储空间。阿里云的RocketMQ 5.0 存储为serverless架构，用户无需预先购买规格，只需按照实际的消耗量付费。
网络为可选项，大部分客户从内网访问消息，内部网络访问免费。但在少量特殊场景下，如果需要使用公网来传输消息，可以选配公网的能力，需要支付公网下行的带宽费用。
RocketMQ5.0提供了非常灵活的付费模式，支持按月付费、按小时付费。生产环境中建议使用包月模式，单价更低；测试环境或项目环境等临时场景，建议使用按量付费，可以随时释放，后续也可转换为包月模式。
除了付费项目和付费形式的变化，我们也为客户准备了多样的实例规格，价格相比于比老版本大幅降低。新版本推出了专业版系列，每月只需要4000+费用，即可享受大规模集群、突发弹性、可观测增强以及容灾集成等企业级能力。
考虑到很多客户在做集成测试时会有大量测试环境的诉求，RocketMQ5.0还贴心提供了测试环境专用实例，在保证功能一致的情况下，门槛降低至300+元/月，大幅降低了客户构建测试环境的成本。除了售卖策略降价之外，RocketMQ5.0 商业版在计算弹性、存储弹性方面也有很大升级。
上图为典型的消息吞吐量曲线。正常业务系统消息处理的过程中曲线并不是一成不变，而是伴随着业务的高峰、低谷频繁波动。如果按照常规的资源保障，则必须按照峰值能力去购买规格或部署资源，该方案存在几个问题：
第一，运维难度。如果是突发峰值流量，无法预期，紧急的扩容无法及时跟上，导致业务损伤，极端情况还会导致整个集群垮掉。
第二，如果为了避免毛刺，提前扩大集群的规模，预留足够的 buffer ，虽然可以避免一定的风险，但是又会带来很大的资源浪费。
RocketMQ 5.0 系列为以上痛点提供了一套组合方案，用户可以按照经验为业务的处理划定预留的基线，在预留范围之内直接购买规格即可抵消费用。对于突发的毛刺以及波动的流量，可以选择开启弹性能力。开启之后，超出基准部分的流量可以按量付费，使得业务无需一直为少量脉冲型流量支付全部的费用。预留部分，RocketMQ 5.0提供了从 2000-100 万 TPS随时升降配选择。此外，突发弹性可以支持秒级的响应速度，保证业务无感。
RocketMQ 5.0 商业版的存储，无需用户提前购置磁盘空间，按量使用、按需付费。且在相同的副本情况下，商业版的单位定价是自建成本的1/3，非常优惠。阿里云基于自研的多机存储架构，对数据做了冷热分离处理，充分利用了云厂商的存储资源池做弹性。
在常规的开源消息方案中，存储的扩缩容一直是难点。首先，云盘无法缩容，如果提前购置了大量盘，缩容只能做数据搬迁、换盘。其次，在扩容和搬迁存储的过程中很容易出现运维故障，风险很高。
而商业版 5.0 系列使用户再也无需评估存储规格，存储容量无上限，使用非常方便。而且 RocketMQ 5.0 商业版提供的存储方案默认三副本、高可靠，数据不会丢失，且即将支持最长一个月的保存时效。开源社区的某些版本会因为本地空间不足导致消息无法写入或清除最早的数据，无法百分百满足保存时效。
冷热分离的存储架构也可以很好地隔离读写压力，避免在堆积等场景下影响热数据的写入性能。
RocketMQ 5.0 商业版在开发管理方面完全对齐开源版本的习惯，优先推荐使用开源 SDK ，与社区保持一致，各个 API 的接入门槛更低。伴随着社区版本的发布， RocketMQ 5.0 系列提供了一套全新的轻量化SDK ，相比早期版本有很大的升级和改变，列举其中三点如下：
第一， SDK 设计方面，配合了服务端全新的存储计算分离架构，将很多复杂的管理逻辑上移到服务端，客户端的设计更加轻量。而轻量带来的好处就是客户端的逻辑更稳定，出问题之后更容易诊断和分析。
第二，新的 SDK 在可观测能力上做了很多增强，补齐了几十处的埋点以及指标采集。支持 OpenTelemetry 标准协议上报客户端的轨迹信息以及指标的信息，配合服务端分析工具和大盘可快速定位客户端应用的情况。因为采用了标准协议，RocketMQ5.0 也支持用到用户自定义监控系统的集成。
第三，RocketMQ5.0 多语言 SDK 有了很大增强，基于新版本协议推出了原生的多语言 SDK 覆盖，前期可以覆盖 Java 、C++、.net 以及 go 的原生支持，后续也会逐步完善其他语言。
消息系统时业务的核心数据链路，耦合了上下游的业务逻辑。当业务出现非预期的问题时，问题排查过程中往往会出现相互拉扯，比如消息底层的服务看起来很正常，但是业务消息却没有收到或者没有处理成功。同时，当系统处于高水位运行或在大促等极端场景下，业务指标如果出现恶化趋势，很可能无法及时判断和巡检，诸如此类的问题都是由于消息系统可观测能力的欠缺导致。
RocketMQ5.0 商业版为客户提供了开箱即用的可观测能力组合，包括轨迹追踪、指标分析监控、事件中心等能力，从点、线、面多维度地覆盖问题，覆盖了生产、存储、消费全生命周期的 40 多项指标，支持免费的Grafana大盘分析，常见的消息堆积、消息处理耗时、收发成功率等指标一览无遗。
用户也可以很方便对生产环境的集群做巡检和监控，针对上层业务系统可以提前发现问题。同时，RocketMQ 5.0 的系列客户端 SDK 指标和轨迹数据支持标准的 OpenTelemetry协议导出，支持与自定义系统监控的集成。
RocketMQ5.0系列实例还针对生产环境常见的故障应急配置、更新操作等做了升级，支持动态配置管理和更新，提高生产环境中突发情况的应急响应速度。RocketMQ5.0 商业版实例内建了一套高可靠的元数据中心，将 topic group 生产者、消费者等配置统一收敛到一起。用户可以基于控制台的页面白屏化地操作变更，即可动态刷新配置，推送到客户端并动态生效。此套机制有两个优势：
第一，统一配置中心的元数据中心，可以避免消息的配置散落在不同的客户端代码里，造成不同版本的不一致和混乱。历史上出现过大量工单因为客户的各个应用配置不一导致故障。
第二，在故障应急的场景中，不再需要重启各个客户端的应用，可以快速生效，一方面提高了运维人效，缩短了处理时间，同时也降低了紧急情况下的变更范围和风险。
RocketMQ 5.0 商业版系列除了消息基础的机制增强能力之外，也为方便企业客户完成高效的上下游数据集成、降低开发门槛和代价，提供了一套开箱即用的上下游消息集成服务，消息作为其中的数据源和目标，对接到阿里云的 EventBridge 集成中心。
上下游的其他生态产品，比如网络存储、计算数据库、大数据等多种产品可以快速连接到消息，实现打通。该套集成方案目前支持阿里云一方产品、三方 SaaS 等大概 200 多款上下游产品，可以说只要有集成诉求都可以连接。
其次，基于消息集成的方案，用户的开发门槛低。内置了 10 多种数据抽取转换模板，用户可以直接白屏化配置，即可抽取数据到目标下游。如果内置的模板不支持，还能提供自定义函数的能力，可以编写自定义的处理逻辑。此套系统运行的过程中，用户无需部署和运维。基于阿里云的 FaaS 的底座和弹性 Serverless ，使用非常方便。目前已有大量客户使用该方案实现 ETL消息路由等能力。
