Austin消息中心

简介: Austin消息中心

写这篇文章是首先我之前也是做过消息中心的需求,当时3y开源了它的项目Austin,当时觉得挺好的,之后我负责的消息中心重构了一版,现在想想也挺开心的。所以想把之前学习的整理了下来。

      开源项目Austin的地址:https://gitee.com/zhongfucheng/austin,以下内容基于Austin,同时带上自己的一些思考。更多细节请参考开源项目Austin,作者是3y,感谢作者开源这么好的项目。以下内容基于Austin。

一、首先我们来说思考一下,如果实现一个消息中心?

1.实现的原则

方便业务方调用,同时调用的成本相对来说较小,统一的接口发送各种类型消息,对消息生命周期全链路追踪。也即实现一个消息中心,需要对来自各个渠道的消息进行统一接口的提供,方便排错。同时方便后续的迭代开发。同时实现熔断限流的功能。

2.消息中心提供的能力

邮件、短信、IM、微信服务号、微信小程序、企业微信、钉钉、飞书等

3.实现的模型

业务方通过消息中心,能够实现对短信、邮件、IM、微信类、飞书等消息的正确发送


4.具体的实现方式

1).首先它具有多种渠道,因此我们需要对此维护一个渠道的相关账号信息

2).由于发送的消息不同于消息中间件的消息,比如短信、邮件等,需要先准备好模板,因此需要一个模板表

3).由于存在审计信息需要记录,发送消息的人发送的消息记录

4).由于存在审计信息需要记录,因此这里需要准备一张消息接收者接收消息的情况

5).对失败的消息进行一些补充或者重试,此时需要起一些定时任务或者在代码中进行重试,这个具体需要根据业务的需求进行

6).对失败和成功的消息做指标的统计,方便业务查询哪些消息发送成功了,哪些消息发送失败了,如果失败了,可以进行手动重试与定时任务重试,这个具体根据业务方的需求进行

也即总结起来就是:

实现多渠道统一接口
模板信息的准备与填充
审计信息的记录
成功失败指标统计
失败重试与提示

5.实时之外延迟队列=>不定时任务—延迟队列

除了实现这些功能外,思考一下,如果业务通常希望今天填充的信息,明天能够在某时某点能够进行发送,而且每次可能都是不固定的。此时就不再单单是发送了,需要考虑延迟的情况,也即结合延迟队列实现对短信的方式或者邮件等等。

延迟队列的实现,网上有很多实现的方案,这里主要介绍三个实现的方案:

1.基于开源版本的RocketMQ的延迟队列实现,其在5.0之后是支持任意精度的延迟消息队列的,在5.0之前它不支持任意精度的延迟消息队列。其实现原理是通过时间轮的方式实现的。

5.0之前,通过将消息的主题修改SCHEDULE_TOPIC_XXXX,并投递到延迟队列,比较局限只支持18个等级,精度有限。时间轮是一种算法, 用来管理和调度固定时间间隔内的事件。它将固定时间间隔分成若干个时间槽,并将事件映射到相应的时间槽上。在时间轮中,每个时间槽都会按顺序处理它所映射的事件,从而实现对固定时间间隔内的事件的调度。

支持的RIP:[RIP-43] Support Timing Messages with Arbitrary Time Delay

2.基于xxl-job实现,这个是开源项目Austin主推的方式

方案:万物皆扫表,针对这次需求(晚上发的消息,次日早上发送),就不需要上延时队列,因为austin已经接入了分布式定时任务框架了(对应的实现是xxl-job),只要把晚上的接收到的消息扔进Redis list,然后启个定时任务(每天早上9点)轮询该list是否有数据,如果有再重新做处理就完事了。当然它这种也不属于任意精度的。只能说是定时

3.基于Redis实现,思想还是轮询。基于Redis 实现一个轻量级的延迟队列。


6.实现业务之外的考虑-防重

业务方使用不当,不小心连续推送了两次,如果没有任何限制,那就真的下发了两次。试想下,如果你点了下验证码,如果收到了两条一模一样的短信,你是什么感受?作为平台需要有兜底的功能(尽可能避免由于业务使用不恰当,导致出现事故)

7.实现业务之外的考虑-防重-统计量化监控限流

前面说到对相关指标进行统计量化,仅仅是做这些是做了成功失败的统计,做这些是不够的。第三方接口一般都会有限流的,比如在腾讯云官网上看到对发送接口有3000QPS的限制。我们是需要知道现在各种类型的消息的发送情况是怎么样的,是否有限流的操作。如果限流了,是不是可以告诉业务方可能是原因目前发送量过大导致触发限流。系统上有完备的监控,你知道了各种的系统指标数据,自己才不会慌。比如此时产生的白名单、黑名单信息记录。同时实现熔断限流的相关措施。

