SMSSDK到现在为止经历1.0到3.0几十个版本的迭代升级，已经非常稳定和高效。
这个过程中有：

· sdk的bug修复，性能提升，安全性提升。

· sdk发送验证码部分收费到完全免费的升级。

· 功能逐渐丰富的过程

· 服务端架构调整

SMSSDK的初始版本在效能和稳定性上有太多的不足和缺失。这些问题主要集中的服务端，下面我来介绍一下SMSSDK服务端的进化之路。

一、SMSSDK1.0版本

· 问题

· 业务服务

· 数据中转

· 数据存储

业务服务

1. 所有业务耦合在一起，经常因为一个不重要的业务流程执行缓慢导致整个验证码发送、校验业务缓慢或崩溃；

1.访问层使用Nginx做负载均衡；
2.服务层：要求服务间互不影响或影响较小。将之前的一个服务拆分为：
o 基础服务：查多写少的服务，要求响应迅速；
o 短信发送、校验服务：发送验证码短信，校验验证码短信。
o 其他服务：其他开发者可选集成的服务。
o Web服务：开发者服务器接口服务。
o 速码云服务：隶属于速码云内部的公共服务。
通过服务拆分，将业务分级，流量分流，各个服务间解耦互不影响，服务稳定性稳步提升。例如：有一段时间基础服务被攻击，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稳定运行之后，由于速码云内部业务调整，开发者需求增多等诸多因素，SMSSDK迈入了3.0。

三、SMSSDK3.0版本

SMSSDK3.0在主体架构上没有做太大的改动，主要在业务上做了很多的优化工作。最终目的是缩短开发者集成SDK的时间，提升速码云平台的服务品质。
在3.0中，主要做了以下升级：
1. 同一个appkey可以在速码云的所有sdk中使用。
2. 开发者可以个性化配置：短息内容，验证码长度，验证码有效时间；
3. 接入了更多优质通道，提升短信发成功率；
4. 标准化sdk的通信协议，方便和其他速码云下sdk组合使用； 还有bug修复，性能优化的工作，就不逐个列举了。

文章结语

在未来SMSSDK将继续保持高效、稳定的短信验证和发送服务。持续不断的技术升级，为开发者提更为丰富的功能。