简介面向移动通信网络工程师、运维人员及短消息业务学习者这份技术课件围绕短消息中心业务功能系统展开系统梳理短消息从提交、转发到状态反馈的完整链路帮助读者理解短信中心核心职责与各功能触发条件适合通信培训或自学入门。资源共1个文件为PPTX演示文稿体积444KB内容编排完整已有77人学习下载。课件对短消息中心核心业务功能逐项展开介绍包含提交验证、转发控制、优先级处理、有效期管理、重发机制、状态报告、用户鉴权、汉字传输、虚拟中心、存储转发、数据报、交互三种调度模式及节日负荷保护等模块并介绍省内网络短消息中心间协同调度思路。读者通读后可建立起从概念到实现的完整认知为后续网络规划、参数配置和问题排障提供参考。1. 短消息中心业务功能一份PPT背后的核心网元与短信全链路「短消息中心业务功能」这份PPT我接过好几版有给业务部门讲增值服务的有给新同事做网元科普的还有给客户汇报系统割接方案的。名字都叫“试谈”可读完之后你要去接SMPP网关、排查状态报告丢失照样无从下手。短信不是A手机到B手机直连中间有一台叫短消息中心SMSC的核心网元做存储转发所有业务功能都绕着这个「先收下、再投递、失败了重试、还要给回执」的流程转。这篇按一线集成视角把PPT上的功能框拆成协议、参数、队列和坑新手能照着排查熟手能直接拿去对参数。2. SMSC业务功能全景把「试谈」翻译成能落地的功能清单一份讲「业务功能」的PPT最常见的毛病是只画三层手机终端、交换网、短信中心然后列出“支持短信收发、支持状态报告、支持群发”就完了。可工程上真正要确认的是这些功能背后的处理流程和边界条件。下面按我接项目时的拆法把PPT最容易含糊的两块——消息流转和消息状态——铺开说。2.1 短信从发起到送达要过几道关MO/MT与存储转发短消息中心的业务功能用一句话概括就是从发起方把短信收下来替它存着再想办法送到接收方手里最后如实告诉发起方“送没送到”。这句话拆开就是三个核心子功能。第一是MOMobile Originated移动台发起。手机用户按了发送键短信先到基站子系统再经MSC移动交换中心通过MAP信令的forwardShortMessage请求送到SMSC。此时SMSC只做两件事一是验身份确认这个号码有权限发短信二是落存储把消息内容和用户信息一起写进消息队列。这一步的关键指标是收容能力也就是短时间冲进来大量短信时系统能不能全收下并落盘而不是先拒绝再让用户重发。第二是存储转发。PPT上这四个字看着轻巧实际是整个SMSC的命门。短信进入队列后SMSC并不保证马上能投出去接收方可能关机、不在服务区、开了飞行模式甚至号码已经注销。SMSC的策略是先把消息存起来然后按路由分析找到接收方当前所属的MSC再发起MTMobile Terminated移动台终止流程。如果第一次MT失败就进入重试队列按定时器退避重试直到超过有效期才把消息作废。第三是状态报告Status Report也叫DLRDelivery Report。发起方想知道短信有没有送到SMSC会在投递成功或最终失败后按原路返回一条回执。这个回执在内部流程里是独立的一条消息它不占用户的短信配额但要占系统处理能力。很多项目验收时只看收发成功率不看状态报告成功率结果上线后SP客户全部投诉收不到回执——这就是PPT没讲透的地方。所以我在对接一个新SMSC系统时会让对方先回答四个问题消息在队列里是怎么分优先级排队的MT失败后按什么时间间隔重试有效期到了之后消息是删除还是退回给发起方状态报告是实时生成还是定时批量生成。这四个问题全都答得上来的才是真能落地的业务功能。2.2 容易被PPT一笔带过的功能才是工程重点重试、优先级与消息过滤业务功能清单里还有几项PPT常拿一句话带过但实际调参时最花时间。重试策略。初看只是“失败后过几分钟再发一次”但重试间隔的取值直接影响系统容量。设想一个场景凌晨某区域MSC割接十分钟内几万条短信投递失败。如果SMSC全部立即重试所有失败消息会在同一秒内打回MSC形成重试风暴把本来还健康的设备拖垮。所以重试必须做指数退避或分档退避我一般会按T1/T2/T3/T4分四档T1为1分钟T2为10分钟T3为30分钟T4为60分钟最多重试四次。这个值不是拍脑袋是根据MSC恢复正常所需的典型时长倒推的。优先级处理。短消息中心队列里不会只有一种消息普通用户短信、银行验证码、灾害预警、SP营销短信重要程度完全不同。SMSC一般支持按priority_flag分0到3四档高优先级消息在队列头部和重试顺序上都有优先权。这里有个坑营销短信是批量提交的如果不限制配额高峰期会占掉大量队列资源把验证码这类高价值消息挤到后面。所以除了优先级标志位还得配合每秒提交配额和单SP并发连接数一起限制。消息过滤与黑名单。这一块和业务功能有关系但通常不由SMSC核心做而是前置的业务网关做。SMSC层面至少要支持的基础过滤包括号段黑名单、内容关键字拦截、同一发送方频率限制如每分钟最高条数和非法号码格式拒绝。核心原则是过滤要前置不要等消息入了存储队列再拦截白白占用存储和重试资源。一句话总结这章看一份SMSC业务功能PPT先看它怎么处理“失败”而不是看它怎么描述“成功”。失败路径设计得好不好决定了系统在真实网络环境里是稳定运行还是天天告警。3. 把PPT功能映射到接口协议SMPP/CMPP/MAP各自管什么PPT里的业务功能最终都要落到接口协议上。短消息中心同时对着两边对内朝着运营商网络走的是七号信令的MAP协议对外朝着SP、企业网关、银行系统走的是SMPP、CMPP这类TCP/IP之上的协议。两边协议语言不同功能映射的时候很容易错位。3.1 协议栈选型什么场景用SMPP什么场景用CMPP和MAPMAPMobile Application Part是SMSC和MSC/HLR之间的信令协议。手机用户发的短信经过MSC转成MAP消息到达SMSCSMSC往接收方投递也是通过MAP把消息发回给接收方所在的MSC。这部分在运维侧通常是透明的SMSC设备厂商已经封装好集成方只需要关注SIGTRAN链路状态和GT寻址配置。但有一点要清楚MAP不支持业务侧直接对接你不可能让一个银行系统通过MAP发短信。对外接口才是集成方的主战场。SMPPShort Message Peer to Peer是最通用的协议面向短信中心与外部消息实体之间的交互国内外的SP、云短信平台基本都支持。SMPP定义了bind、submit_sm、deliver_sm、query_sm等命令字状态报告通过deliver_sm承载指令清晰、扩展性好适合做新系统对接。CMPP是中国移动定义的短消息网关协议实际使用中CMPP3.0最普遍。如果你要接运营商行业网关下发短信大概率要面对CMPP。CMPP和SMPP功能上对等都有消息提交、状态报告、话单回执但字段定义和交互流程不兼容。联通侧常见SGIP电信侧常见SMGP这些都和CMPP类似核心思路一致只是码头不同。选型上我的经验是如果是自建SMSC对外提供服务优先选SMPP因为客户端生态最成熟、开源工具多、排查方便如果业务必须直连运营商的行业网关那网关定什么协议你就得接什么协议没得挑。工程上常见做法是在SMSC外面加一层协议适配网关对外同时开放SMPP和CMPP对内统一转成SMPP或内部私有协议这样不同客户各接各的SMSC核心不用跟着改。3.2 从PPT章节到功能-接口-参数映射表拿到PPT里列的业务功能我习惯先画一张映射表把每个业务功能落到具体协议命令和需要核实的参数上。这张表同时也是后续写测试用例的依据。PPT上的功能内部流程协议/接口关键参数验收时看什么点对点短信收发MO收容 MT投递MAP forwardShortMessage外部实体走SMPP submit_smregistered_delivery设为1才返回状态报告起止号码、消息内容、时间戳完整状态报告MT结果回填SMPP deliver_smesm_class置0x04message_state字段1为DELIVRDSP侧能按msg_id关联到原短信群发/批量发送队列批量投递SMPP submit_sm批量提交或sub_multi连接并发数、每秒提交上限大批量时不串号、不重复投递定时短信队列存储到时间点再投submit_sm的schedule_delivery_time时区设置要统一定时消息到期准点出队优先级保障队列内部排序submit_sm的priority_flag0到3档映射关系高峰期高优先级先出队黑名单拦截入队前过滤外部接口前置或SMSC内部模块黑名单号段、拦截原因码被拦截消息不进存储队列填这张表时有三处容易错第一external实体提交的消息source_addr和destination_addr要用国际格式还是本地格式PPT里若没写明联调时一定出状况第二registered_delivery这个参数0表示不要状态报告1表示要成功和失败都返回有些客户只要失败回执参数又不一样第三message_id的定义权到底由SMSC生成还是由SP侧生成要在一开始定死不然状态报告回来对不上账。3.3 用最小工具验证「状态报告」这条业务链路协议层验证最有价值的不是拿客户端发一条短信测通而是直接抓包看状态报告链路通不通。这里我用一个最简单的抓包姿势给你参考。tshark -r smsc_trace.pcapng -Y smpp.command_name deliver_sm -T fields \ -e frame.number \ -e smpp.sequence_number \ -e smpp.esm_class \ -e smpp.message_state这段命令从抓包文件里过滤出所有SMPP deliver_sm报文显示帧号、序列号、esm_class和message_state四个字段。逻辑是deliver_sm既承载普通上行短信也承载状态报告区分标志就在esm_class——第2位为1十六进制0x04时表示这条deliver_sm里装的是状态报告。再看message_state字段1代表DELIVRD送达4代表UNDELIV无法送达2代表EXPIRED过期。抓包验证时如果能看到message_state1说明整条状态报告链路已经打通如果全是submit_sm而没有deliver_sm问题多半出在registered_delivery参数或SMSC侧的状态报告开关上。这套方法的优势是不依赖任何客户端只要有一台能抓包的跳板机或者从SMSC镜像口拿一份pcap就能快速定位是协议层问题还是业务层问题。注意字段名tshark版本不同略有差异版本过低时smpp.message_state可能解析不出来需要升级Wireshark套件到3.x以上。4. 从PPT到可运维系统容量规划与关键参数怎么设业务功能PPT看到这一步你会发现真正决定项目成败的不是功能列表而是那些没人愿意写进PPT的参数。SMSC是典型的高并发、高可靠系统参数设得对不对直接决定你是在做工程还是在做玄学。4.1 存储转发队列与重试定时器T1/T2/T3该给多少存储转发队列的设计核心是算准两笔账队列要能装多少条消息消息要在队列里待多久。先算「装多少」。队列容量取决于系统峰值TPS乘以消息最长滞留时间。举例一个中等规模的SMSC忙时提交峰值200条/秒有效期24小时理论上队列至少要有200×86400约1728万条的容量。实际上不用按满24小时算因为大部分消息在几分钟内就投递成功了真正滞留到最后的只是极少数。工程上常见的做法是队列容量按峰值TPS×2小时估算再加上20%到30%的余量同时对超过2小时仍滞留的消息进入慢速重试池单独管理。再算「待多久」。重试定时器决定消息在队列里的生命周期。我常用的四档退避参数如下表档位触发时机建议值作用T1首次投递失败1分钟给MSC瞬态抖动一点恢复时间T2第二次失败10分钟让HLR查询结果先缓存过期T3第三次失败30分钟等待MSC或HLR告警恢复T4第四次失败60分钟最后一轮尝试总有效期超过即作废24小时业务类可48小时防止僵尸消息占据队列一个需要特别注意的细节延迟类业务如验证码和通知类业务的超时时长应该分开。验证码的有效期超过10分钟就基本没意义用户早就手动重发了而营销短信晚半小时送达用户也能接受。统一用一个24小时有效期会导致大量已经无意义的验证码在队列里反复重试挤占重试通道。我一般在SMSC里按业务类型区分有效期验证码类设30分钟通知类设4小时营销类设24小时。4.2 短信有效期、去重窗口与积压保护短信有效期validity period这个参数PPT上通常一行字带过但它直接决定存储资源的占用。SMSC在收到消息时就开始计时超过有效期后不再尝试投递。问题是过期消息怎么处理是直接删除还是生成一条失败状态报告回给发起方这两者对系统负载影响完全不同。直接删除最省事但SP客户那边会永远等不到回执生成失败回执则要占用一条处理链路。我一般建议线上生产环境必须有回执否则业务侧无法感知消息最终状态回执内容里要写明失败原因为「有效期过期」方便SP做后续补发。去重窗口是另一个容易被忽略的参数。外部网关重传、客户端超时重发都可能让同一条短信被提交两次。SMSC要有按「msg_id 接收号码 消息内容哈希」的去重机制典型窗口设为5分钟窗口内重复提交直接返回上一次的受理结果不再重复入库。这里有个度要把握窗口太短挡不住延迟重传窗口太长又可能误伤正常业务——比如群发场景里两条内容完全相同的消息发给同一个号码确实可能是用户故意发的两次。所以去重一定要把消息ID纳入判断而消息ID必须由SP侧生成并保证唯一不能都用SMSC生成。积压保护是最后一道防线。当队列水位超过设定阈值我常用的墙是80%系统要自动进入保护模式对新提交的低优先级消息直接返回临时失败让SP过一会儿重试对高优先级消息保持正常受理。水位到95%时连高优先级也拒绝接收保证系统还能把手上的消息尽量投完。这个阈值参数要在压测里调不是上线时拍脑袋设的。4.3 计费与优先级业务功能背后的话单设计计费是业务功能PPT里最敏感、也最容易含糊的一章。不同运营商的计费口径不同但原则只有一条计费点必须和「成功」的定义焊死。常见的计费点有三种。第一种是MO计费短信从用户提交到SMSC且校验通过就计费不管对方收没收到。这种模式简单但用户被扣了费却收不到短信时会投诉。第二种是MT计费以SMSC成功投递到接收方MSC为准计费靠状态报告回填话单对用户友好但要求状态报告不能丢。第三种是前转计费适用于SP之间转发或国际短信业务按转出方和转入方分别计费。工程上自建SMSC通常采用第二种因为话单最干净对账也简单。计费话单上最少要有这些字段主叫号码、被叫号码、消息ID、提交时间、最后投递时间、投递结果状态、有效期、优先级、计费类型标识。特别提醒话单生成时机要和状态报告回填一致。有些系统在submit_sm受理时就先生成一条预话单状态报告回来后再更新结果字段有些系统等状态报告回来才生成话单。前者的风险是状态报告如果丢了话单结果就永远是未知后者的风险是状态报告延迟太久话单迟迟出不来。我的做法是预生成话单加超时回补受理时生成预话单状态报告回来后更新状态若超过30分钟状态报告还没回来按SMSC内部投递队列的最后状态补一条并对账时标注「未确认」。优先级参数再补一句别迷信priority_flag。真正的优先级要靠队列分区实现——高优先级走独立队列和独立投递线程而不是在同一个队列里靠排序。同一个队列里排序遇到大批量低优先级消息涌入时排序开销和锁竞争照样拖慢高优先级消息。独立队列才是硬隔离。5. 短消息中心功能落地避坑5个高频翻车现场功能模块都接完了联调也调通了量产环境还是会翻车。下面五条是我在这些年排查里遇见最多的坑按现象、原因、解决三步写出来照着核对能省很多半夜电话。5.1 状态报告丢失DLR映射没按msg_id闭环现象SP侧短信都收到了但等状态报告一条都等不到或者偶尔能收到几条大部分丢失。原因大概率是msg_id对不上。SP提交短信时自己生成了一个msg_idSMSC受理后又按自己的规则生成了另一个message_id。状态报告回来时带的是SMSC的message_idSP却拿自己生成的msg_id去匹配自然配不上。还有一种情况是SMSC集群里多个节点都能产生状态报告但报告没有统一回到SP刚才提交的那条连接上。解决对接之初就约定msg_id的归属权。常见做法是SP生成一个全局唯一的msg_id放在协议里提交上来SMSC全程沿用这个ID状态报告里原样带回两边以此关联。部署了集群的话每个SMSC节点要配置专属的msg_id前缀避免两个节点生成重复的ID。5.2 群发短信串号会话复用与连接隔离没做对现象上一秒用户A收到提示60秒后重发验证码下一秒用户A收到另一条完全不相干的短信或者群发任务里两条不同内容的短信互串了接收人。原因群发场景下SP通过一个TCP连接并发提交大量消息SMSC侧解析后若用共享的全局变量暂存号码或消息内容并发一高就会互相覆盖。常见翻车点有两个一是连接级复用但会话上下文没跟连接绑定二是重试队列里只存了msg_id重发时重新取消息内容而取到的内容已经被后续消息覆盖。解决每个连接创建独立的会话上下文对象所有状态存放在上下文里禁止用模块级全局变量暂存单条消息的任何字段。重试队列里的消息必须是完整快照——源号码、目的号码、内容、优先级、时间戳全部落盘重发时只读这份快照不做二次查询组装。这条我建议写进代码评审规范比事后加监控管用。5.3 短信延迟一夜飙高重试风暴压垮前置机现象凌晨某MSC升级大量短信投递失败。恢复后SMSC集中重试结果MSC还没完全就绪又被重试流量打崩如此反复短信延迟从几分钟飙到几个钟头。原因失败消息没有按档位退避而是全部走「尽快重试」策略加上没有限制单时间片内的重试总量形成自激的流量循环。这在自动化运维体系里叫重试风暴SMSC这种永远在重试的系统尤其容易中招。解决严格按T1到T4分档退避具体值参考4.1节表格同时加一个全局熔断每分钟重试总量超过阈值一般按正常峰值TPS的50%设时重试队列暂停出队等待MSC侧的链路质量指标恢复。关键是熔断不能按消息级别做要看链路级别。5.4 话单与下发不一致计费点选取错了现象对账时发现两种问题并存——有用户扣费了但没收到短信也有短信下发了但话单里查不到记录。原因计费点放在了submit_sm受理时刻MT最终失败但状态报告没回写导致话单显示成功实际未送达另一部分则是因为计费链路只认deliver_sm状态报告状态报告一丢就漏计费。解决话单以「SMSC投递流程出终态」为准。也就是说不管最终是成功还是失败只要MT流程走到终态投递成功、有效期过期、黑名单拒绝、永久失败都要回填预话单。预话单在受理时生成状态报告回来后回填结果字段30分钟无状态报告则按内部投递状态补填并打上「待确认」标等后续对账时人工核对。这套机制在PPT上占不了多大篇幅但做计费必须按这个思路建。5.5 联调测试全过、上线就翻车只做了业务面测试现象测试环境用10条/秒的速率联调功能全通过上线后实际跑到100条/秒系统开始出现连接超时、消息积压、重复投递。原因SMSC这类系统业务功能正常不代表系统能在高并发下正常。联调阶段只验证了消息能不能通没验证在并发压力下的排队、超时、失败注入等行为。更常见的是测试环境用的是同一个MSC模拟器永远即时响应上线后真实MSC偶尔慢个几百毫秒SMSC侧的超时参数就崩了。解决验收时至少要做三类压测一是峰值1.5倍TPS的压力测试持续30分钟以上观察队列水位和投递延迟二是异常注入测试模拟MSC无响应、HLR查询超时、网络连接重置看重试和退避是否生效三是积压恢复测试先把队列压到80%水位再恢复MSC看系统能不能有节奏地把积压消息排完而不产生二次风暴。这三类测试做完才算真正具备上线条件。6. 拿这份PPT去做评审一张业务功能检查清单最后给你一个我每次评审短消息中心方案都会带在身边的检查清单。它能帮你把一份「试谈」级别的PPT快速翻译成可工程化验收的条目。评审维度必须回答的问题通过标准消息链路MO、MT、状态报告三条链路分别怎么走每条链路有明确的协议命令和失败分支重试策略失败后分几档重试、间隔多少有具体退避值拒绝「按系统默认」有效期与去重各类业务有效期分别是多少去重窗口多长验证码、通知、营销分别有不同取值优先级别priority_flag 映射到哪几个队列高优先级走独立队列不是仅靠排序容量与积压峰值TPS、队列容量、水位线阈值容量有计算依据积压保护有明确动作计费与话单计费点在哪、预话单怎么生成、状态报告怎么回填终态话单覆盖成功和全部失败原因测试覆盖是否覆盖压力、异常注入、积压恢复三类测试都有报告不止业务功能测试我个人的习惯是接到任何一份短消息中心PPT不急着看架构图先把「业务功能」一页里的每个动词翻译成这张表里的一行。翻译得过去的才是可落地的功能翻译不过去的就在评审会上请对方把话说明白。实话讲做了几年SMSC集成我发现大部分上线事故都不是功能缺失而是功能描述和工程实现之间那层窗户纸没捅破。态度是把每个含糊的词都当成潜在的事故现场一个一个问清楚才能睡得着觉。希望这份思路能帮到你下次再拿到类似PPT时愿你也能一眼看出哪些是词哪些是活。本文还有配套的精品资源点击获取 短消息中心业务功能拆解：从存储转发到参数调优实战
简介面向移动通信网络工程师、运维人员及短消息业务学习者这份技术课件围绕短消息中心业务功能系统展开系统梳理短消息从提交、转发到状态反馈的完整链路帮助读者理解短信中心核心职责与各功能触发条件适合通信培训或自学入门。资源共1个文件为PPTX演示文稿体积444KB内容编排完整已有77人学习下载。课件对短消息中心核心业务功能逐项展开介绍包含提交验证、转发控制、优先级处理、有效期管理、重发机制、状态报告、用户鉴权、汉字传输、虚拟中心、存储转发、数据报、交互三种调度模式及节日负荷保护等模块并介绍省内网络短消息中心间协同调度思路。读者通读后可建立起从概念到实现的完整认知为后续网络规划、参数配置和问题排障提供参考。1. 短消息中心业务功能一份PPT背后的核心网元与短信全链路「短消息中心业务功能」这份PPT我接过好几版有给业务部门讲增值服务的有给新同事做网元科普的还有给客户汇报系统割接方案的。名字都叫“试谈”可读完之后你要去接SMPP网关、排查状态报告丢失照样无从下手。短信不是A手机到B手机直连中间有一台叫短消息中心SMSC的核心网元做存储转发所有业务功能都绕着这个「先收下、再投递、失败了重试、还要给回执」的流程转。这篇按一线集成视角把PPT上的功能框拆成协议、参数、队列和坑新手能照着排查熟手能直接拿去对参数。2. SMSC业务功能全景把「试谈」翻译成能落地的功能清单一份讲「业务功能」的PPT最常见的毛病是只画三层手机终端、交换网、短信中心然后列出“支持短信收发、支持状态报告、支持群发”就完了。可工程上真正要确认的是这些功能背后的处理流程和边界条件。下面按我接项目时的拆法把PPT最容易含糊的两块——消息流转和消息状态——铺开说。2.1 短信从发起到送达要过几道关MO/MT与存储转发短消息中心的业务功能用一句话概括就是从发起方把短信收下来替它存着再想办法送到接收方手里最后如实告诉发起方“送没送到”。这句话拆开就是三个核心子功能。第一是MOMobile Originated移动台发起。手机用户按了发送键短信先到基站子系统再经MSC移动交换中心通过MAP信令的forwardShortMessage请求送到SMSC。此时SMSC只做两件事一是验身份确认这个号码有权限发短信二是落存储把消息内容和用户信息一起写进消息队列。这一步的关键指标是收容能力也就是短时间冲进来大量短信时系统能不能全收下并落盘而不是先拒绝再让用户重发。第二是存储转发。PPT上这四个字看着轻巧实际是整个SMSC的命门。短信进入队列后SMSC并不保证马上能投出去接收方可能关机、不在服务区、开了飞行模式甚至号码已经注销。SMSC的策略是先把消息存起来然后按路由分析找到接收方当前所属的MSC再发起MTMobile Terminated移动台终止流程。如果第一次MT失败就进入重试队列按定时器退避重试直到超过有效期才把消息作废。第三是状态报告Status Report也叫DLRDelivery Report。发起方想知道短信有没有送到SMSC会在投递成功或最终失败后按原路返回一条回执。这个回执在内部流程里是独立的一条消息它不占用户的短信配额但要占系统处理能力。很多项目验收时只看收发成功率不看状态报告成功率结果上线后SP客户全部投诉收不到回执——这就是PPT没讲透的地方。所以我在对接一个新SMSC系统时会让对方先回答四个问题消息在队列里是怎么分优先级排队的MT失败后按什么时间间隔重试有效期到了之后消息是删除还是退回给发起方状态报告是实时生成还是定时批量生成。这四个问题全都答得上来的才是真能落地的业务功能。2.2 容易被PPT一笔带过的功能才是工程重点重试、优先级与消息过滤业务功能清单里还有几项PPT常拿一句话带过但实际调参时最花时间。重试策略。初看只是“失败后过几分钟再发一次”但重试间隔的取值直接影响系统容量。设想一个场景凌晨某区域MSC割接十分钟内几万条短信投递失败。如果SMSC全部立即重试所有失败消息会在同一秒内打回MSC形成重试风暴把本来还健康的设备拖垮。所以重试必须做指数退避或分档退避我一般会按T1/T2/T3/T4分四档T1为1分钟T2为10分钟T3为30分钟T4为60分钟最多重试四次。这个值不是拍脑袋是根据MSC恢复正常所需的典型时长倒推的。优先级处理。短消息中心队列里不会只有一种消息普通用户短信、银行验证码、灾害预警、SP营销短信重要程度完全不同。SMSC一般支持按priority_flag分0到3四档高优先级消息在队列头部和重试顺序上都有优先权。这里有个坑营销短信是批量提交的如果不限制配额高峰期会占掉大量队列资源把验证码这类高价值消息挤到后面。所以除了优先级标志位还得配合每秒提交配额和单SP并发连接数一起限制。消息过滤与黑名单。这一块和业务功能有关系但通常不由SMSC核心做而是前置的业务网关做。SMSC层面至少要支持的基础过滤包括号段黑名单、内容关键字拦截、同一发送方频率限制如每分钟最高条数和非法号码格式拒绝。核心原则是过滤要前置不要等消息入了存储队列再拦截白白占用存储和重试资源。一句话总结这章看一份SMSC业务功能PPT先看它怎么处理“失败”而不是看它怎么描述“成功”。失败路径设计得好不好决定了系统在真实网络环境里是稳定运行还是天天告警。3. 把PPT功能映射到接口协议SMPP/CMPP/MAP各自管什么PPT里的业务功能最终都要落到接口协议上。短消息中心同时对着两边对内朝着运营商网络走的是七号信令的MAP协议对外朝着SP、企业网关、银行系统走的是SMPP、CMPP这类TCP/IP之上的协议。两边协议语言不同功能映射的时候很容易错位。3.1 协议栈选型什么场景用SMPP什么场景用CMPP和MAPMAPMobile Application Part是SMSC和MSC/HLR之间的信令协议。手机用户发的短信经过MSC转成MAP消息到达SMSCSMSC往接收方投递也是通过MAP把消息发回给接收方所在的MSC。这部分在运维侧通常是透明的SMSC设备厂商已经封装好集成方只需要关注SIGTRAN链路状态和GT寻址配置。但有一点要清楚MAP不支持业务侧直接对接你不可能让一个银行系统通过MAP发短信。对外接口才是集成方的主战场。SMPPShort Message Peer to Peer是最通用的协议面向短信中心与外部消息实体之间的交互国内外的SP、云短信平台基本都支持。SMPP定义了bind、submit_sm、deliver_sm、query_sm等命令字状态报告通过deliver_sm承载指令清晰、扩展性好适合做新系统对接。CMPP是中国移动定义的短消息网关协议实际使用中CMPP3.0最普遍。如果你要接运营商行业网关下发短信大概率要面对CMPP。CMPP和SMPP功能上对等都有消息提交、状态报告、话单回执但字段定义和交互流程不兼容。联通侧常见SGIP电信侧常见SMGP这些都和CMPP类似核心思路一致只是码头不同。选型上我的经验是如果是自建SMSC对外提供服务优先选SMPP因为客户端生态最成熟、开源工具多、排查方便如果业务必须直连运营商的行业网关那网关定什么协议你就得接什么协议没得挑。工程上常见做法是在SMSC外面加一层协议适配网关对外同时开放SMPP和CMPP对内统一转成SMPP或内部私有协议这样不同客户各接各的SMSC核心不用跟着改。3.2 从PPT章节到功能-接口-参数映射表拿到PPT里列的业务功能我习惯先画一张映射表把每个业务功能落到具体协议命令和需要核实的参数上。这张表同时也是后续写测试用例的依据。PPT上的功能内部流程协议/接口关键参数验收时看什么点对点短信收发MO收容 MT投递MAP forwardShortMessage外部实体走SMPP submit_smregistered_delivery设为1才返回状态报告起止号码、消息内容、时间戳完整状态报告MT结果回填SMPP deliver_smesm_class置0x04message_state字段1为DELIVRDSP侧能按msg_id关联到原短信群发/批量发送队列批量投递SMPP submit_sm批量提交或sub_multi连接并发数、每秒提交上限大批量时不串号、不重复投递定时短信队列存储到时间点再投submit_sm的schedule_delivery_time时区设置要统一定时消息到期准点出队优先级保障队列内部排序submit_sm的priority_flag0到3档映射关系高峰期高优先级先出队黑名单拦截入队前过滤外部接口前置或SMSC内部模块黑名单号段、拦截原因码被拦截消息不进存储队列填这张表时有三处容易错第一external实体提交的消息source_addr和destination_addr要用国际格式还是本地格式PPT里若没写明联调时一定出状况第二registered_delivery这个参数0表示不要状态报告1表示要成功和失败都返回有些客户只要失败回执参数又不一样第三message_id的定义权到底由SMSC生成还是由SP侧生成要在一开始定死不然状态报告回来对不上账。3.3 用最小工具验证「状态报告」这条业务链路协议层验证最有价值的不是拿客户端发一条短信测通而是直接抓包看状态报告链路通不通。这里我用一个最简单的抓包姿势给你参考。tshark -r smsc_trace.pcapng -Y smpp.command_name deliver_sm -T fields \ -e frame.number \ -e smpp.sequence_number \ -e smpp.esm_class \ -e smpp.message_state这段命令从抓包文件里过滤出所有SMPP deliver_sm报文显示帧号、序列号、esm_class和message_state四个字段。逻辑是deliver_sm既承载普通上行短信也承载状态报告区分标志就在esm_class——第2位为1十六进制0x04时表示这条deliver_sm里装的是状态报告。再看message_state字段1代表DELIVRD送达4代表UNDELIV无法送达2代表EXPIRED过期。抓包验证时如果能看到message_state1说明整条状态报告链路已经打通如果全是submit_sm而没有deliver_sm问题多半出在registered_delivery参数或SMSC侧的状态报告开关上。这套方法的优势是不依赖任何客户端只要有一台能抓包的跳板机或者从SMSC镜像口拿一份pcap就能快速定位是协议层问题还是业务层问题。注意字段名tshark版本不同略有差异版本过低时smpp.message_state可能解析不出来需要升级Wireshark套件到3.x以上。4. 从PPT到可运维系统容量规划与关键参数怎么设业务功能PPT看到这一步你会发现真正决定项目成败的不是功能列表而是那些没人愿意写进PPT的参数。SMSC是典型的高并发、高可靠系统参数设得对不对直接决定你是在做工程还是在做玄学。4.1 存储转发队列与重试定时器T1/T2/T3该给多少存储转发队列的设计核心是算准两笔账队列要能装多少条消息消息要在队列里待多久。先算「装多少」。队列容量取决于系统峰值TPS乘以消息最长滞留时间。举例一个中等规模的SMSC忙时提交峰值200条/秒有效期24小时理论上队列至少要有200×86400约1728万条的容量。实际上不用按满24小时算因为大部分消息在几分钟内就投递成功了真正滞留到最后的只是极少数。工程上常见的做法是队列容量按峰值TPS×2小时估算再加上20%到30%的余量同时对超过2小时仍滞留的消息进入慢速重试池单独管理。再算「待多久」。重试定时器决定消息在队列里的生命周期。我常用的四档退避参数如下表档位触发时机建议值作用T1首次投递失败1分钟给MSC瞬态抖动一点恢复时间T2第二次失败10分钟让HLR查询结果先缓存过期T3第三次失败30分钟等待MSC或HLR告警恢复T4第四次失败60分钟最后一轮尝试总有效期超过即作废24小时业务类可48小时防止僵尸消息占据队列一个需要特别注意的细节延迟类业务如验证码和通知类业务的超时时长应该分开。验证码的有效期超过10分钟就基本没意义用户早就手动重发了而营销短信晚半小时送达用户也能接受。统一用一个24小时有效期会导致大量已经无意义的验证码在队列里反复重试挤占重试通道。我一般在SMSC里按业务类型区分有效期验证码类设30分钟通知类设4小时营销类设24小时。4.2 短信有效期、去重窗口与积压保护短信有效期validity period这个参数PPT上通常一行字带过但它直接决定存储资源的占用。SMSC在收到消息时就开始计时超过有效期后不再尝试投递。问题是过期消息怎么处理是直接删除还是生成一条失败状态报告回给发起方这两者对系统负载影响完全不同。直接删除最省事但SP客户那边会永远等不到回执生成失败回执则要占用一条处理链路。我一般建议线上生产环境必须有回执否则业务侧无法感知消息最终状态回执内容里要写明失败原因为「有效期过期」方便SP做后续补发。去重窗口是另一个容易被忽略的参数。外部网关重传、客户端超时重发都可能让同一条短信被提交两次。SMSC要有按「msg_id 接收号码 消息内容哈希」的去重机制典型窗口设为5分钟窗口内重复提交直接返回上一次的受理结果不再重复入库。这里有个度要把握窗口太短挡不住延迟重传窗口太长又可能误伤正常业务——比如群发场景里两条内容完全相同的消息发给同一个号码确实可能是用户故意发的两次。所以去重一定要把消息ID纳入判断而消息ID必须由SP侧生成并保证唯一不能都用SMSC生成。积压保护是最后一道防线。当队列水位超过设定阈值我常用的墙是80%系统要自动进入保护模式对新提交的低优先级消息直接返回临时失败让SP过一会儿重试对高优先级消息保持正常受理。水位到95%时连高优先级也拒绝接收保证系统还能把手上的消息尽量投完。这个阈值参数要在压测里调不是上线时拍脑袋设的。4.3 计费与优先级业务功能背后的话单设计计费是业务功能PPT里最敏感、也最容易含糊的一章。不同运营商的计费口径不同但原则只有一条计费点必须和「成功」的定义焊死。常见的计费点有三种。第一种是MO计费短信从用户提交到SMSC且校验通过就计费不管对方收没收到。这种模式简单但用户被扣了费却收不到短信时会投诉。第二种是MT计费以SMSC成功投递到接收方MSC为准计费靠状态报告回填话单对用户友好但要求状态报告不能丢。第三种是前转计费适用于SP之间转发或国际短信业务按转出方和转入方分别计费。工程上自建SMSC通常采用第二种因为话单最干净对账也简单。计费话单上最少要有这些字段主叫号码、被叫号码、消息ID、提交时间、最后投递时间、投递结果状态、有效期、优先级、计费类型标识。特别提醒话单生成时机要和状态报告回填一致。有些系统在submit_sm受理时就先生成一条预话单状态报告回来后再更新结果字段有些系统等状态报告回来才生成话单。前者的风险是状态报告如果丢了话单结果就永远是未知后者的风险是状态报告延迟太久话单迟迟出不来。我的做法是预生成话单加超时回补受理时生成预话单状态报告回来后更新状态若超过30分钟状态报告还没回来按SMSC内部投递队列的最后状态补一条并对账时标注「未确认」。优先级参数再补一句别迷信priority_flag。真正的优先级要靠队列分区实现——高优先级走独立队列和独立投递线程而不是在同一个队列里靠排序。同一个队列里排序遇到大批量低优先级消息涌入时排序开销和锁竞争照样拖慢高优先级消息。独立队列才是硬隔离。5. 短消息中心功能落地避坑5个高频翻车现场功能模块都接完了联调也调通了量产环境还是会翻车。下面五条是我在这些年排查里遇见最多的坑按现象、原因、解决三步写出来照着核对能省很多半夜电话。5.1 状态报告丢失DLR映射没按msg_id闭环现象SP侧短信都收到了但等状态报告一条都等不到或者偶尔能收到几条大部分丢失。原因大概率是msg_id对不上。SP提交短信时自己生成了一个msg_idSMSC受理后又按自己的规则生成了另一个message_id。状态报告回来时带的是SMSC的message_idSP却拿自己生成的msg_id去匹配自然配不上。还有一种情况是SMSC集群里多个节点都能产生状态报告但报告没有统一回到SP刚才提交的那条连接上。解决对接之初就约定msg_id的归属权。常见做法是SP生成一个全局唯一的msg_id放在协议里提交上来SMSC全程沿用这个ID状态报告里原样带回两边以此关联。部署了集群的话每个SMSC节点要配置专属的msg_id前缀避免两个节点生成重复的ID。5.2 群发短信串号会话复用与连接隔离没做对现象上一秒用户A收到提示60秒后重发验证码下一秒用户A收到另一条完全不相干的短信或者群发任务里两条不同内容的短信互串了接收人。原因群发场景下SP通过一个TCP连接并发提交大量消息SMSC侧解析后若用共享的全局变量暂存号码或消息内容并发一高就会互相覆盖。常见翻车点有两个一是连接级复用但会话上下文没跟连接绑定二是重试队列里只存了msg_id重发时重新取消息内容而取到的内容已经被后续消息覆盖。解决每个连接创建独立的会话上下文对象所有状态存放在上下文里禁止用模块级全局变量暂存单条消息的任何字段。重试队列里的消息必须是完整快照——源号码、目的号码、内容、优先级、时间戳全部落盘重发时只读这份快照不做二次查询组装。这条我建议写进代码评审规范比事后加监控管用。5.3 短信延迟一夜飙高重试风暴压垮前置机现象凌晨某MSC升级大量短信投递失败。恢复后SMSC集中重试结果MSC还没完全就绪又被重试流量打崩如此反复短信延迟从几分钟飙到几个钟头。原因失败消息没有按档位退避而是全部走「尽快重试」策略加上没有限制单时间片内的重试总量形成自激的流量循环。这在自动化运维体系里叫重试风暴SMSC这种永远在重试的系统尤其容易中招。解决严格按T1到T4分档退避具体值参考4.1节表格同时加一个全局熔断每分钟重试总量超过阈值一般按正常峰值TPS的50%设时重试队列暂停出队等待MSC侧的链路质量指标恢复。关键是熔断不能按消息级别做要看链路级别。5.4 话单与下发不一致计费点选取错了现象对账时发现两种问题并存——有用户扣费了但没收到短信也有短信下发了但话单里查不到记录。原因计费点放在了submit_sm受理时刻MT最终失败但状态报告没回写导致话单显示成功实际未送达另一部分则是因为计费链路只认deliver_sm状态报告状态报告一丢就漏计费。解决话单以「SMSC投递流程出终态」为准。也就是说不管最终是成功还是失败只要MT流程走到终态投递成功、有效期过期、黑名单拒绝、永久失败都要回填预话单。预话单在受理时生成状态报告回来后回填结果字段30分钟无状态报告则按内部投递状态补填并打上「待确认」标等后续对账时人工核对。这套机制在PPT上占不了多大篇幅但做计费必须按这个思路建。5.5 联调测试全过、上线就翻车只做了业务面测试现象测试环境用10条/秒的速率联调功能全通过上线后实际跑到100条/秒系统开始出现连接超时、消息积压、重复投递。原因SMSC这类系统业务功能正常不代表系统能在高并发下正常。联调阶段只验证了消息能不能通没验证在并发压力下的排队、超时、失败注入等行为。更常见的是测试环境用的是同一个MSC模拟器永远即时响应上线后真实MSC偶尔慢个几百毫秒SMSC侧的超时参数就崩了。解决验收时至少要做三类压测一是峰值1.5倍TPS的压力测试持续30分钟以上观察队列水位和投递延迟二是异常注入测试模拟MSC无响应、HLR查询超时、网络连接重置看重试和退避是否生效三是积压恢复测试先把队列压到80%水位再恢复MSC看系统能不能有节奏地把积压消息排完而不产生二次风暴。这三类测试做完才算真正具备上线条件。6. 拿这份PPT去做评审一张业务功能检查清单最后给你一个我每次评审短消息中心方案都会带在身边的检查清单。它能帮你把一份「试谈」级别的PPT快速翻译成可工程化验收的条目。评审维度必须回答的问题通过标准消息链路MO、MT、状态报告三条链路分别怎么走每条链路有明确的协议命令和失败分支重试策略失败后分几档重试、间隔多少有具体退避值拒绝「按系统默认」有效期与去重各类业务有效期分别是多少去重窗口多长验证码、通知、营销分别有不同取值优先级别priority_flag 映射到哪几个队列高优先级走独立队列不是仅靠排序容量与积压峰值TPS、队列容量、水位线阈值容量有计算依据积压保护有明确动作计费与话单计费点在哪、预话单怎么生成、状态报告怎么回填终态话单覆盖成功和全部失败原因测试覆盖是否覆盖压力、异常注入、积压恢复三类测试都有报告不止业务功能测试我个人的习惯是接到任何一份短消息中心PPT不急着看架构图先把「业务功能」一页里的每个动词翻译成这张表里的一行。翻译得过去的才是可落地的功能翻译不过去的就在评审会上请对方把话说明白。实话讲做了几年SMSC集成我发现大部分上线事故都不是功能缺失而是功能描述和工程实现之间那层窗户纸没捅破。态度是把每个含糊的词都当成潜在的事故现场一个一个问清楚才能睡得着觉。希望这份思路能帮到你下次再拿到类似PPT时愿你也能一眼看出哪些是词哪些是活。本文还有配套的精品资源点击获取