推倒？！重构还是有意思

这周重构了下我的开源项目消息推送平台，虽然改动稍微有点大，但重构的过程还是蛮有成就感的，很多代码都推倒重来，一步一步看着项目完善，贼有意思。

在几个月前，我在austin写了个feature分支，实现了部分代码：austin的渠道账号从配置的方式改为读取数据库进行增删改查。

对渠道账号的管理，在我实现的时候也有个迭代的过程：

1、在最开始实现的时候，我是直接把账号信息写在代码里的，当时没有做任何的存储。

2、后来，当我引入了apollo后，我决定把账号的信息写在分布式配置中心上，这会比较方便去做增删，这也是生产环境里比较正常的姿势。

3、再后来，为了推广austin，需要把门槛降低（并不是所有人都希望用apollo），后来就引入了nacos，并且又使用本地配置文件的方式可读取到账号信息。实现优先读远程配置中心，读不到则读取本地配置文件。

4、到这一次，我把账号的信息全部重构至数据库里，在austin的前端上实现一套对账号的增删改查。

为什么会有这个改动？我这也是有几个原因的：

1、austin一定会依赖数据库，这是强依赖必不可少的。对账号信息的管理对数据库而言只是多一张表，本来austin的数据库表就不多，现在就总共3张

2、austin后续会支持docker的支持部署，如果不使用分布式配置的同学，那就很难对账号进行管理了（因为之前是把账号信息写在本地的properties文件里的）。

3、账号的信息分散在配置中心和本地文件也不合理，如果后期要改动账号管理，那这俩个地方都需要跟进。

4、新增/查询渠道账号有较强内部约定，之前是每个渠道的每个账号步长为10。比如腾讯云短信的ID为10，云片短信渠道的ID为20，如果要新增阿里云短信，那这时候短信渠道ID就为30。这些账号ID都是项目内部约定维护，这些账号ID值也是写死在前端上，不利于后续的扩展。

那么，把Austin的渠道账号信息维护在数据库的理由就很充分了。这是我几个月前就想干的事，但这段时间成为了救火队员，又想出来看看面试机会，导致一直搁置了。

这几天已经把相关的代码给实现了，从文件的角度来看改动还是蛮大的，但代码实现倒是挺简单的，无非就是对单表的增删改查嘛，这期间又顺便优化了部分代码。

由于各个渠道的配置都不太同，我这也取了个巧，直接把配置用json传入就完了。不然要做一堆的解析工作（其实主要是不想写前端，这会耗费很多时间）

在新增的时候，不同的发送渠道都会给出对应的样例，只要根据样例修改为对应的值就完事咯。

一般新建渠道账号都是需要开发的支持，所以这里的“取巧”，问题不大。

唯一值得注意的就是短信渠道，如果还记得，我们的在短信渠道上是实现了使用配置根据不同的消息类型实现短信渠道商之间的流量分配的功能。

实现该功能的理由：

别以为我们的依赖是阿里云、腾讯云或者华为云这种大公司，他们提供的产品不是万无一失的，挂也是很正常的事。那如果我们只依赖一个短信渠道，它挂了，是不是相当于我们就挂了。 解决方案：短信需要接入多个渠道商，调用接口失败需要继续调用其他渠道商，支持动态分配渠道商的流量（一旦有提前预警，直接切换渠道商）

那么在创建模板发送消息的时候就不能跟某个具体的账号匹配，而是取决于该模板的消息类型。至于具体采取哪一个短信渠道商，那得等到运行时才能确定。

基于这个背景下，我决定在短信账号的配置下增加一个字段：ScriptName。这个字段要能唯一标识具体的某个短信账号，并且方便程序之间的调用。（算是一个项目内的约定，但我觉得问题不大）

看一眼发送短信的具体的代码逻辑上，应该就很容易懂了。

代码我就刚刚已经push到master分支了，感兴趣的小伙伴可以pull 下来看看我改动了什么！

梳理了下目前各个渠道的状况，发现还是有挺多渠道还没实现完的。今天我正在实现微信服务号模板消息推送，看进度的话应该也很快就完成了。