为了适应公司的业务发展以及未来不同场景下的消息应用,我们将引入消息中心概念,抽取通用和稳定的部分划归到消息中心来实现,拆解模块之间的职能,解决重复造轮子,反复改问题的现象。同时将不同的消息渠道整合,为不同的业务线提供不同场景的应用支撑。基于此背景,我们搭建了一个基于内部系统的消息中心。
3.1 业务系统架构
应用架构这里就不展示了,因为是基于技术部中间件团队java应用(nvwa)工厂生成标准COLA的多模块项目模板应用。
3.2 消息流程管理
消息通知的流程设计,在各个业务线中通过消息中心提供的接口方法,将不同场景下的消息内容提交到消息中心,消息中心进行统一维护管理,并根据消息的来源和去向,适配相应的推送逻辑:
消息生产:涉及到的场景很多,比如活动、系统通知、业务流转、过期提醒等;
消息管理:对预发送消息的结构和参数进行校验,并创建消息推送的任务,维护任务级别的推送管理,跟踪消息的状态周期;
消息处理:基于消息任务的结构,构建消息推送的主体内容,并对接多个发送渠道,实现通知的高效触达;
定时任务:消息可以直接即时推送,但如果是夜间定时任务触发,则要考虑推送延迟问题,将消息放在指定时段投递;
渠道对接:通常不同的渠道意味着不同的场景,例如监控推送飞书,邮件走email,业务则应用内通知;
在整个流程中涉及到的模块比较多,状态的流转也很复杂,但是通过消息中心进行统一标准管理和流入流出的跟踪,也可以提供清晰的生命周期监控和维护。大部分的消息通知机制都可以容忍一定的延迟性,所以消息中心完全可以解耦各个流程,引入MQ队列或者异步机制,业务方只需要将请求发送到消息中心,之后由消息中心统一调度和管理即可。
3.3 数据模型
3.4 飞书通道与业务系统对接过程中遇到的问题
3.4.1 老应用有增量消息需接入效率消息中心,效率消息中心该如何解决历史消息转发及复杂交互类型消息的事件回调。
{
"reachType": 2,
"templateCode": "*******",
"sendTime": 1687163457335,
"reachList": [
{
"contentParamList": [
{
"key": "addCourseCount", // 动态参数[新增课程总数 (30)]
"value": "30"
},
{
"key": "lastWeekNewCourseCount", // 动态参数[上周上新课程数量 (20)]
"value": "20"
},
{
"key": "dataList", // 动态参数,数据格式用户可自定义
"value": "[{\"courseName\":\"测试课程内容1\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"},{\"courseName\":\"测试课程内容2\",\"courseUrl\":\"https://t1-iwork-rdc.shizhuang-inc.net/rdc/desk\"}] "
}
],
"receiverId": "*******"
}
]
}
b. 使用VelocityEngine语法解析
<code>
#set($myList=$dataList) // api接口传过来的参数
#set($result = '')
#foreach($item in $myList) // 拼接消息内容
#set($result = $result+'['+$item.courseName+']'+'('+$item.courseUrl+')'+'\n')
#end
#set($growthContent="**新人成长(10)**\n$result") // 输出最终消息内容
</code>
c. 动态渲染输出
3.4.3 在消息中心平台推送大规模消息,如何去跟业务系统的机器人去做平衡而不触发飞书平台限流
业务场景:在一个阳光明媚的早上,业务同学用潮人研习社的机器人给公司用户推送了chatgpt的学习先关的内容,消息推送触达竟然花费了一个1多小时。
问题分析:没办法,做为技术boy,只能埋头去寻找根因,主要有以下几点
如上图所示,每次消息推送都要做获取token这个动作,显然获取token这个动作是可以优化的。基于飞书返回的失效时间做近端缓存。
消息推送接口虽启用了异步推送,但是在一个消息体里面有很多触达用户时,没有进行分组,底层推送给飞书时还是串行在推消息(这里没有采用飞书的批量发消息接口,是因为在产品侧有个功能要去统计单个用户已读未读的数据,用批量推送的话,具体到用户粒度的已读未读数据飞书是不支持的。另外一个原因就是飞书的机器人不是集中在消息中心进行消息推送,需要考虑飞书侧对某个机器人消息推送做限流的问题,一旦使用了某个业务系统的机器人进行批量或并发推送,可能会导致业务系统业务消息推送(限流)异常)。
优化思路:
结果:
4.1 学会聆听
当完成整个消息中心的设计后,要听取他人意见,学会聆听,因为完成这件事其实并不难。另外在网上也可以找到很多开源产品可借鉴,但是完全拿来主义不一定适合我们自己业务。所以需要跟PM、同事讨论,听取意见。再者消息中心未来是需要长期与其它部门及产品协调沟通的,如果一开始在做的时候就没有与其他人去交流或技术方案讨论,那么后期由于业务拓展,很有可能整体架构很容易被推翻重构。
4.2 结语
*文/Leezr
关注得物技术,每周一、三、五更新技术干货
要是觉得文章对你有帮助的话,欢迎评论转发点赞~
未经得物技术许可严禁转载,否则依法追究法律责任.
“
扫码添加小助手微信
如有任何疑问,或想要了解更多技术资讯,请添加小助手微信: