消息集成：多类型业务消息

介绍

自Apache RocketMQ诞生以来，经过十余年的大规模业务稳定性打磨，服务了阿里巴巴集团100%的内部业务和阿里云数万家企业客户。RocketMQ作为一个财务可靠的业务消息方案，自成立以来一直专注于业务集成领域异步通信能力的建设。本文将从业务集成场景需求入手，介绍RocketMQ作为业务消息集成解决方案的核心能力和优势，并从功能场景、应用案例、最佳实践等角度介绍RocketMQ常用消息类型的使用。

说到业务集成场景，RocketMQ最初的使用场景就是一个典型的例子。RocketMQ诞生于阿里的电商体系，电商体系经常需要做各种大促活动。在如此复杂的需求场景下，对消息系统的吞吐性能、端到端时延、削峰填谷能力有着极高的要求。

总之，总结一下今天的核心问题，核心交易业务环节中运行的消息有什么特点和要求，与离线分析等场景中运行的消息有什么不同？下面和大家一起探讨一下吧~

业务集成与数据集成

整合目标不同

在设计业务核心架构时，往往需要设计面向上层需求的业务逻辑。以电商交易场景为例。通过微服务的拆分，整个环节可能会拆分成很多环节。当不同的应用通过消息集成时，更多关注的是用户订单的流转过程，以及这个业务逻辑是否会正常处理。这就是业务整合。

相比之下，数据集成是以数据为中心的，它更关注业务集成产生的数据来分析这些业务数据的价值。数据集成不关心这个数据来自哪里，只关心数据本身的属性和数据之间的关系。

关注不同的点

在业务集成中，随着业务逻辑的扩展和复杂度的提高，主叫和被叫之间的耦合度会逐渐增加，链路的拓扑结构会越来越复杂。经常会发生这样的情况，一个消息的上游是另一个消息的下游，一个服务可能既是发送者又是消费者，等等。

在数据集成的场景下，我们不关注以上环节，而更关注数据的多样性。也就是说，在做数据集成分析的时候，更重要的是从各种异构数据源中提取和聚合这些数据，然后聚合这些异构系统的数据进行清洗，最后聚合成结构化的数据或者报表进行分析。数据集成更关注数据的异构性和多样性。

实时差异

简单理解业务集成是一种在线逻辑或者说是一种强实时逻辑。在这个业务集成领域，同步和异步调用都对调用方和被调用方之间的响应协调机制有一定的要求。比如一个订单的处理必须在毫秒内完成，否则用户体验会很差。

而在数据集成领域，更有可能是近实时甚至离线的非实时场景，也就是说，通过批量、实时或者近实时的流场景抓取数据后，具体的链接是用户看不到的，这也是数据集成和业务集成的区别。

业务集成对消息系统的核心需求

消息队列是企业业务集成的主要模式之一，是一种异步通信模式。异步模式提供低耦合、高可靠性和可观察的异步通信能力。那么在服务集成环节使用消息后会带来什么效果呢？这里有一个小清单。

上图是典型的上层应用链接。从应用程序A到较低级别的应用程序B的单个链接将初始化的或结构化的消息作为调用事件发送到事件通道。这个通道就是消息系统，比如RocketMQ和RabbitMQ。在被存储在时间通道中之后，被过滤和路由的分发组件被匹配到下游，然后被推送进行处理。同时，还会有一些可观测的、可操作的、可监控的系统来支撑这个环节的可靠运行。

功能齐全的要求很多。下面是业务集成对消息系统的四个核心需求:

1)多类型消息传输:支持多种业务场景的集成需求，主要包括普通消息、定时消息、交易消息、顺序消息等。

2)丰富路由分发能力:支持多种分发路由条件，包括标签过滤、消息属性过滤、一对多、一对一分发等。

3)多种交互方式:支持发送和接收消息、同步和异步发送、主动消费和被动推送消费、流式响应和单一响应的多种交互方式；

4)可观察系统:支持度量、跟踪、事件分析、单链路和全链路跟踪、度量分析和告警监控、系统运行事件和业务事件揭示和处理。

RocketMQ作为一个典型的业务消息方案，正好对应了上述业务集成的需求，提供了完善的消息功能、丰富的客户端接口、完善的可观察系统和稳定性保障机制。

接下来，我们将逐步拆解RocketMQ的多类型消息。本文主要介绍常见的消息。

