摘要： Mob-SMSSDK 是可以叫应用快速、免费拥有手机验证功能的SDK。帮助开发者减少大量的开发工作，帮助企业节省短信费用。SMSSDK到现在为止经历1.0到3.0几十个版本的迭代升级，已经非常稳定和高效。
Mob-SMSSDK 是可以叫应用快速、免费拥有手机验证功能的SDK。帮助开发者减少大量的开发工作，帮助企业节省短信费用。
SMSSDK到现在为止经历1.0到3.0几十个版本的迭代升级，已经非常稳定和高效。
这个过程中有：
sdk的bug修复，性能提升，安全性提升。
sdk发送验证码部分收费到完全免费的升级。
功能逐渐丰富的过程
服务端架构调整
SMSSDK的初始版本在效能和稳定性上有太多的不足和缺失。这些问题主要集中的服务端，下面我来介绍一下SMSSDK服务端的进化之路。
一、SMSSDK1.0版本
问题
1.效能性：经常出现发送短信延迟或者失败的情况；
2.稳定性：服务不够稳定，需要经常重启服务保证服务的相对正常运行；
3.可用性：开发者反馈问题后，技术支持解决时间较长；
原因
在1.0时期的服务器架构有一些不合理的地方导致出现了上面的问题。下面我会根据架构图介绍当时的架构细节，如图：
如图中所示从SDK到负载均衡这一阶段没有太大的问题，可以继续保持使用。
问题主要出现在一下三个方面：
业务服务
数据中转
数据存储
业务服务
1.所有业务耦合在一起，经常因为一个不重要的业务流程执行缓慢导致整个验证码发送、校验业务缓慢或崩溃；
2.服务间通信采用普通的HTTP接口交互，且依赖度很高，互相影响较大；
3.服务的容错性较低；
4.通道单一，当通道出问题后服务不可用。
数据中转
使用单台Redis作为消息队列中转数据。
redis作为消息队列时，经常出现内存不足的情况,导致前面的服务响应缓慢或不响应。
因此，还延伸出了离线处理数据的多个辅助程序，增加维难度。
数据存储
1.存储数据介质多样：MongoDB，Redis，HBase，Elasticsearch。增加系统复杂度，增加维护成本；
2.存储介质稳定性低，且异常处理缺失，导致一些数据丢失；
3.日志信息记录不全，查找问题困难
上面的架构给开发，运维，技术支持带来巨大的工作量，非常影响SMSSDK的服务质量，加上SMSSDK免费业务线确定，决定对服务器架构进行重构，由此诞生了SMSSDK2.0。
一、SMSSDK2.0版本
此版本主要解决1.0版本中存在的各种问题，旨在为开发者提供更快，更稳定，更丰富功能的SDK。
架构图：
架构分析
1.访问层使用Nginx做负载均衡；
2.服务层：要求服务间互不影响或影响较小。将之前的一个服务拆分为：
o基础服务：查多写少的服务，要求响应迅速；
o短信发送、校验服务：发送验证码短信，校验验证码短信。
o其他服务：其他开发者可选集成的服务。
oWeb服务：开发者服务器接口服务。
oMob服务：隶属于Mob内部的公共服务。
通过服务拆分，将业务分级，流量分流，各个服务间解耦互不影响，服务稳定性稳步提升。 例如：有一段时间基础服务被攻击，pv由正常的2000w增加到3.7亿，导致基础服务响时间增加。但此时短信发送，校验等其他服务任然能正常使用。
3.数据处理层：
数据处理层更改的地方比较多，从根本上解决1.0版本的不稳定因素。
使用kafka做消息队列，将业务解耦，数据统一处理。
缩短服务层的处理流程，通过kafka将复杂耗时的处理在数据处理中心中异步处理，缩短服务层的访问时间。
独立短信发送业务，专注对接通道，保证短信发送稳定高效；
服务间调用使用Dubbo通信。
Redis不再写盘，并增加keepalived。
接入多条通道，保证短信发送成功率。当一条通道出现问题，自动启动备用通道发送短信。
增加业务全流程监控，并提供技术支持系统。将之前的问题查询时间缩短10倍。
服务配置动态化，即时生效，且不需要重启服务器。
4.数据存储：简化升级数据存储介质，提高其稳定性，降低维护难度。
MongoDB分库分表以提升查询写入性能；
升级优化ES的索引结构，提升数据的完整性；
通过kafka传递数据，在数据中心统一落地，统一处理落地错误的数据
以上就是SMSSDK2.0版本的服务端架构缩阴，在实际的实施过程中还遇到了很多问题：
新老版本的数据兼容合并问题；
kafka重复消费导致短信重复发送的问题；
统计耗费过多资源，且数据不准确的问题；
通道智能切换的问题；
等等其它大大小小的问题。不过在2.0版本上，进行bug查找，修复的难度降低了很多。
1.业务升级：
增加的SDK的智能验证功能；
增加了web-api发送自定短信内容的接口；
优化了SDK的通信协议，提升安全性和性能；
在SMSSDK2.0稳定运行之后，由于Mob内部业务调整，开发者需求增多等诸多因素，SMSSDK迈入了3.0。
三、SMSSDK3.0版本
SMSSDK3.0在主体架构上没有做太大的改动，主要在业务上做了很多的优化工作。最终目的是缩短开发者集成SDK的时间，提升Mob平台的服务品质。
在3.0中，主要做了以下升级：
1.同一个appkey可以在mob的所有sdk中使用。
2.开发者可以个性化配置：短息内容，验证码长度，验证码有效时间；
3.接入了更多优质通道，提升短信发成功率；
4.标准化sdk的通信协议，方便和其他mob下sdk组合使用； 还有bug修复，性能优化的工作，就不逐个列举了。
结语
以上就是SMSSDK 2年来的进化过程。这其中有服务崩溃时的慌张，有数据丢失时的惊恐，有寻找bug时的迷惑，有服务稳定高效时的欣喜。
在未来SMSSDK将继续保持高效、稳定的验证和发送服务。持续不断的技术升级，为开发者提更为丰富的功能。
版权声明：本文内容由互联网用户自发贡献，版权归作者所有，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至：yqgroup@service.aliyun.com 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
