阿里云短信平台

去年双十一前夜，阿里我盯着监控大屏上那条几乎垂直拉升的云短短信发送量曲线，心里其实挺平静的信平。每秒一万两千条，阿里这个数字搁在三年前够我们整个团队通宵达旦地扩容服务器，云短现在不过是信平阿里云短信平台控制台上一个实时跳动的计数。点开某个子账号的阿里发送详情，每一条都带着时间戳、云短签名、信平模板ID和运营商返回的阿里状态码，密密麻麻地往下滚，云短像瀑布。信平

很多人对短信平台的阿里印象还停留在“找个通道商买套餐”的阶段。我最初也这么干过，云短对接过七八家小服务商，信平价格从三分五到五分二不等，便宜是真便宜，但每逢月底对账就头疼——他们后台的数据和我们自己的日志永远对不上，丢包、延迟、签名被运营商拦截，出了问题只能靠猜。后来换到阿里云，最大的感受不是技术多先进，而是“账能算清了”。每条短信的完整生命周期都有记录，从API请求发出到最终抵达用户手机，中间经过哪些网关、哪个环节耗时多少，一清二楚。这种透明度对技术团队来说，比省那几厘钱重要得多。

控制台的设计其实挺“工程师思维”的。左侧导航栏里，国内消息和国际/港澳台消息是分开的，签名和模板的管理入口挨着，但审核状态用不同颜色标得明明白白。我印象最深的是模板审核被驳回时的提示，不是笼统的“内容不合规”，而是具体到“变量位置可能引起用户误解”或者“营销类短信缺少退订方式”。这种颗粒度，一看就是被大量实际案例磨出来的。有次我提交了一个带“限时”字样的模板，秒拒，理由写着“避免诱导性词汇”，旁边直接附了修改建议。省了工单沟通的功夫。

API的设计也值得说两句。SendSms这个接口的参数列表不长，PhoneNumbers、SignName、TemplateCode、TemplateParam，几个必填项摆在那儿，没什么花哨的封装。但真正体现功力的地方在错误码。比如isv.BUSINESS_LIMIT_CONTROL这个码，它不告诉你具体触发了哪个限流策略，但配合阿里云自己的流控文档和请求ID，能在日志服务里快速定位到是哪个手机号或哪个模板在短时间内请求过量。我们内部做过统计，接入阿里云之后，因为限流导致的发送失败率从之前的千分之三降到了万分之零点七。数字不大，但放在日均百万级的量级上，就是每天少丢几百条验证码。

国际短信这块我踩过坑。给东南亚用户发验证码，一开始用国内模板直接翻译，到达率不到六成。后来在阿里云的控制台里翻到各个国家的运营商政策说明，才发现有些地区对发送频率极其敏感，同一个号码一小时内超过两条就可能被标记为骚扰。调整了发送策略，把重试间隔从30秒改成动态的指数退避，到达率才爬回九成以上。这些细节文档里都有，但如果你不主动去翻，平台也不会弹窗提醒你。

价格方面，阿里云不算最便宜的。国内短信按量付费大概四分五一条，买套餐包能压到三分多，比某些小通道贵了将近一厘。但考虑到它和日志服务、云监控、访问控制这些产品的无缝打通，省下来的人力成本早就覆盖了差价。我们团队现在只有半个运维在管短信通道，其余精力都投在业务逻辑上。上个月有个新来的后端问我，为什么不用那家报价两分八的通道商，我让他去查了一下对方近半年的运营商投诉率——百分之一点二。他没再说话。

说到底，短信这个看似古老的通信方式，在验证码、通知、营销这些场景里依然是刚需。阿里云短信平台没打算把它做得多性感，就是把稳定、透明、可追溯这几件事做到了及格线以上。对于每天要发几十万条短信的团队来说，及格线有时候就是生命线。