通用报文原则介绍

功能介绍

在各种类型的消息中，普通消息是最简单也是最重要的。普通消息是RocketMQ的基本消息类型，它提供高吞吐量、可扩展、低延迟和异步通信能力。其他高级消息类型基本上都是在这个普通消息类型的基础上叠加了独特的控制功能或者特定的使用方式。

下图是普通消息的典型拓扑。与消息队列的典型场景一样，生产者发送消息，并将普通消息发送到服务器进行存储。消息存储后会根据订阅关系进行匹配，最终推送给下游消费者进行消费。

普通信息的特征

1)原子性:消息之间没有关联，发送和接收处理逻辑原子；

2)扩展性:可扩展普通消息的容量和能力，支持多队列存储、水平拆分和并发消费；

3)低延迟:普通消息链接短，交互简单，状态简单，链接最少，毫秒级低延迟通信。

消息的生命周期

普通消息从最初发送到最终处理会经历很多状态和过程，了解消息的生命周期可以帮助我们判断如何快速定位和解决在线问题。

简单地说，消息的生命周期可以抽象为五种状态:

初始化:一般消息由生产者初始化并发送给服务器的状态；待消费:消息传送到服务器，下游可见，等待消费者获取处理状态；消费:消息由消费者获取，并根据业务逻辑进行处理。此时，服务器将等待消费完成。如果在一段时间后没有收到消费者提交的事件，将再次处理该消息。提交:消费者完成消息处理，将响应事件提交给服务器，服务器标记当前消息已被处理。默认情况下，RocketMQ支持所有消息保留。此时，不会立即删除消息数据，而是完成逻辑标记。在消息被物理删除之前，消费者仍然可以返回并重新处理消息。删除消息:RocketMQ根据消息保存时间机制清理最旧的消息数据，并从物理文件中删除消息。

常见的消息应用场景和案例

简单了解了原理和基本介绍后，普通消息主要用在哪里？普通消息是RocketMQ使用最广泛、规模最大的消息类型。主要关注服务之间的解耦调用，以及批量数据的采集和传输等一些场景。

使用场景

1)微服务调用解耦

异步解耦:普通消息实现微服务的异步调用，缩短了业务流程和响应时间。削峰填谷:共同消息的海量积累能力，可以解决高峰流量下游处理能力不足的稳定性风险。

2)实时数据传输

高吞吐量传输:普通消息可以无限扩展，数据传输吞吐量高，解决了采集上报问题。实时传输:普通消息实时传输传递，下游可以及时消耗，实现计算分析。

案例介绍

1)场景介绍

交易平台是买卖双方根据约定的合同在网上完成货币和商品交换的过程中所涉及的系统。平台涉及与支付、物流、订货、运营等子系统的交互。大多使用RocketMQ普通消息进行异步解耦，消息的可靠处理是电子商务保障的核心。

2)核心难点

订单状态机复杂，需要缩短链接时间:订单生命周期长，涉及下游几个子系统的流转，同步调用时间长，用户体验差。

大规模场景订单处理，下游压力大:大规模场景订单流转，各子系统处理能力不足导致系统崩溃。

分布式订单变化的持久性和下游调用的事务性:订单状态循环需要保证数据库状态变化和下游调用同时成功或失败，即事务性。

快速发送和接收信息。

说了这么多场景和案例，我们直接来看看代码是怎么用的。

发送普通消息

发送消息的过程非常简单，但需要注意以下几点:

消息初始化应该尽可能完整:常见的消息初始化包括主题、标签、索引键和有效载荷。可以根据实际情况设置。消息发送需要捕捉结果和异常:消息发送时，需要得到响应结果；如果失败，它需要捕捉异常并重试。

普通消费新闻

RocketMQ支持多种消费模式，包括主动获取模式和被动消费监听器推送模式。

被动消费只需要注册消费监听器，然后监听器内部处理这个逻辑，最后返回消费结果。如果消费失败，希望RocketMQ重新投资，我会返回一个失败的结果；抛出异常也是返回失败。类似这个结果，回到服务器就完成了消费的全过程。

至于主动获取的方式，会更加灵活。业务方可以主动调用获取消息，可以根据自己的速率和并发来获取消息。处理完成后，会回复RocketMQ服务器的消费结果。

原文链接:http://click.aliyun.com/m/1000350415/

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