vlambda博客
学习文章列表

众所周知，Apache RocketMQ 当初被创造出来的主要目标是解决海量消息堆积以及电商场景下的精准顺序消息分发。而自从捐赠给阿帕奇基金会后，社区得到了快速发展，这主要得益于创始团队的坚持以及社区的厚爱。时至今日，Apache RocketMQ已然发展为全球范围内的在线事务消息的首选，成为电商、金融、教育、科技等领域技术中台最核心的数据底座。冯嘉曾在中提到“ 双十一当天的万亿级数据洪峰下，RocketMQ可以做到 99.996% 的毫秒级响应，每秒支撑千万级消息发布，每条消息发布平均响应时间不超过 3 毫秒，最大不超过 20 毫秒，而核心交易链路平均 Response Time 仅 3ms”。经过这些年的发展，无论是性能，还是百分位延迟，Apache RocketMQ都处于同行业水准的佼佼者，这一点大家可以通过OpenMessaging这一开放标准组织发布的benchmark进行测评。

据不完全统计，单就中国而言，金融100强、保险100强、财富500强、券商50强超过70%的企业在核心应用链路上规模化部署了RocketMQ，全球包括AWS，Azure，Alibaba，Tecent，Huawei等云厂商都部署上线了RocketMQ云产品服务。谈起这一点，冯嘉和他的创始团队无比的自豪。

据获悉，就在前不久，分布式系统领域资深专家，中国早期开源先锋探路者，收获无数国内外开源成就奖，阿里中间件消息团队负责人，Apache RocketMQ最初的创始人冯嘉已入职华为云，目前负责华为云中间件产品的整体架构设计与研发工作。对于未来，冯嘉并没有透漏太多。只是从小编采访中，可以看出，Apache RocketMQ 目前主要研发已经分布各大公司，头条，中移动，小米，阿里，华为，腾讯等中间件团队纷纷在布局，共建社区生态。按照冯嘉的说法，未来Apache RocketQ 在服务好消息这个重要场景下，通过深耕RocketMQ Streams（也许会有新的名字）推动符合时代趋势的streaming 融合架构，打造新一代轻量级实时计算平台。在新一代社区领导者杜恒的带领下，我们有理由相信，Apache RocketMQ会越来越好。让我们祝福冯嘉，祝福Apache RocketMQ社区，期待大家在新的时代机遇下能够持续发展，为国家的信创产业贡献微薄之力。

采访中，冯嘉反复强调，Apache RocketMQ的发展和公司高层的大力支持是密不可分的。“感恩小邪（现任阿里云副总裁），感恩阿里”。最后，让我们重温经典，一起看看冯嘉早些年在社区发表的一篇文章，一起期待的规模化推广。开源成就辉煌，所有RocketMQ人有理由共同期待更美好的未来。

存储计算分离与可插拔架构

整体架构会采取存储计算分离与可插拔架构，关于存储计算分离，我知道在工业界这是一个饱受争议的话题，大家可能也看到了Twitter将自己的messaging解决方案EventBus这种存储计算分离的方式，切换回传统的一体式架构，它们给出的原因在于”introduces an additional hop”。没错，通常情况下，确实不需要这么多此一举。但这里我想表达的是，存储计算分离带来的价值就如同我们设计模式里面的单一职责一样，让专注更加专注。举个例子，假如你的引擎部署在IoT边缘云端，你需要你的计算节点按需部署，因为是计算密集型的任务，我们可以将关注点放到如何提升计算能力与响应速度上，而无需关心存储带来的机器成本，运维成本等。再比如，RocketMQ的默认存储我们都看做是时间序列存储的一种，它不但提供了单一数据的存储能力，还有批量存储的能力，但无论如何它是一种数据类型无关的顺序追加存储，在这种架构下，如果希望实现目前事务这种能力，还是有一些复杂的，尤其是当希望将RocketMQ打造成一站式的微服务事务解决方案时，这个我们已经做过一些尝试。据我和很多来自银行的朋友了解到，它们在金融体系中对存储是做了一些改造的，如将文件存储替换成关系型，NoSQL抑或是NewSQL存储，带来的收益就是可维护性增强，增强了事务的处理能力。从这个意义上讲，5.0的架构我希望它是可插拔设计，默认我们会提供极致的顺序追加能力的存储，这也最符合磁盘寻址算法的存储实现。但也带来了另外一个问题，如何提升对数据的查询，处理能力。这里我想分享的是另外一个初步的设计思路，我们继续沿用Commitlog这样的数据结构存储原始数据，然后基于 Commitlog 构建索引或者中间聚合结果，目前我们的索引结构没有达到很好的融合与利用。接下来一个重要方向，就是对索引的改造与优化。另外，我们可以利用 DPDK/SPDK 、写 Pos 原子递增的方式达到最佳的无锁设计，即只有当 HeaderLog 的内容全部分发到索引或者聚合中才认为是已经 committed 的数据，这一系列都需要很大程度上去探索，甚至包括和一些其它社区与高校的合作。所以在这个层面上，我认为我们要让RocketMQ具备分离的能力，同时存储能力又是可插拔，可按需替换的。

