之家短信平台高可用探索之路

在信息化时代，短信作为最基本的通信方式，在各种业务中都扮演着重要角色。但是，随着业务量的增长和用户对服务质量要求的提高，短信平台的高可用性成为了我们面临的一个重大挑战。接下来的分享，将带领大家走进我们在寻找短信平台高可用解决方案的探索之路。

之家短信平台是一个提供企业级短信服务的全面解决方案。目前支持短信发送、彩信发送、提供一套完整安全策略的验证码发送服务，该平台以高可用性、稳定性和安全性为首要目标，为之家各业务线提供可靠的短信发送和接收功能。

之家短信平台的主要特点包括：

• 高可用性：通过冗余硬件、软件和网络连接来保证服务的持续可用。系统采用分布式架构设计，实现了高并发、快速响应的通信能力。

• 限频限流：使用先进的算法进行流量控制，确保系统在面临大量请求时不会过载，保障短信服务质量。

• 故障自动切换：一旦检测到系统出现故障，平台会自动将流量切换到异地健康的服务集群上，从而减少对业务的影响。

• 故障监控报警：平台设有完善的监控系统，可以实时监测系统状态，并在发现异常时立即发出告警。

短信服务1.0架构图-01

随着时间的推移，当初.Net版本程序维护成本逐渐增加，以及运营人员对管理功能的强烈需求，就产生的之家短信的2.0升级。

2.0升级的主要解决的问题：

• 使用Java语言将原有功能迁移到Java平台上，便于日后维护。
• 管理端页面重构，增加日常查询统计
• 数据脱敏等一系列迭代升级。

 随着业务的发展和对大型活动的支持，面对瞬时大量短信发送场景（百万QPS发送请求），以往的单一架构支撑起来捉襟见肘，于是开启了短信平台的高可用探索实践之路。

分析原有短信架构，找出性能瓶颈

• 手机号验证、路由分配、策略等配置数据直接读库。
• 接口接收到发送短信请求后同步调用三方短信通道商，如遇网络卡顿或三方服务不稳定就会出现接口响应超时。
• 信息同步保存到数据库，如果遇到网络波动或数据库繁忙的情况下会出现接口响应卡顿。
• 短信发送是异步请求，并非同步发送，流程如下图：

短信下发流程-02

重构思路：基于上述3个问题点和1个短信发送特性，将API接入校验、调用三方、保存数据库三部分进行解耦，每部分是一个服务，通过kafka进行削峰解耦，解耦后的程序为无状态服务，理论上可以做到无限横向扩展。

三个服务功能职责划分

Api服务：

• 负责基本数据校验，包括手机号合法性、黑白名单、路由通道等，所涉及到的配置信息全部从缓存中读取，不再依赖数据库，合规数据加密后发送到kafka。
•  接收状态报告回执信息
• 接收用户回复的短信内容

分发服务：负责消费 “api服务” 产生的合规数据，将调用三方发送结果加密后发送到kafka。

落库服务：负责消费 “分发服务” 产生的数据，将发送结果保存到数据库。

短信下发-状态报告-上行短信 全流程图-03

按照上述思路3.0很快落地了，运行速度相比2.0的时候迈进了一大步，可以支撑高达百万QPS每秒，拆分开的三个服务每个服务是高可用的，每个服务依赖的中间件是高可用的，看起来万无一失了，但是存在一个薄弱环节，如果三个服务所在的机房出现了故障，例如机房网线断了，那么整个短信平台就会失联。

经过调研，4层AnyCast是一种网络寻址和路由方法，它可以将数据流重定向到最近、最佳或某特定的节点。因此，当A机房出现故障时，系统会凭借4层AnyCast的特性，自动选择并切换到功能正常的B机房，从而故障自动转移，且整个过程是自动切换，没有人工依赖大大缩短了故障响应时间。

于是将完整的短信服务在A机房和B机房分别部署一份，AB两个机房所涉及到的中间件完全独立。但是存在一个问题，数据库数据不能分开，跟DBA商讨后决定，数据层面采用TiDB互为主从的方式实现，当A机房失联后无需DBA干预，数据可以实时写入B机房，AB机房数据实时同步。

架构优点：避免因网络故障导致A机房整体失联。

架构缺点：AB机房平时只有一个对外提供服务，另外一个处于备用状态，造成了资源的浪费，之所以不能同时对外提供服务的原因是，底层TiDB互为主从的实现方式，如果AB机房同时做读写操作会影响两个数据库的同步机制。

 短信服务4.0架构图-04

限频限流操作界面-06

状态报告主要作用是能够了解短信送达情况和月底结算，由于状态报告涉及到网络调用和更新操作，大批量短信发送场景下，对于网络和数据库都有一定压力都非常大，所以在活动当天选择服务降级，等活动结束后选择业务量较少的时间点回推短信状态报告。

结合以上五点优化，短信平台经历了5届之车之家818全球购车节的检验，峰值可以满足百万QPS无延迟下发场景需求。

架构再完美，也避免不了会出现故障，那么第一时间发出告警信息就显得弥足珍贵，短信本身作为一个消息发送方，那如何保证他本身出现问题还能发出消息告警呢？大家想象一下以下场景

• 短信服务本身异常了
• 短信服务依赖的中间件故障了，Redis、TiDB、kafka
• 短信所处的1个机房故障了
• 短信所处的2个机房都故障了
• 短信下发通道商正常，但通道商调用三大运营商有问题
• 短信下发通道商失败，网络超时、DNS解析失败等错误
• 短信回调之家业务方故障了，502、404、500等错误
• 上行短信通道商配置错误导致数据回传有问题
• 状态报告非约定状态码
• 配置文件修改错误导致短信下发失败

等等

以上部分故障可以通过短信系统自身发出报警，但是有一些故障需要依赖三方才能够实现消息的传递。短信平台结合鹰眼日志、真机短信发送与接收、运营商实时监控反馈、通道商客服24小时值守等外部系统进行监察，消息接收方式包括短信、钉钉、微信、电话，设置多个报警接收人，避免单一报警系统出现问题，导致报警内容无法触达短信平台接收人员。

此外，我们特设每日成功率告警和主力通道无短信提交告警等安全告警机制，使我们可以快速发现并应对各类风险，保证短信从发送到接收的全过程都在我们的监控范围内。短信平台拥有健全的短信故障监控体系，我们以全面且精细化的监察机制，确保短信服务的稳定运行。体系涵盖短信下发、状态报告回执、上行短信异常、中间件报错等8大类17个重要的监控细节，可以及时检测并处理可能出现的问题。

短信故障监控图-07

短信平台的高可用性涉及多个方面，包括异地多活架构、负载均衡技术、限频限流、故障自动恢复机制、数据冗余和备份等策略，可以有效提升系统的稳定性和可靠性，确保信息的及时传递和保障大型活动的顺利进行。在故障发生时和发生后有相应监控报警实时跟进，增加日常巡检机制防范风险发生，只有持续探索和优化，不断提升系统的稳定性和可靠性，才能在竞争激烈的市场中脱颖而出，为用户提供卓越的体验。