8.实现业务之外的考虑-防重-花销统计

接入的短信后台都有对应的统计,但我们量大的话是需要「对账」,以我们的发送记录与回执统计跟短信的后台进行统计。austin使用的方案是基于hive实现。将短信的发送和回执数据导入到Hive,每个月跑一次Hive脚本统计进行对账

9.实现业务之外-供应商的服务挂掉了怎么办

比如某个短信渠道商挂了怎么办?短信需要接入多个渠道商,调用接口失败需要继续调用其他渠道商,支持动态分配渠道商的流量(一旦有提前预警,直接切换渠道商)

实现业务之外需要实现的功能

延迟队列
防重
统计量化监控限流
花销统计
多渠道服务

10.实现业务之外-可配置

相关参数信息可配置化,这里可以看到其使用了nacos进行相关参数配置化。

二、Austin的实现

首先准备好对应的账号信息、渠道信息、模板信息,然后进行消息的发送。

实现流程


austin-web:为前端项目提供相关接口  可以调用austin-web创建发送消息
austin-cron: 承载着定时任务的工作
austin-api: 接受到发送消息请求,直接将请求进MQ
austin-handler: 消费MQ消息后,由各类handler进行发送处理
1.调用消息推送接口
2.接受消息推送接口返回信息
3.保存消息推送接口返回信息至mysql
4.从推送消息第三方拉去,推送消息回执
5.将回执信息保存到mysql中
austin-stream:处理handler产生的日志数据
austin-support: pipeline的支持、获取配置、mq的封装等,主要是对项目的支持
austin-conmmon:公共类
austin-data-house:对数据的处理,hive、flink

开源项目参考地址:https://gitee.com/zhongfucheng/austin

相关实践学习
消息队列RocketMQ版:基础消息收发功能体验
本实验场景介绍消息队列RocketMQ版的基础消息收发功能,涵盖实例创建、Topic、Group资源创建以及消息收发体验等基础功能模块。
消息队列 MNS 入门课程
1、消息队列MNS简介 本节课介绍消息队列的MNS的基础概念 2、消息队列MNS特性 本节课介绍消息队列的MNS的主要特性 3、MNS的最佳实践及场景应用 本节课介绍消息队列的MNS的最佳实践及场景应用案例 4、手把手系列:消息队列MNS实操讲 本节课介绍消息队列的MNS的实际操作演示 5、动手实验:基于MNS,0基础轻松构建 Web Client 本节课带您一起基于MNS,0基础轻松构建 Web Client
目录
相关文章
|
3月前
|
JavaScript 前端开发 API
第二十九章 使用消息订阅发布实现组件通信
第二十九章 使用消息订阅发布实现组件通信
|
存储 消息中间件 缓存
|
2月前
|
消息中间件 网络性能优化
消息队列 MQ产品使用合集之通过MQTT控制台查询不到设备轨迹或消息轨迹是什么原因
阿里云消息队列MQ(Message Queue)是一种高可用、高性能的消息中间件服务,它允许您在分布式应用的不同组件之间异步传递消息,从而实现系统解耦、流量削峰填谷以及提高系统的可扩展性和灵活性。以下是使用阿里云消息队列MQ产品的关键点和最佳实践合集。
|
3月前
|
消息中间件 Java Kafka
【消息中心】kafka消费失败重试10次的问题
【消息中心】kafka消费失败重试10次的问题
289 0
|
3月前
|
微服务
注册中心机制
【2月更文挑战第16天】注册中心机制
41 5
|
消息中间件 监控 JavaScript
聊聊 消息中心的设计与实现
聊聊 消息中心的设计与实现
|
消息中间件 存储 运维
RocketMQ 消息集成:多类型业务消息-普通消息
本篇将从业务集成场景的诉求开始,介绍 RocketMQ 作为业务消息集成方案的核心能力和优势,通过功能场景、应用案例以及最佳实践等角度介绍 RocketMQ 普通消息类型的使用。
262 0
RocketMQ  消息集成:多类型业务消息-普通消息
|
消息中间件 存储 算法
RocketMQ 消息集成:多类型业务消息——定时消息
本篇将继续业务消息集成的场景,从使用场景、应用案例、功能原理以及最佳实践等角度介绍 RocketMQ 的定时消息功能。
449 0
RocketMQ  消息集成:多类型业务消息——定时消息
|
消息中间件 存储 算法
RocketMQ 消息集成:多类型业务消息——定时消息
本篇将继续业务消息集成的场景,从使用场景、应用案例、功能原理以及最佳实践等角度介绍 RocketMQ 的定时消息功能。
RocketMQ 消息集成:多类型业务消息——定时消息
|
消息中间件 负载均衡 Java
消息消费基本流程|学习笔记
快速学习消息消费基本流程
83 0