以下内容，如需要做实际操作体验，可以移驾 https://www.firefac.com
智能设备普及的今天，互联网应用的复杂性越来越高。对于通知到用户的消息也面临多种渠道，常见的有短信，小程序订阅消息，公众号模版消息，应用站内信，应用推送，IM即时消息等。现在大多数中小企业面对这种情况也是措手不及，没有一定的规划，只能兵来将挡水来土掩。到最后代码乱七八糟，到处都是补丁，为了业务需求而放弃了代码的扩展性和代码之美。
实战需求分析
应用的迭代过程大致可以分为几个阶段：启动、扩展、稳定。
启动阶段：一般只需要基础的通知功能，能够将流程状态变化通知到用户即可。由于启动的时候，大多数企业使用小程序作为第一版应用载体，所以主要用到的渠道有：
小程序订阅消息：曝光触达率较低，不需要关注公众号，需要用户对消息进行订阅才能收到。
公众号推送消息：曝光触达率比较高，不过需要用户关注公众号，有一定门槛。
扩展阶段：也是消息模块快速扩展的阶段，这个阶段运营会有各种需求，更注重到消息的触达和多渠道推送，毕竟很多渠道的消息触达率不是很高。这个阶段主要用到的有
小程序订阅消息：曝光触达率较低，不需要关注公众号，需要用户对消息进行订阅才能收到。
公众号推送消息：曝光触达率比较高，不过需要用户关注公众号，有一定门槛。
站内信：曝光率非常低，仅作为各种消息的站内备份。如果错过其他消息后，这里可以查询使用。
短信：曝光率高，短信内容需要运营商进行审核，如果营销短信，很多也会被用户手机拉黑。
邮件：邮件的使用国外的软件比较多，国内的话，2B的应用会更多一些，使用起来感觉会更正式。
稳定阶段：稳定阶段是在扩展阶段以后，这个时候的特点是，保持了扩展阶段的消息发送模块，也更加会完善扩展阶段因为时间关系未完善的模块。这个阶段除了上述内容外，还会有几个模块
APP消息推送：扩展阶段完成后，用户的增长等会达到一定水平，这个时候就需要把用户沉淀下来，所以APP是必不可少的。那推送肯定也是非常重要的一环。
IM即时消息：对于带有社交方面属性的应用，当用户到达一定基础以后，应用内的即时通讯是必不可免的。这个时候消息通知也需要对接到即时消息。
设计概述
经过如上需求分析，大概可以总结归纳为如下描述：
场景需求：需要支持多种场景，每种场景需要在代码中埋点。并且对这些场景有分类管理
模版管理：针对不同的消息渠道配置模版对应关系，不同的场景下如果存在参数的情况，在这里做对应
消息配置管理：对于不同的场景和发送的消息模版的管理，管理主要是该场景下消息的发送渠道和针对用户群体
消息管理：主要是消息的流水记录，各个渠道各个消息的发送情况及状态，是否需要补偿发送等内容。
发送方式：单播、多播、广播。
营销信息：手动单条消息的发送，可以支持单播、多播和广播。
根据上述的描述，设计模型结构如下：
详细设计逻辑
场景管理
场景
场景内容针对不同的业务场景来进行分类，这块内容是比较定制化的。电商的场景主要会有订单消息、积分消息、会员消息、促销消息等内容。社交场景主要会有帖子内容发布、操作（点赞、评论、转发等）。任务场景主要是任务的报名、到时提醒、完成等逻辑。
在场景管理的时候，分类是一个很好的方式，比如如下的分类方式
订单：下单、支付、取消、配送、重要物流节点、退换货等。
社交：关注消息、帖子评论、帖子点赞、用户关注等。
任务：新任务提醒、报名状态、任务开始结束等。
参数
不同的场景下，还会对应到不同的参数，这些参数都需要在代码层面给出定义和关联。比如订单下单会有订单编号、价格、订单商品、下单时间等字段；支付的时候还会涉及到支付时间、支付状态等；售后等逻辑还包含售后商品，售后审核状态等参数。
模版管理
不同的场景下面，不同渠道会存在不同的实现方式，可以抽象成模版的方式配置。模版方式既是预先在渠道平台配置相应的模版和参数预配置。比如小程序订阅消息模版、公众号消息模版、短信模版等。在做消息订阅的时候，因为小程序的现实，一个事件最多能订阅三条消息，所以模版消息需要增加一个不同按钮的分组配置。
模版的属性一般会有：模版id，模版参数对应关系（字段映射、按照顺序映射），跳转地址。
模版的配置方式参考如下方式，对应到场景与参数。如下是针对小程序订阅消息的配置：
小程序订阅消息的配置
模版消息分组
消息配置管理
消息配置就比较简单，主要是对所有模版和渠道的一个统筹管理。主要配置指定场景的对应渠道的状态是否开启。比如下单场景下只需要发送订阅消息，或者公众号模版消息即可触达；而促销活动场景下，发布的活动为了增加触达率，则需要对多个渠道进行推送，订阅消息、短信息、APP推送等。
消息配置管理的另一个作用，就是可以手动发起消息推送，定时发送内容到多渠道。
消息管理
消息的发送记录分为单播记录、多播记录与广播记录。
单播：针对单人的消息推送
多播：针对多个有限用户的消息推送
广播：针对平台所有人的消息推送
消息管理是对已经发送的消息进行记录，管理，补偿的模块。记录既是记录下所有场景下针对不同用户的推送数据，用于状态记录、追溯等。所有的消息都需要记录下来，这样的好处有两个：1 可以对特定消息进行触达率统计；2 根据消息异常情况，可以进行补偿重新发送。到后期如果消息量增加的情况下，可以对历史数据进行备份按年份或月份分表存储，或者将这些数据从mysql移植到更适合大数据的mangoDB、ES或者TIDB中。
