消息中台系统需求设计

随着业务的增长，我们发现将消息模板和第三方推送信息存储在代码配置文件中变得越来越繁琐且难以管理。因此，我们计划开发一个系统，将各种推送消息聚合到一个前端界面上，而事务和推送渠道规则则由产品配置决定。

另外，为了发展成为一个SaaS产品，我们需要支持其他业务平台的接入。这就需要我们将账户体系和消息推送系统打通，这对于建筑设计领域的平台来说尤为重要。因此，我们计划提供一个第三方开放平台，以便其他平台能够接入我们的系统。

一、需求分析

为了支持不同的业务平台，并帮助它们完成基础消息的闭环流程，我们计划开发一个消息系统。该系统将支持产品配置业务类消息模板以及相应媒介，并支持运营配置营销类消息模板以及相应媒介。这样，不同的业务系统就可以使用我们的消息系统，来发送不同类型的消息。

此外，我们还计划对接各种消息触达媒介，并支持多类事件调用。这意味着，我们的系统将能够汇聚各种类型的消息，无论是来自于业务系统还是营销系统，并通过多种渠道将它们推送给用户。

1、好处

• 我们意识到将所有账号密码都存储在代码和配置文件中存在着较高的风险，因为一旦出现密码泄露等情况，我们将不得不重新上线。为了解决这个问题，我们计划将所有的账号密码存储在安全的数据库中，通过加密等措施来保护数据的安全。
• 为了确保用户在单一消息通道出现异常后，仍能正常地接收到消息，我们的消息中台将支持通道切换策略。这样，当一个通道出现问题时，我们的系统将自动切换到另一个可用的通道，并确保消息能够被及时地发送出去。
• 为了提高消息发送的吞吐量和并发量，我们将使用异步发送的机制。这样，当用户发送消息时，我们的系统将立即将消息加入到异步消息队列中，并由消息中台进行处理和发送。这将确保消息能够快速地触达到用户，同时还可以避免在发送消息时对系统性能造成影响。
• 我们认识到消息数据的重要性，并计划将其沉淀下来，以便后期进行数据分析。具体来说，我们将记录每一条消息的发送时间、接收时间、发送状态、接收状态等信息，并将这些数据存储在消息数据仓库中。这样，我们就可以利用这些数据来进行消息推送效果的评估和优化。

2、价值

• 我们的消息中台可以最大程度地完成消息分发系统与业务系统的解耦，这将大大减少开发资源的浪费和重复造轮子的问题。我们将提供各种消息模板和通道接口，这样开发人员就可以轻松地将消息中台集成到他们的业务系统中。
• 我们的消息中台具备极强的横向扩展属性。我们将支持各种消息媒介接口，建立消息模板体系，以及提供低代码工作流业务赋能。这将使我们的消息中台能够为各个行业和业务提供支持，并具备极高的拓展性。
• 我们的消息中台对于各种业态有极强的适应性。这得益于我们仅仅承担了业务当中消息分发的能力。我们的系统将支持各种消息类型和通道类型，并将根据不同的业务需求进行自定义配置。这将使我们的消息中台能够适应各种不同的业务场景和需求。

二、消息推送媒介的选择

1、短信

短信服务已成为目前最主流的消息推送渠道之一。由于每个人几乎都拥有一部手机，因此短信的触达率也是最高的。然而，由于主流短信服务商的收费标准通常在每条0.05元左右，频繁的推送可能会产生不小的成本，也可能给用户带来短信轰炸的感觉。因此，通常只将短信用于验证码、系统通知、营销短信等业务，以平衡成本和用户体验。

2、邮件

邮件服务是一种常见的消息推送渠道，与短信不同的是，邮件可以免费发送，触达率较低，但对用户的干扰较小，因此对于营销类业务比较适合。同时，邮件还可以作为验证入口之一，提高验证的灵活性和多样性。

3、微信

微信推送是目前除了短信推送触达率最高的渠道之一，覆盖了大量的用户群体，对于业务消息和与用户产生互动的推送非常适合。 另外，微信推送包括小程序和公众号推送，基本上不需要成本，且具备高度的互动性，可以帮助企业与用户建立良好的互动关系。虽然在推送内容方面存在一些限制，但这也可以帮助企业更好地把握推送内容的质量和效果。

三、消息分发流程

1、发送方

消息内容（消息类型、消息模板）、消息对象（系统范围内的人员）

2、媒介方

消息策略（触达媒介选择：短信、邮件、站内信、微信等 ，消息任务时限设置，消息补发策略）、消息管理（增删查改）

3、触达方

消息回执（已读未读、数据反馈回流）

四、业务流程

1、C端实时接口业务流程

2、后台消息调度

五、架构

通过消息中台统一各业务发送入口，协调各消息供应商服务，降低业务方调用成本，简化使用方调用方式，统一保障系统稳定性。

1、业务架构

2、模块全景图

3、用例描述

六、详细设计

1、消息服务

承接C端实时请求，如验证码、警报短信，提供所有消息发送能力。

• 支持网关流量控制，保障接口服务稳定。
• 保证消息及时触达用户。RPC接到消息后优先直接发送，减少延迟。为避免离线消息堆积影响及时消息延迟，需要将离线和及时消息分开解耦。
• 根据机器负载支持并发线程数配置，超出负载则通过mq 削峰。
• 支持消息状态跟踪

2、调度服务

实现延迟消息和周期消息的统一调度。

• 支持延迟消息及周期消息发送。支持目标存储。支持消息状态跟踪。
• 单机调度。
• 支持消息重试及幂等消费。

3、后台管理

实现消息中台、调度、监控等基础数据维护。包括消息模块管理、签名管理、供应商管理、业务方管理、消息调度信息配置等等。

• 业务方接入管理
• 供应商管理
• 签名管理
• 模板管理
• 任务管理
• 消息状态管理

4、消息消费

消费MQ的消息并调用统一分发逻辑，实现对不同供应商的消息支持。

5、业务指标监控

• APP每天调用接口总次数限制
• 手机号每天发送次数限制
• QPS流控
• 并发流控

七、设计原则

1. 解耦：最大限度地完成消息分发系统与业务系统的解耦，避免重复开发，降低开发成本，提高系统的可维护性。
2. 扩展性：消息中台应该支持不同的消息媒介接口，并建立消息模板体系，具备极强的横向扩展属性。同时，消息中台也应该支持低代码工作流业务，为后续的开放平台提供支持。
3. 稳定性：消息中台应该支持单一消息通道出现异常后，自动切换到备用通道，确保消息能够及时触达用户，同时保证系统的高可用性和稳定性。
4. 异步化：消息中台应该使用异步发送机制，提高吞吐量和并发量，确保消息能够及时触达到用户。
5. 数据沉淀：消息中台应该对消息数据进行沉淀，方便后期数据分析和业务调优。同时，消息中台也应该支持对消息数据的搜索和查询，以便快速定位和解决问题。

综上所述，这些设计原则可以帮助消息中台更好地支持不同业务系统的消息分发需求，并提高系统的可维护性和稳定性，同时也为后续的业务发展和数据分析提供了支持。