引言
Apache RocketMQ 诞生至今,历经十余年大规模业务稳定性打磨,服务了 100% 阿里集团内部业务以及阿里云数以万计的企业客户。作为金融级可靠的业务消息方案,RocketMQ 从创建之初就一直专注于业务集成领域的异步通信能力构建。本篇将从业务集成场景的诉求开始,介绍 RocketMQ 作为业务消息集成方案的核心能力和优势,通过功能场景、应用案例以及最佳实践等角度介绍 RocketMQ 普通消息类型的使用。
说起业务集成场景,RocketMQ 最初的使用场景就是典型代表。RocketMQ 诞生于阿里的电商系统,电商系统经常需要做各种大促活动,在这类复杂需求场景下对消息系统的吞吐性能、端到端延迟、削峰填谷等能力有着极高的要求。
一句话概括今天的核心问题,跑在核心交易业务链路的消息有什么特点,有什么要求,和跑在离线分析等场景的消息有什么不同。下面和大家一起来探讨~
业务集成 vs 数据集成
集成目标不同
做业务核心架构设计时,很多时候需要面向上层需求去完成业务逻辑的设计。以电商交易场景为例,通过微服务的拆分,可能在整个链路中会拆成很多个环节,不同应用之间通过消息去集成时,更多的是关注用户订单的流转过程,关注这个业务逻辑是否会正常的处理,这个就是业务集成。
对比一下,数据集成是以数据为中心,更多的是关注业务集成产生的数据,去分析这些业务数据的价值。数据集成并不关心这个数据是从哪里来,只关心数据本身的属性和数据之间的关系。
关注重点不同
在业务集成里随着企业业务逻辑的拓宽和复杂度的提升,调用和被调用方之间的耦合性会逐步增加,链路的拓扑也会变得越来越复杂。经常会出现一条消息的上游是另一条消息的下游,一个服务可能既是发送方也是消费方,等等。
而在数据集成的场景里面,并不关注上述链路,更多是关注数据的多样性。也就是说,在做数据集成分析时,更多的是从各种异构的数据源里去提取、汇聚这些数据,然后把这些异构系统的数据聚合在一起做清洗,最终汇聚成结构化的数据或报表去做分析。数据集成更多是关注数据的异构性和多样性。
实时性不同
业务集成简单理解就是一种在线的逻辑,或者是一种强实时的逻辑