在常规的分布式架构下，「消息中心」的服务里通常会集成「短信」的渠道，作为信息触达的重要手段，其他常用的手段还包括：「某微」、「某钉」、「邮件」等方式；
对于《消息中心》的设计和实现来说，在前面已经详细的总结过，本文重点来聊聊消息中心的短信渠道的方式；
短信在实现的逻辑上，也遵循消息中心的基础设计，即消息生产之后，通过消息中心进行投递和消费，属于典型的生产消费模型；
在大部分的系统中，短信功能的实现都依赖第三方的短信推送，之前总结过《三方对接》的经验，这里不再赘述；
但是与常规第三方对接不同的是，短信的渠道通常会对接多个，从而应对各种消息投递的场景，比如常见的「验证码」场景，「通知提醒」场景，「营销推广」场景；
这里需要考虑的核心因素有好几个，比如成本问题，短信平台的稳定性，时效性，触达率，并发能力，需要进行不同场景的综合考量；
验证码：该场景通常是用户和产品的关键交互环节，十分依赖短信的时效性和稳定性，如果出问题直接影响用户体验；
通知提醒：该场景同样与业务联系密切，但是相对来说对短信触达的时效性依赖并不高，只要在一定的时间范围内最终触达用户即可；
营销推广：该场景的数据量比较大，并且从实际效果来看，具有很大的不确定性，会对短信渠道的成本和并发能力重点考量；
从整体上来看短信的实现流程，可以分为三段：「1」短信需求的业务场景，「2」消息中心的短信集成能力，「3」对接的第三方短信渠道；
需求场景：在产品体系中，需要用到短信的场景很多，不过最主要的还是对用户方的信息触达，比如身份验证，通知，营销等，其次则是对内的重要消息通知；
消息中心：提供消息发送的统一接口方法，不同业务场景下的消息提交到消息中心，进行统一维护管理，并根据消息的来源和去向，适配相应的推送逻辑，短信只是作为其中的一种方式；
渠道对接：根据具体的需求场景来定，如果只有验证码的对接需求，可以只集成一个渠道，或者从成本方面统筹考虑，对接多个第三方短信渠道，建议设计时考虑一定的可扩展；
单从短信这种方式的管理来看，逻辑复杂度并不算很高，但是很依赖细节的处理，很多不注意的细微点都可能导致推送失败的情况；
实际在整个逻辑中，除了「验证码」功能有时效性依赖之外，其他场景的短信触达都可以选择「MQ队列」进行解耦，在消息中心的设计上，也具备很高的流程复用性，图中只是重点描述短信场景；
对于「短信」功能中的「验证码」场景来说，个人感觉在常规的应用中是最复杂的，这可能会涉及到「账户」和相关「业务」的集成问题；
【验证码获取】
这个流程相对来说路径还比较简短，只要完成手机号的校验后，按照短信推送逻辑正常执行即可；
这里需要说明的是，为了确保系统的安全性，通常会设定验证码的时效性，并且只能使用一次，但是偶尔可能因为延时问题，引起用户多次申请验证码，基于缓存可以很好的管理这种场景的数据结构；
【验证码消费】
验证码的使用是非常简单的，现在很多产品在设计上，都弱化了登录和注册的概念，只要通过验证码机制，会默认的新建帐户和执行相关业务流程；
无论是何种业务场景下的「验证码」依赖，在处理流程时都要先校验其「验证码」的正确与否，才能判断流程是否向下执行，在部分敏感的场景中，还会限制验证码的错误次数，防止出现账户安全问题；
无论是「通知提醒」还是「营销推广」，其本质上是追求信息的最终触达即可，大部分短信运营商都可以提供这种能力，只是系统内部的处理方式有很大差异；
在部分业务流程中，需要向用户投递短信消息，在营销推广的需求中，更多的是批量发送短信，部分需求其内部逻辑上，还可能存在一个转化率统计的问题，需要监控相关短信的交互状态；
由于短信是集成在消息中心的服务中，其相关的数据结构模型都是复用消息管理的，具体细节描述，参考《消息中心》的内容即可，此处不赘述；
从技术角度来看的话，涉及经典的生产消费模型，第三方平台对接，任务和状态机管理等，消息中心作为分布式架构的基础服务，在设计上还要考虑一定的复用性。
京公网安备 11010802035086号