RocketMQ 消息集成：多类型业务消息-普通消息

引言

Apache RocketMQ 诞生至今，历经十余年大规模业务稳定性打磨，服务了 100% 阿里集团内部业务以及阿里云数以万计的企业客户。作为金融级可靠的业务消息方案，RocketMQ 从创建之初就一直专注于业务集成领域的异步通信能力构建。本篇将从业务集成场景的诉求开始，介绍 RocketMQ 作为业务消息集成方案的核心能力和优势，通过功能场景、应用案例以及最佳实践等角度介绍 RocketMQ 普通消息类型的使用。

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

一句话概括今天的核心问题，跑在核心交易业务链路的消息有什么特点，有什么要求，和跑在离线分析等场景的消息有什么不同。下面和大家一起来探讨～

业务集成 vs 数据集成

集成目标不同

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

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

关注重点不同

在业务集成里随着企业业务逻辑的拓宽和复杂度的提升，调用和被调用方之间的耦合性会逐步增加，链路的拓扑也会变得越来越复杂。经常会出现一条消息的上游是另一条消息的下游，一个服务可能既是发送方也是消费方，等等。

而在数据集成的场景里面，并不关注上述链路，更多是关注数据的多样性。也就是说，在做数据集成分析时，更多的是从各种异构的数据源里去提取、汇聚这些数据，然后把这些异构系统的数据聚合在一起做清洗，最终汇聚成结构化的数据或报表去做分析。数据集成更多是关注数据的异构性和多样性。

实时性不同

业务集成简单理解就是一种在线的逻辑，或者是一种强实时的逻辑