企业官网建设流程全解析

简介：面向移动通信网络工程师、运维人员及短消息业务学习者，这份技术课件围绕短消息中心业务功能系统展开，系统梳理短消息从提交、转发到状态反馈的完整链路，帮助读者理解短信中心核心职责与各功能触发条件，适合通信培训或自学入门。资源共1个文件，为PPTX演示文稿，体积444KB，内容编排完整，已有77人学习下载。课件对短消息中心核心业务功能逐项展开介绍，包含提交验证、转发控制、优先级处理、有效期管理、重发机制、状态报告、用户鉴权、汉字传输、虚拟中心、存储转发、数据报、交互三种调度模式及节日负荷保护等模块，并介绍省内网络短消息中心间协同调度思路。读者通读后可建立起从概念到实现的完整认知，为后续网络规划、参数配置和问题排障提供参考。

1. 短消息中心业务功能：一份PPT背后的核心网元与短信全链路

「短消息中心业务功能」这份PPT，我接过好几版：有给业务部门讲增值服务的，有给新同事做网元科普的，还有给客户汇报系统割接方案的。名字都叫“试谈”，可读完之后你要去接SMPP网关、排查状态报告丢失，照样无从下手。短信不是A手机到B手机直连，中间有一台叫短消息中心（SMSC）的核心网元做存储转发，所有业务功能都绕着这个「先收下、再投递、失败了重试、还要给回执」的流程转。这篇按一线集成视角，把PPT上的功能框拆成协议、参数、队列和坑，新手能照着排查，熟手能直接拿去对参数。

2. SMSC业务功能全景：把「试谈」翻译成能落地的功能清单

一份讲「业务功能」的PPT，最常见的毛病是只画三层：手机终端、交换网、短信中心，然后列出“支持短信收发、支持状态报告、支持群发”就完了。可工程上真正要确认的，是这些功能背后的处理流程和边界条件。下面按我接项目时的拆法，把PPT最容易含糊的两块——消息流转和消息状态——铺开说。

2.1 短信从发起到送达要过几道关：MO/MT与存储转发

短消息中心的业务功能，用一句话概括就是：从发起方把短信收下来，替它存着，再想办法送到接收方手里，最后如实告诉发起方“送没送到”。这句话拆开，就是三个核心子功能。

第一是MO（Mobile Originated，移动台发起）。手机用户按了发送键，短信先到基站子系统，再经MSC（移动交换中心）通过MAP信令的forwardShortMessage请求送到SMSC。此时SMSC只做两件事：一是验身份，确认这个号码有权限发短信；二是落存储，把消息内容和用户信息一起写进消息队列。这一步的关键指标是收容能力，也就是短时间冲进来大量短信时，系统能不能全收下并落盘，而不是先拒绝再让用户重发。

第二是存储转发。PPT上这四个字看着轻巧，实际是整个SMSC的命门。短信进入队列后，SMSC并不保证马上能投出去：接收方可能关机、不在服务区、开了飞行模式，甚至号码已经注销。SMSC的策略是先把消息存起来，然后按路由分析找到接收方当前所属的MSC，再发起MT（Mobile Terminated，移动台终止）流程。如果第一次MT失败，就进入重试队列，按定时器退避重试，直到超过有效期才把消息作废。

第三是状态报告（Status Report，也叫DLR，Delivery 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和MAP

MAP（Mobile Application Part）是SMSC和MSC/HLR之间的信令协议。手机用户发的短信经过MSC转成MAP消息到达SMSC；SMSC往接收方投递，也是通过MAP把消息发回给接收方所在的MSC。这部分在运维侧通常是透明的，SMSC设备厂商已经封装好，集成方只需要关注SIGTRAN链路状态和GT寻址配置。但有一点要清楚：MAP不支持业务侧直接对接，你不可能让一个银行系统通过MAP发短信。

对外接口才是集成方的主战场。SMPP（Short 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里列的业务功能，我习惯先画一张映射表，把每个业务功能落到具体协议命令和需要核实的参数上。这张表同时也是后续写测试用例的依据。

填这张表时有三处容易错：第一，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_state=1，说明整条状态报告链路已经打通；如果全是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小时仍滞留的消息进入慢速重试池，单独管理。

再算「待多久」。重试定时器决定消息在队列里的生命周期。我常用的四档退避参数如下表：

一个需要特别注意的细节：延迟类业务（如验证码）和通知类业务的超时时长应该分开。验证码的有效期超过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_id，SMSC受理后又按自己的规则生成了另一个message_id。状态报告回来时带的是SMSC的message_id，SP却拿自己生成的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，快速翻译成可工程化验收的条目。

我个人的习惯是：接到任何一份短消息中心PPT，不急着看架构图，先把「业务功能」一页里的每个动词翻译成这张表里的一行。翻译得过去的，才是可落地的功能；翻译不过去的，就在评审会上请对方把话说明白。实话讲，做了几年SMSC集成，我发现大部分上线事故都不是功能缺失，而是功能描述和工程实现之间那层窗户纸没捅破。态度是：把每个含糊的词都当成潜在的事故现场，一个一个问清楚，才能睡得着觉。希望这份思路能帮到你，下次再拿到类似PPT时，愿你也能一眼看出哪些是词，哪些是活。

本文还有配套的精品资源，点击获取