马蜂窝消息总线——面向业务的消息服务设计 _消息

App 1 的应用只负责发出消息，至于什么业务需要关注，下游业务应用自己订阅该消息就可以。很大程度上减少了上游业务和下游业务的耦合程度和开发调试成本。
【马蜂窝消息总线——面向业务的消息服务设计】消息总线使用 DB 来进行消息订阅关系的存储，上游业务的消息经过消息总线时会根据订阅关系，裂变为是订阅应用的多条消息。这样的消息裂变方式使消息后续在消息总线流转时目标明确，在进行消费负载，消费确认，失败重试等场景时可以按照进行隔离。
同样调用方可以使用 SDK 提供的 pub 方法进行消息的发送，订阅方通过消息管理系统进行消息订阅的申请。

文章插图
4). 防消息干扰
很多使用消息总线的同学比较关心不同消息之间是否会相互干扰，比如由于某个消息短时间内大量涌入是否会造成其他消息被阻塞。
通过前面架构的介绍，可以看到所有的消息经过时可以进行路由、分组。消息总线未来会根据业务和消息量来做一些物理隔离，保障业务之间不会相互影响。
而在一个分组内，消息总线也有一些机制保障分组内的不同消息不会相互影响。

文章插图
图5 防消息干扰机制
消息经过默认会进入一个Queue 的队列中，集群中会有多个监听Queue 。在服务内，通过来控制消息总并发消费量，以及同类型消息的并发消费量。当某种类型的并发消息数量超过阈值时，就会被转发到Queue，避免消费都被同一个类型的消息占用。而Queue 会被独立的服务监听进行消费，不影响Queue 的消费。
5). 消费服务高可用

文章插图
为了保证消费时的高可用，群在负责进行消费协议转换之外，也做了一些策略来保证消费端的高可用。
◆ 熔断
在消息一段时间内失败数量超过阈值时，停止对队列的消费，避免由于服务抖动和线上故障引起的大面积消息。
◆ 消费失败
熔断后，服务会对后端应用服务健康度进行监控，在服务恢复后可自动恢复消费。
◆ 系统失败重试
消息总线服务发生故障时，可对期间的失败消息采用重试策略进行重试，避免由于基础服务问题造成的消费失败。
◆ 业务失败重试
在业务应用消费时产生业务异常，可在订阅消息时指定是否进行重试。消息总线会对需要失败的消息按照一定的时间周期进行多次重试。
◆重启
实现了重启和退出，保障当前正在消费的消息都处理完成后才会进程退出。
未来规划

文章插图
图7 未来演进方向1. 产品化
当前消息总线在功能上经过近一年的迭代，已经基本稳定。但在消息管理，监控，统计等环节对开发者来说还不够友好，接下来一段时间会着重优化系统的易用性。
目前已经在规划以下方向的优化改进：
开发者可以通过消息管理系统进行新增消息，订阅消息 (加入权限的审核) 等操作，代替当前手工提 issue 的方式。
开发者可以通过系统关注到自己消息的消费情况，并及时接收到消息处理异常的报警。
完善监控体系，提供更精细维度的系统监控数据。
2. 微服务
关于在微服务架构内提供消息总线服务，也已经在计划当中。包括在微服务内进行消息发送和使用某个微服务进行消息的消费。未来整个消息总线计划会往下图的架构进行演进，增加对多语言和不同架构服务的支持。适应更多的业务开发场景，提供更稳定，友好的消息总线服务。
另外对消息引擎的技术选型，未来也会考虑接入 Kafka，等其他消息队列服务。根据不同业务场景的消息特性，在发布时选择进入不同的消息队列服务。比如对可靠性，数据安全性要求高的消息会进入，而对高吞吐量的消息可以进入 Kafka 。但对消息的发送方和订阅方来说都可以不用关心这些细节，仍然按照统一的方式进行接入。
马蜂窝消息总线服务当前也在不断迭代中，在很多地方还有不少没有考虑到的问题。欢迎大家多提宝贵意见，您可以扫描下方二维码订阅「马蜂窝技术」更多内容。