介绍ApacheRocketMQ自诞生以来，经过十余年的规模化业务稳定，服务了阿里巴巴集团100%的内部业务和上万家阿里云企业客户。作为金融级可靠的业务消息传递解决方案，RocketMQ自诞生之日起就专注于业务集成领域的异步通信能力建设。本文将从业务集成场景需求入手，介绍RocketMQ作为业务消息集成解决方案的核心能力和优势，从功能场景、应用案例、最佳实践等角度介绍RocketMQ常用消息类型的使用。说到业务集成场景，RocketMQ最初的使用场景就是一个典型代表。RocketMQ诞生于阿里的电商系统。电子商务系统经常需要做各种促销活动。在如此复杂的需求场景下，对消息系统的吞吐性能、端到端时延、削峰填谷能力都有非常大的影响。要求。一句话概括今天的核心问题，新闻跑在核心交易业务环节有什么特点和需求，和新闻跑在离线分析等场景有什么不同。跟大家一起探讨～业务整合vs数据整合的整合目标是不一样的。在设计核心业务架构时，往往需要针对上层需求完成业务逻辑设计。以电商交易场景为例，通过微服务的拆分，可能会将整个链路拆分成很多个环节。当不同的应用通过消息进行整合时，更应该关注用户订单的流转过程。这个业务逻辑会不会正常处理，这就是业务集成。相比之下，数据集成是以数据为中心的，更侧重于业务集成产生的数据，分析这些业务数据的价值。数据集成不关心数据从哪里来，只关心数据本身的属性和数据之间的关系。侧重点不同在业务集成中，随着企业业务逻辑的扩展和复杂化，调用方和被调用方之间的耦合度会逐渐增加，链路的拓扑也会越来越复杂。经常会发生一条消息的上游是另一条消息的下游，一个服务可能既是发送者又是消费者，等等。在数据融合的场景下，不关注上述环节，更关注数据的多样性。也就是说，在做数据集成分析的时候，更多的是从各种异构数据源中抽取聚合这些数据，然后把这些异构系??统的数据聚合在一起进行清洗，最后聚合成一个结构化的数据或者报表，供用户使用。分析。数据集成更关注数据的异构性和多样性。不同业务的实时融合简单理解就是在线逻辑，或者强实时逻辑。在业务集成这个领域，无论是同步调用还是异步调用，都对调用者和被调用者之间的响应协调机制有一定的要求。比如一个订单的处理，必须在毫秒级内完成，否则用户体验会很差。但是在数据集成领域，更可能出现的是近实时甚至离线的非实时场景，也就是说，通过批处理、实时流式或者近实时的方式来爬取数据-用于分析的时间流场景。具体链接对用户来说是不可见的，这也是数据集成和业务集成侧重点的区别。业务集成对消息系统的核心诉求消息队列是企业业务集成的主要模式之一，是一种异步通信模式。异步模式提供低耦合、高可靠、可观察的异步通信能力。那么在业务整合环节使用消息后会带来什么效果呢？这是一个小清单。上图是一个典型的上层应用链路。从应用程序A到下层应用程序B的单个链接将初始化或结构化消息作为调用事件发送到事件通道。这个通道就是消息系统。如RocketMQ、RabbitMQ等。存储到时间通道后，通过过滤路由的分发组件匹配到下游，然后推送处理。同时，还会有可观察、运维和监控系统来支撑这个链路的可靠运行。有很多完整的功能需求。以下是消息系统业务集成的四大核心需求：1）多类型消息传输：支持各种业务场景的集成需求，主要包括普通消息、定时消息、事务消息、时序消息等；2))丰富的路由分发能力：支持多种分发路由条件，包括Tag过滤、消息属性过滤、一对多、一对一分发等；支持主动消费、被动推送消费、流式响应、单次响应；4）Observable系统：支持Metrics、Trace、Events分析，支持单链路、全链路跟踪跟踪，支持Metrics分析和监控告警，支持系统操作事件和业务事件的暴露和处理。RocketMQ作为一个非常典型的业务消息解决方案，响应了上述业务融合的诉求，提供完备的消息功能、丰富的客户端接口、完备的可观察性体系和稳定性保障机制。接下来我们逐步拆解RocketMQ的多类型消息。本文主要介绍常用消息。普通消息原理介绍功能介绍在各种消息类型中，普通消息是最简单也是最重要的。普通消息是RocketMQ的基础消息类型，提供高吞吐、扩展、低延迟、异步通信能力。其他高级消息类型基本上是在这种普通消息类型的基础上叠加了独特的控制特性或特定的使用方法。下图是普通消息的典型拓扑结构。和消息队列的典型场景是一样的。生产者发送消息，将普通消息发送到服务器存储，存储后根据订阅关系匹配消息，最后推送给下游消费者做消费。普通消息的特点1）原子性：消息之间没有关联，发送和接收的逻辑是原子的；2）可扩展性：可以扩展普通消息的容量和能力，支持多队??列存储、水平拆分、并发消费；3）低延迟：普通消息链接短，交互简单，状态简单，链接极少，毫秒级的低延迟通信。消息的生命周期普通的消息从最初的发送到最终的处理都会经历多个状态和过程，了解消息的生命周期可以帮助我们判断如何快速定位和解决线上问题。简单来说，消息的生命周期可以抽象为五个状态：初始化：普通消息由生产者构造并初始化，等待发送给服务器；待消费：消息传输到服务端，下游可见，等待消费者获取Processing状态；消费：消息被消费者获取，并根据业务逻辑进行处理。此时服务端会等待消费完成。如果消费提交的事件在一定时间后没有收到，则消息会重试处理；消费提交：消费者完成消息处理，向服务端提交响应事件，服务端标记当前消息已经处理完毕（包括消费成功和失败）。RocketMQ默认支持所有的消息保留。此时消息数据并不会立即删除，而是完成了逻辑标记。在消息被物理删除之前，消费者仍然可以返回并重新处理消息；消息删除：RocketMQ根据消息存储时间机制滚动清理最旧的消息数据，从物理文件中删除消息。常见消息应用场景及案例简单了解了原理和基本介绍后，常见消息主要用在哪些地方呢？普通消息是RocketMQ使用最广泛、规模最大的消息类型。主要是服务间的调用解耦，也有批量数据采集和传输等一些场景。使用场景1）微服务调用解耦异步解耦：普通消息实现微服务的异步调用，缩短业务流程和响应时间。流量削峰填谷：具备大量普通消息积累能力，解决流量高峰下游处理能力不足的稳定性风险。2）实时数据传输和高吞吐量传输：普通消息可以实现无限水平扩展，高数据传输吞吐量，解决采集和上报问题。实时传输：普通消息实时传输下发，下游可以及时消费，实现计算分析。案例介绍1）场景介绍交易平台是买卖双方根据约定的合同在网上完成资金和货物交换过程中涉及的系统。交易平台与支付、物流、下单、运营等多个子系统的交互大部分采用RocketMQ普通消息进行异步解耦。消息的可靠处理是电子商务推广保障的核心。2）核心痛点是订单状态机复杂，需要缩短链接时间：订单生命周期长，涉及多个下游子系统的流转，同步调用耗时长，以及用户体验很差。大促场景处理海量订单，下游压力大：大促场景订单流量大，各子系统处理能力不足，导致系统崩溃。分布式场景下订单变化的持久化和下游调用的事务性：订单状态流需要保证数据库状态变化和下游调用同时成功或失败，即事务性。快速上手收发消息说了这么多场景和案例，我们来看看代码的使用方法。发送普通消息发送消息的过程非常简单，但需要注意以下几点：消息初始化要尽可能完整：普通消息初始化包括主题、标签、索引键和负载。可以根据实际情况设置。消息发送需要捕获结果和异常：消息发送完成后需要获取响应结果，如果失败则需要捕获异常重试。消费普通消息RocketMQ支持多种消费方式，包括主动获取和被动消费监听推送。被动消费方式只需要注册消费监听器，然后监听器内部处理这个逻辑，最后返回消费结果。如果消费失败，想要RocketMQ重新提交，会返回失败的结果；抛出异常也会返回失败。类似这样的结果，返回服务端就完成了整个消费过程。对于主动获取方式，会更加灵活。业务方可主动调用获取消息，并可按自己的速率并发获取消息。处理完成后，RocketMQ服务器会回复消费结果。
