前言
陆陆续续间间隔隔开发公司短信平台接口已经一段时间了，在年末的时候找个空闲把觉得实际可行的东西记录下来。
想了想，感觉这东西应该没啥好说的，但是又觉得哪里需要记一记，以后换个工作环境，还来一发呢，不就可以避免不必要的坑。
毕竟在实现短信接口的过程中，看似简单，但是有许多需要注意的地方和可以一步到位的地方可以记录下来，请大牛们分享探讨不足指正。
来吧，整理整理思绪。
开发背景
由于公司的APP端、微信公众号端、各种后台端和报警机制端等等的一系列应用和系统都需要用到一个基础功能：发短信。所以一开始只是做了简单的一个发短信的接口在dubbo上，供各个端来调用。基础短信接口是去接入市场上一些靠谱的短信服务商，比如国都、中数、阿里云以及一些国外的短息服务商等等。渐渐地、公司的业务量在慢慢变大，用户量也在变大，导致短信的日用量逐渐增大，每月都是一笔大支出，老板可不高兴了，咋回事，短信被人刷了还是开发人员死循环了乱发短信。这时候，就意识到需要完善这个短信接口了，不能单纯的调来调去就了事了。
短信平台构建
一、基础短信接口：在dubbo上开发了包括单条短信发送接口、批量短信发送接口（多个号码内容一致）、批量个性化短信发送接口（多个号码内容各不一致）、短信余额查询接口、短信状态回调接口（短信服务商回该接口告诉我们刚才发送的那条短信发送成功与否）等
在开发上述这些接口的时候，当然你需要出一份接口文档，合理简单些喔不然业务端的开发人员会刚xi你。但是不管他们怎么刚你，你一定要在手机号码和短信内容的基础上加上这几个参数：
- templateid:模板id,这个参数可以用于这个短信的模板类别，是哪种模板，因为有的短信服务商也是按模板才能发送短信的，不是任意的内容都能给你发，自己也能定义几种模板很规范化有木有。
- areaid:国家地区编码，这个东西默认可以不填认为是中国大陆手机号，但是后面你公司要是牛逼了走向世界了，给国外用户发短信呢，是不是，提早防备啊。
- sourceid:业务名称编码，就是用来标记这条短信是哪个具体业务发出去的，这样老板问你短信花销怎么这么大的时候，你就可以说就是它，这个业务短信用量非常大。开个玩笑哈，这是统计短信用量开销的最佳手段啊。
当然，发送完一条短信的时候，这些参数信息以及发送时间、发送是否成功，回调状态等等的参数都是要记录到数据库的，这里有两个要点：
- 存放短信发送记录的表字段要设计的尽量详细，只能多不能少，用不上的大不了后面先NULL呗，万一哪天扩展功能又用上了对吧。
- dubbo发送短信接口上，调用短信服务商http接口发送短信和插入我们自己的数据表的两个操作请用异步，这样当并发大的时候才能及时hold住，servlet3.0以上是支持异步的，所以dubbo也早就支持。
二、短信平台后台：内部开发的一个工具网添加短信模块，可以在上面实时查看每条短信的发送情况、账户余额情况、敏感词汇管理、短信计费报表、短信服务商切换、运营短信批量导入发送（比如公司要做个类似银行发买黄金短信给你的那种推广的时候，运营人员可以进行的推广手段）等功能
这个web的东西就不细说了，数据都是读取mysql表的。敏感词提下：就是我们国内不是所有短信内容都能发，一些非法词汇是不允许发送短信的比如"激情大奖"，这个词汇一般找短信服务商要个excel，导到数据库中，短信接口在发送前自己先过滤一遍先，web这边可以增删改查管理下。短信服务商切换也说下：就是一般我们会有一个备用的短信服务商，一旦目前在用的这个短信服务商突然出问题了短信都是发送失败的，需要换一个，这时候就可以切成备用的另外一家服务商，实现的话，是在zk上拿一个节点来控制，发送短信的接口都会实时关注这个值的情况来来选择短信服务商。
注意事项
不管业务端是否有对用户请求验证码类似功能的做限制，短信平台端要有最基础的防刷手段：1、同一天内同一个手机号码最多发送短信的量；2、同一个手机号码下次发送短信要间隔上次至少多久。这两个限制一出，平台端的限制也只能这样了，不能再细致了，再细致的限制我觉得应该是业务端的事情了。还有就是像阿里云短信这样大的服务商本来就自带这种限制buff，但是有的是不自带比较自由随你发，你一调他服务他就收你钱。
短信的到达率真的是很重要，想要几乎接近99%的短信发送成功率，那就要找短信服务商给你专线，这就看你的短信量大小和商务部能力了，能要到专线是最好的，不同的短信服务商到达率真的参差不齐，目前我觉得国都是不错的（此处不是广告）。
国内短信服务商发送国内短信收费便宜，但是发送国外短信贼贵，所以你公司的业务要是扩展到海外，量也还行了，最好到当地国家找一家短信服务商，收费便宜到达率还高，写短信接口的时候areaid参数的判断就能用上了。
最后新年快乐！！！！
2017-01-24