1、背景 平台内的原消息通知服务有以下 2 个弊端：第一，配置非常麻烦，需要配置五六张 MySql 表，并且关系 错综复杂；第二，设计思路及架构老旧，维护费劲，日志信息也比较欠缺，出错之后不易定位问题。为了解决以 上问题，决定重新开发一套简单高效且可扩展的消息通知架构。 2、设计 消息通知的本质是：把消息组装好，通过一定的发送渠道，发送到指定的终端，并记录发送日志。 基于此抽象出以下模型：消息模板、数据 Provider、发送器、全局变量、发送日志、布局页。采用订阅 RabbitMQ 消息实现逻辑解耦，以 MongoDB 作为存储。每条消息包含一个模板编号，根据编号得到消息的各组件：模板内容、 模板数据、发送通道、发送人、抄送人等。在收到消息后，需要对其进行一系列的合规校验，如模板是否存在、收 件人是否存在及合法、附件大小是否超限等，这里采用了责任链模式实现。消息渲染使用 RazorEngine 组件，获 取发送器对象采用了简单工厂模式 + 反射 + 缓存 实现(目前支持：邮件、短信、极光推送、微信、Webhook、 站内消息，并易于扩展)，具体发送器依赖一个消息对象，而整个构建消息对象的过程采用了 建造者模式 实现。 3、遇到的挑战 问题描述：有个租户需要在每周四下午 5 点，给指定用户发送付款通知邮件，用户的数量大约 1 万 +，这段时间集中式的向 MQ 推送消息，导致 MQ 有大量消息堆积，而且影响到了其他场景下的消息发送，最要命 的是同一条消息会推送多次，这就导致很多客户收到了很多重复的邮件，遭到客户投诉。解决方案：起初采用增加 服务节点数量，来增加消费端能力，但同一消息推送多次未能解决（最后查到是阿里云 RabbitMQ 组件那段时间有 问题），后面将这一业务场景单独调整为引用 DLL 库，直接调用发送方法，构造消息对象采用 享元模式（消息 对象池思想）即保证了性能，也解决了以上问题。 4、项目业绩 通过重构之后新的消息通知架构，在消息配置及维护方面，效率提高了 70%，新租户的消息通知需 求上线时间比原来缩短了 50%。目前公司 80%场景已改造完毕，服务运行一年多时间，经过了几次迭代打磨，功 能变得越来越强大，能满足客户各种刁钻的需求，并且多次得到老板和客户的好评。