效率消息中心从0-1搭建与思考

消息中心是一个集中管理、分发通知和提醒的平台，可以让用户或系统消息更方便、快捷的触达给指定用户或者系统。并且可以帮助用户或系统更好地管理消息的生命周期，屏蔽不同消息渠道差异与技术差异，从而提升效率与体验，降低维护成本。,,应用架构这里就不展示了，因为是基于技术部中间件团队java应用（nvwa）工厂生成标准COLA的多模块项目模板应用。,,,消息通知的流程设计，在各个业务线中通过消息中心提供的接口方法，将不同场景下的消息内容提交到消息中心，消息中心进行统一维护管理，并根据消息的来源和去向，适配相应的推送逻辑：,,在整个流程中涉及到的模块比较多，状态的流转也很复杂，但是通过消息中心进行统一标准管理和流入流出的跟踪，也可以提供清晰的生命周期监控和维护。大部分的消息通知机制都可以容忍一定的延迟性，所以消息中心完全可以解耦各个流程，引入MQ队列或者异步机制，业务方只需要将请求发送到消息中心，之后由消息中心统一调度和管理即可。,,,飞书侧机器人回调地址只能填写一个，历史的应用已经对接过飞书平台进行发消息，对于系统增量消息想接入消息中心应该怎么解决，在不影响老系统增量消息接入消息中心的又不影响历史消息回调的情况下，消息中心采用了转发的方式去兼容历史的消息回调。下面是飞书回调流程：,,动态消息内容 和 静态消息内容 指的是消息（如邮件、短信、通知等）中的内容。,静态消息内容是指在发送消息时事先准备好的、不会发生变化的消息内容，比如营销邮件、欢迎短信、通知公告等。这些内容在每次发送时都是一样的，不会根据接收者的情况、时间等因素而发生变化。,而动态消息内容则会根据接收者的情况、时间等因素而实时生成，以提供更好的个性化服务。动态消息内容的例子包括订单确认邮件、账户余额提醒短信、预约成功通知等。这些消息内容需要根据接收者的订单信息、账户信息、预约信息等动态生成。,总之，静态消息内容是在发送消息前准备好的、不会发生变化的消息内容，而动态消息内容是根据接收者的情况、时间等因素而实时生成的消息内容，以提供更好的个性化服务。,,,目前跟业务系统对接的消息内容，99%都属于静态消息内容，相对于那种较复杂的动态消息内容（图一折线图，图二动态表单等动态数据）去做动态数据渲染。消息中心对于动态内容消息渲染，解决方案是在模板功能里面抽象了一层消息内容解析引擎，模板引擎采用的是Apache 软件基金会下的一个开源 Java 模板引擎框架（VelocityEngine）该引擎用于生成 HTML、XML、JSON、CSV 等文件格式的文本内容。功能非常强大，感兴趣的同学可以去了解一下。下面拿个简单动态消息模板举例：,a. API接口组装消息体,b. 使用VelocityEngine语法解析,,c. 动态渲染输出,,业务场景：在一个阳光明媚的早上，业务同学用潮人研习社的机器人给公司用户推送了chatgpt的学习先关的内容，消息推送触达竟然花费了一个1多小时。,,问题分析：没办法，做为技术boy，只能埋头去寻找根因，主要有以下几点,,优化思路：,针对上面2个问题的具体分析，主要是对问题2做了对应的优化，优化思路主要是分治思想，针对大批量推送消息场景对用户进行分组，充分利用操作系统的多核优势。把分组的任务提交到异步消息队列，通过自产自消的方式来提升消息触达效率。,结果：,基于上面的思路去优化并测试，效果是异常的明显，之前推送消息需花费1个多小时，现在10分钟（这里的触达时效瓶颈主要是飞书侧，飞书对消息推送接口做了限流（1s并发只能50且1min上限1000））就可以全部触达了。,当完成整个消息中心的设计后，要听取他人意见，学会聆听，因为完成这件事其实并不难。另外在网上也可以找到很多开源产品可借鉴，但是完全拿来主义不一定适合我们自己业务。所以需要跟PM、同事讨论，听取意见。再者消息中心未来是需要长期与其它部门及产品协调沟通的，如果一开始在做的时候就没有与其他人去交流或技术方案讨论，那么后期由于业务拓展，很有可能整体架构很容易被推翻重构。,对于消息中心来说，根据实际业务线的丰富度，相应应用场景也会更加复杂，所以我们在设计消息的落地场景时，对于不同场景的适用性挑战也会增大。但殊途同归，基于降本增效去做更多思考，总归会让价值落地。