程序员的自我救赎---2.1：短信中心项目分析

Posted 2020-10-16 程序员的自我救赎

《前言》

（一） Winner2.0 框架基础分析

（二）PLSQL报表系统

（三）SSO单点登录

（四） 短信中心与消息中心

（五）钱包系统

（六）GPU支付中心

（七）权限系统

（八）监控系统

（九）会员中心

（十） APP版本控制系统

（十一）Winner前端框架与RPC接口规范讲解

（十二）上层应用案例

（十三）总结

 

《短信中心项目分析》

从本章开始，包括后面的SSO单点登录，钱包系统，GPU支付中心，权限系统，会员中心 都是Jason开发的作品。

短信中心用一句话就能概括完：“一个提供发短信服务的项目”。开发短信中心理由也很简单，不可能每个项目都去配置并

编写发短信的功能。所以基于我们一直提倡的“职责分离”思想就开发这套短信中心。

 

我相信大部分的技术团和我们一样，一开始使用的短信服务商总是不那么如意，就好比我们一开是用的一家重庆的短信服务商

真是差到一个狗屎地步，短信发出去5分钟收不着，到达率还不到80%，多次反馈还不断推荐我们使用他们的语音验证码，

搞得我们本身项目刚上线就不稳定的阶段又增添了一个烦恼。后来通过老板的关系直接接了联通，直接对接联通的短信也一样，

到达率高点还是不过90%。而且最恶心是发联通的手机到达率很好，电信的也凑合，移动的到达率甚至低于80%。

 

当时也是糊涂，我们又走了一次弯路，我们又去对接其他的短信服务商，然后联通手机走联通通道，移动和电信走新的服务商。

这么对付着使了一年。直到后来我们接了一家上海的短信公司，这里就不提名字了，免得有打广告的嫌疑。

总之，我的经验来说，最直接的方式是上阿里云的“云市场” ：https://market.aliyun.com 这上面的服务提供商都很不错，而且云市场

上面提供的API服务也多。

 

说回正题，关于“短信中心”功能虽然简单，我先讲一下我们之前短信中心是怎么做的：

 

 这是1.0时代我们短信中心的做法（Gof二十三种设计模式之---工厂模式），首先将短信功能从各个单体项目中抽离出来这是最基本的“职责分离”思想，方便各个项目用到短信时

只需要引用Webservice调用发送短信功能即可。具体使用哪个通道可以有数据库 或 配置文件决定，也可以让调用者来决定。

 

其实这一版本短信中心就已经基本够用，但是也有他的缺点，这两年随着阅历的增长，Jason提出了“SaaS”的概念，也就是：“Software-as-a-Service 软件即服务”。

整点英文瞬间就高大上了，其实我们想的很简单，就是如果有一天短信中心变成短信服务，变成了一个产品提供给任意公司任意项目调用我们现在的短信中心能行吗？

 

答案肯定是不行的，最主要的问题是“耦合”。

我们在数据库上我们耦合了我们的用户，我们的规则是用户收到的验证码即使用户登录的默认登录密码。这里的问题就造成了，短信中心生成验证码，然后短信

中心又写了一条历史记录，而历史记录表又记录的是给哪个用户发的短信，把用户id给记录了下来，自此耦合Winner框架的数据库设计。

 其次，短信中心由于以前的特殊业务需要有的是需要用户回复的，然后根据用户的回复又耦合的其他业务。短信中心与其它项目相互关联耦合，不能独立运作自然就不能SaaS了。

 

============================华丽的分割线========================

 

不过SaaS只是一种思想，不遵循它项目当然也跑的没有任何问题，但是还有几个缺点：

1，1.0所有的第三方短信提供商的账户，密码，API接口全部配置在WebConfig中，安全性不高。

2，WebServices 的性能方面不如MVC的WebAPI，这个有点吹毛求疵，但也算是一点。

3，代码老旧且与业务重度耦合（1.0的短信中心还包含了发邮件功能）。

 

基于方方面面的原因吧，Jason就重构了这套短信中心，我们就称他为2.0吧，可以作为服务商提供服务（SaaS），也可以作为软件部署的2.0（PaaS）。

 

 首先换掉了Asp.net 用了MVC，然后彻底废掉了以前的业务耦合，最好职责分离不再兼任发邮件的功能。

 同时，第三方的配置信息也放到了数据库的去保存。

 

这里短信中心提供三个功能：1，发短信；2，发验证码；3，核对验证码；

 

我特地问了下Jason，为什么把发短信 和发验证码分开两个方法去做。 我理解的发短信就包括了发验证码。

这里Jason是特地为了兼容这种发验证码的这种需求最多的场景，因为只提供发短信功能的话，那就意味着每个调用者要自己去

生成验证码，并且核对验证码。这里每个项目都要这样去做的话，不如由短信中间统一封装起来。 可以说法短信包含发验证码的功能

但是发短信，可以帮助调用者生成验证码。 有了发验证码，就自然有了核对验证码的功能。

 

从代码上来说，2.0还是工厂，但是在角色上发生换了一种做法引入了 “提供者”这个概念。

 

 提供者是什么？确切的说，提供者就是：给具体的某个项目提供发短信的对象。 其实我一开始也纳闷，这里为什么要用反射。

后来Jason跟我解释到用反射他可以彻底不用动“短信中心”这个项目，我的理解有那么点dock容器的这么个味道。

 

简单来说，如上图的YxhSmsProvider 和 CloudCommunicateSmsProvider 这个两个对象，按设计来说本身不是在这个Facade项目类库下。

而是单独的类库，单独的短信中不存在任何具体实现，如果修养新增一个项目，只需要三步：

1，创建一个项目提供者实现ISmsProvider；

2，数据库配置提供者的程序集反射名称，第三方信息，还有项目调用者权限信息。

3，投产提供者。

 

这三个步骤，是完全可以独立于短信中心解决方案之外操作的，用我的话说着就是一个“插件式的开发”。

 

 最后这里不再去赘述其他的思想之类的话题，短信中心项目这里可以提供源码给大家研究：https://github.com/demon28/SmsCenter

 

 

 有兴趣一起探讨Winner框架的可以加我们QQ群：261083244。或者扫描左侧二维码加群。