开发者学堂课程【消息队列 RocketMQ 全类型业务消息学习课程 ：Apache Rocket MQ 阿里云大规模商业化实践之路（一）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1200/detail/18161
Apache Rocket MQ 阿里云大规模商业化实践之路
内容介绍
一、课时概述
二、阿里云消息队列 Rocket MQ 商业化历程
三、阿里云消息队列产品矩阵
四、Rocket MQ4.0 业务消息探索之路
五、Rocket MQ5.0 云原生架构升级之路
六、Rocket MQ5.0 商业版发布预告
一、课时概述
今天为大家分享的主题是 Apache Rocket MQ 在阿里云大规模商业化实践之路。首先会简单介绍一下阿里云消息队列 Rocket MQ 的商业化历程。然后介绍阿里云基于 MQ 构建的消息队列产品矩阵。第三部分是在 MQ4.0的时代商业和开源对业务消息的探索实践。第四部分是 MQ 在云原生时代做的一些架构的升级。第五部分是对即将在阿里云发布的一个 MQ5.0全新商业版作的预告。最后一部分为大家分享阿里云对消息全新形态的探索，事件总线 Event Bridge。
二、阿里云消息队列 Rocket MQ 商业化历程
MQ 诞生于2012年，第一行代码就是在开源社区完成的，2012~2015年 MQ 一直在通过电商业务打磨自身的服务能力，并在2015年进行上线公测。在2016年阿里云 MQ 就完成了商业化，同时阿里巴巴将 MQ 这个软件捐赠给了 Apache 基金会，同年也获得了2016年度最受欢迎开源软件的荣誉。在 Apache 基金会孵化期间，MQ 得到了快速的发展，在2017年不到一年的时间就成为 MQ 的顶级项目。同年 MQ 在 TLP 中的第一个正式版本4.0就正式发布了。MQ4.0发布之后经历了一个长足的发展，在这期间阿里云的商业和开源处于一个相辅相成、齐头并进的状态，直到今天共同迈入 MQ5.0的时代。MQ5.0发布之后，在后续商业和开源的一个合作模式上，阿里云商业会持续采取 open 的模式，也会秉承一个商业优先的数据发展原则，与整个社区一起加入 MQ，打造一个超融合的数据处理平台。这是一个简单的商业化历程介绍。
三、阿里云消息队列产品矩阵
第二部分是为大家介绍阿里云基于 MQ 这个消息底座构建的消息产品矩阵。阿里云基于MQ 的消息底座其实构建了多元化的产品消息序列，包括消息队列 MQ 也是阿里云主打的消息平台，它是互联网新兴业务领域首选的数据通道，所以消息队列 Kafka 是大数据中首选的数据通道。微消息队列 MQTT 是移动互联网和物联网的一个数据通道。消息队列 Rabbit MQ 是传统业务中的数据通道，消息服务 MNS 作为MQ 的轻量版，主要是应用于应用集成的领域，为平台型应用提供简单的队列服务。事件总线 Event Bridge 是定位于云上的事件枢纽，旨在在阿里云上构建一个统一的事件中心。整个产品序列其实是完全构建在 MQ 之上的，基本做到了应用场景的全覆盖，包括微服务集偶、SaaS 集成、物联网、大数据或者日志收集等形态，同时也在内部覆盖了阿里巴巴内部的百分百的业务，同时在云上为数万的阿里云企业提供优质的消息服务。可以说是阿里云的整个产品消息矩阵涵盖了互联网大数据、移动物联网、移动互联网的业务场景，为云原生客户提供了不可或缺的一站式消息解决方案。
四、Rocket MQ4.0业务消息探索之路
MQ 在商业化的历程之中一直是在致力于探索业务消息的最佳实践，孵化了大量的业务消息的特性，并持续反哺到开源社区当中。简单介绍一下 MQ4.0 在商业化过程中的探索。
1、全类型业务消息
首先就是 MQ 在商业化的过程之中陆陆续续的推出了四种科技类型来满足丰富的业务场景。
（1）普通消息
普通但不简单，普通消息提供了极致弹性、海量堆积的一个能力，同时类致的重试和死信队列来满足业务对失败重试的要求。普通消息同时具备高吞吐、高可用、低延迟的特性，来广泛应用于应用集成、异步解耦、削峰填谷等场景。
（2）定时消息
商业版的 MQ 提供一个秒级的定时精度，同时提供40天的超长定时，主要是面向分布式定时调度、任务超时处理等场景，目前定时消息也在开源当中。
（3）顺序消息
MQ 支持全局与局部的严格有序，同时 MQ 从发送、存储到消费是保证一个端到端有序的。顺序消息是面向有序事件处理，撮合交易、数据实时增量同步等场景。
（4）事务消息
MQ 的事务消息其实是一个分布式的、高性能的、高可用的最终一致性的事务解决方案，广泛应用于电商交易系统中各服务一致性协调的场景。事务消息在前几年已经开源到 MQ 的社区当中了。
2、全方位消息接入能力
MQ4.0期间商业和开源都致力于全方位拓展的消息接入能力，使得 MQ 能够非常轻松的去连接应用，开源和云产品生态。比如包括在商业上提供了一个多元 SDK，能够使用 MQ。开源也用相应的 SDK 能够覆盖 java，go，C++来使用 MQ，同时也支持 Spring 生态，能够通过 Spring Cloud 的方式使用 MQ。在商业上还提供了一个非常简单的应用的 HTTP API，这种 API 大概有7种语言的实现。除了 SDK 接入，MQ 也是积极在拥抱数据标准，在云产品册提供了一个 AMQP 和 MQTT 的一个基础能力。那 MQP 这部分的一个能力的其实在年初已经做了一个开源了，在社区里面也是一个可用的一个状态。同时 MQ 在社区大力在发展一个 Connector生态，能够通过 MQ Connector接入很多数据语言，包括 redis，mongoDB，hudi等大数据系统。那另外的话阿里云构建了一个事件总线 Event Bridge，这部分也是在开源的一个状态，通过该产品能够把阿里云中的一些云产品，包括 SaaS 应用，包括自定义应用以及自建的一些数据平台都能够把数据给硕士进来，能够脱离MQ。可以看出来MQ其实在4.0期间做了大量的尝试，提供了一个非常全方位的消息记录能力。
3、领先的业务消息处理和服务能力
（1）消息订阅
MQ在其实在服务集团用户和商业化历程当中，其实沉淀了大量的一个领先的业务消息处理和服务能力，这点比如说在消息订阅方面，MQ 是支持集群的一种分布式消费能力，也支持广播消费。那在消息处理方面也支持基于对消息能够做到基于 Tag 过滤，也能基于 SQL去做一个灵活的过滤。那基于 SQL 功率在电商交易当中是一个非常重要的一个特性，能够支持在一个非常高定位比的情况下能做到一个较低投递比的能力。
（2）全球消息路由
第二块的话是一个全球消息路由的能力，全球消息路由是具备性能高、实时性强的一个消息数据同步的工具。在云时代，数据中心天然就分布在各个地域，那各个地域之间其实也还有 VPC的一个网络隔离。其实可以通过全球消息路由这个功能将整个地域和网络能够打通，能够满足非常多的业务场景。在阿里云内部基于该能力做了很多，比如说包括异地多活、异地容灾等企业级的一些特性。另外该功能是具备非常高的应用性，MQ 提供了一个可视化的任务管理界面，能够通过简单的配置就能够创建一个复制链路。
（3）消息治理
而在消息治理方面的话，MQ 提供的比如说包括访问控制、命名空间、实力限流、消息回放等能力，也包括一些刚刚提到从事死信堆积的治理能力。
（4）服务能力
在服务能力这一块的话，其实 MQ 经历了非常多的沉淀。在内部 MQ其实在服务了交易链的大概12年，参加了十年的双十一，所以说这也保证了 MQ 能够在阿里云上提供非常高的可能性，可靠性的能力。每年双十一消息收发的 TPS 峰值都是过亿的状态，日消息收发总量超过3万，可以说阿里云这边有全球最大的业务消息集群之一。即使在双十一万亿级数据洪峰下，消息也能做到一个99.996%的在毫秒级响应的能力。那消息发布的一个平均响应时间也是不超过三毫秒，最大不超过20毫秒，真正做到一个低延迟的消息发布。
4、全生命周期的可观测性能力
其实在商业化初期的话，客户遇到的最大的难题就是在分布式环境下怎么把异步的一个消息面度能够完整的够追踪起来。至于这个背景的话，其实打造了业界首个可视化的一个全生命周期的消息轨迹追踪系统，能够提供一个丰富的消息查询、消息下载、定点重头的轨迹追踪能力。通过这个可观测系统能够非常容易的帮用户去解决一个分布式环境当中的可观测性问题。
比如说就像这张图所示，一条消息从产生到发送至服务端存储到最终投递到消费者，整个的发送和消费的轨迹都是可循的，包括在投递给哪些消费者，哪些消费者在什么地方成功消费或者消费失败什么时候进行重投都是完全可以追溯的。这个功能其实是在 MQ4.0当中是被广泛使用，也是被一致好评的一个功能，能够真正帮助客户在解决一个分布式的观测难题。
5、全方位的稳定性建设
（1）架构开发
那其实除了功能特性方面，在稳定性方面也做了很多建设。其实在做云产品的第一天，就意识到其实 SLA 是语音的根本，也是云原生一个赖以生存的基础。整个研发运维联络其实都有一个严格的稳定性保障措施，比如说在价格开发产品，每一个方案的设计都会是面向失败去设计的。在代码开发阶段会有严格的 Code Review 阶段，也会完整的经历一个单侧集测，性能和容灾的测试流程。
（2）变更管理
在变更管理方面，其实阿里这边有非常严格的变更制度，要做到每个变更都是一个可回度，可监控，可回滚，可降级的状态。
（3）稳定性保护
在稳定性保护方面我们也做了很多的一个基点，包括每年双十一都会做一些容量评估，都会对一些非核心依赖有降级的措施，对突发流量一些限流的措施。还会有一些大促的保障，包括应急的方案，定期会做一些故障和医院的演练，也会做一些风险梳理。
（4）体系化巡检
那除此之外也搭建了一个体系化的巡检机制，在鱼云其实有一个全方位的生产环境的黑盒巡检。那基于用户视角，会对全地域的所有的功能做一个全功能扫描，会检测50多项检测项。任一项功能出问题，立刻就能够被监测到。在白盒巡检方面也会去对 JVM 的一些运行时指标、内核系统指标、集群指标做一些巡检。
（5）故障应急
在故障应急方面，如果一旦万不得已故障真的产生了，也会有完整的应急流程。就从监控报警到故障发生到快速止血，再到整个排查和修复，再到故障复盘完善应急流程。那刚刚其实就是4.0期间 MQ 在商业化这边做了一些大量的实践。