全面拥抱OpenMessaging标准

全面拥抱OpenMessaging标准，相信不少同学已经留意到包括阿里巴巴，Yahoo在内的多家公司起草的云原生时代下的消息标准，在这个标准的蓝图里，解决的一个很重要的问题是互操作性，这种互操作性不仅仅来自不同消息厂家之间，还包括消息上下游之间的互操作性。而这种互操作性反应到用户那里，便是API或者协议的一致性，虽然我们认为API也是协议的一种，但我这里分开是想强调，协议的一致性已经被无数场景在努力尝试，但到目前为止，我个人并没有看到一个特别通用且简单的方案，无论是AMQP，MQTT，包括最近被大家开始认识到的RSocket，要想在这一层工作，创新点不会太多，而我们希望避免一些重复的创新，这个时候API层的标准就显得格外重要，所以RocketMQ 5.0在API侧，会重点投入支持OpenMessaging的标准化。未来的多语言，我们希望通过这套API彻底解决大家目前使用RocketMQ多语言遇到的所有问题。

多协议及流计算支持

多协议的天然支持，这一点我觉得也特别重要，所以在5.0里面，我们重构remoting层，在计算节点提供可插拔的传输层协议支持，将会有可能提供HTTP1.1/2的支持。在此基础上，我们也要考虑集成基于TCP的MQTT，UDP的CoAP。当然，我们也清晰的看到随着5.0G网络的逐渐普及，我们可能要积极去跟进市场这块的需求，无论怎么说，保持协议的灵活插拔，一定要成为5.0重点考虑的。

流计算的天然支持，这是目前最为热议的一个话题。我本人也是流计算的早期探索者，但是前些年我们做的所谓流计算，严格意义上来说都是伪场景。为什么是伪场景呢，因为在我看来，一个轻量级的MQ加上简单的处理就是可以实现的。另外，在流计算场景里，消息与存储都是非常重要的一环，那我们为何不让消息天然支持任务节点的调度与计算呢，加上我们内置的存储，可以更好的帮助我们更好的解决状态计算这个痛点。我们只需要提供一个lib包，就可以轻松地让messaging具备流处理的能力。至于后续的SQL处理，CEP，FAAS等，我相信都是这种编程模式的进化。

据悉：经过社区多次的充分讨论，大家一致认定在RocketMQ新架构向前演进的过程中，最重要的就是要保证升级过程的平滑性以及做到向前向后兼容。因此，社区决定采用逐步迭代的方式进行演进，这也是大多数顶级开源项目所采用的向后兼容演进的最佳路径，大致思路可能是：计划通过多个版本迭代逐步演进到上述理想的架构，其中，首先将带来基于raft算法的多副本存储；之后将提供真正的推送方式；随之而来的版本将带来协议的可插拔以及MQTT协议的支持；紧接着就是计划将提供服务端的负载均衡方案，使得客户端更加的轻量级，还将带来基于OpenMessaging的客户端全新解决方案；最后将提供完整的存储计算分离解决方案，用以更好的支撑IOT，多协议，边缘云等新特性，但是我们在传统的消息领域仍将保持简洁的计算存储一体架构，提高资源利用率。