面向业务的消息服务设计

线前，马蜂窝大部分业务中的异步需求是通过 Redis 队列来实现。随着消息量增加，经常会出现消息积压、不同消息之间互相影响的问题。为解决这些问题，电商研发团队开始规划和设计消息总线。

为什么会有消息总线，而不是让业务系统直接用 PHP 或者其他语言对接 RabbitMQ，Kafka 这样的消息系统?

「消息总线和直接使用消息系列有什么实际的区别?」，这是很多研发同学一开始不太理解的地方。假如只是为了用一个性能更好的消息系统代替 Redis，确实并不需要消息总线的这个角色。

但当我们从实际业务角度出发，对公司整体技术架构和开发场景的梳理时，发现如果直接让业务系统对接消息系统，并不是一个很好的方式，并且至少会面临以下问题：

系统分散。各开发团队需要维护各自的消息服务，彼此之间相对隔离。

增加开发难度。用户需要关注具体消息所在消息服务的配置，关注不同业务的消息可能要对接不同种类的消息系统。

维护成本高。用户需要管理自己消费服务的稳定性，处理各种服务异常，保证消费的可靠性。特别对于 PHP 来说，这个成本还是比较高的。

管理难度大。没法对业务消息的创建和订阅关系进行统一管理，也不方便对业务消息中的敏感数据进行权限管理。

不易扩展。无法统一消息系统扩展功能(路由、延时、重试、消费确认等)的使用。

总体来说，直接使用消息系统可以被看成是一个面向技术的接入方式;而消息总线则期望通过隐藏部署、分组和通信等细节，实现一个面向业务的接入方式。

架构设计和技术实现

1. 架构设计

消息总线隐藏了消息发送、路由、分组、存储、消费负载、通信、高可用等一些列问题。对使用者来说，只需要在发送端调用一个 SDK 消息发送方法，

（编辑：梅州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!