三歪用了10分钟写完了一个需求

上次分享的是PUSH推送相关的，这次我们来聊聊「短信」。

抛出问题

每个公司都会发短信，对的吧？所以一般的公司都会有一个发短信的平台（我司有一个系统整合了所有的消息下发，取了一个名字叫做「消息管理平台」）。

发短信我们需要做的东西其实很少，如果发过短信的同学可能就知道：「无非就调个短信接口的API」

本质的确是调短信接口的API而已，就是这么简单。

一个公司往往对接的短信渠道可能不止有一个，可能对接有「百度」「腾讯」「阿里」等等各种的渠道商，所以我们很可能会分开不同的账号。

（这里瞎扯，真实不是这样）比如：我发营销类的短信对接的是「百度」短信API、我发通知类短信对接的是「腾讯」短信API、我发金融催收类的短信对接的是「阿里」短信API.......

现在有三个渠道，所以我们的代码也很简单，只要在代码里边对接这三个渠道就OK了。

问题是这样的：现实我们的渠道商往往不止这三个，变动的概率也很大，每次新增一个渠道商我们都要新增一个类，然后去发布代码上线

有人就会问：为什么渠道商的变动概率会很大？

其实理由也很简单：有一天有个渠道商找过来，说一分钱一条短信。现在百度的短信要3分钱一条，你想不想试试新的渠道商？那肯定是想的啊。我们先接入一下，给予一些小流量，看一下成功率是怎么样的，然后再判断要不要放量

我们下发短信了以后，还得拉取短信的回执（实际上就是看看我们短信的下发情况是怎么样的）。同理，如果要拉取短信回执，也是要单独开发一个类去做的。

痛点

上面的问题痛点是什么？是对接一个新的渠道去下发短信吗？并不是。下发短信的API非常简单，我们照着文档搞一下很快就能搞好了。

主要的痛点是：「每次新增一个短信渠道，我都需要去发布代码，走上线流程」。

业务多变性，使得我们不停地修改代码、发布代码，会浪费了一定时间在发布流程上......那么一些体积小的、变动频繁的部分是否可以使用动态脚本替代？

我司就有这么一个「脚本平台」，听到「脚本」这个词，你会不会觉得有点牛逼。（反正三歪第一次听到的时候，就觉得这个东西就很有东西）。

使用脚本平台

我们使用脚本的姿势大概是这样的:通过脚本名取到脚本对象，用接口来接收，然后调用方法（这就是面向接口编程的好处）

将代码写在脚本平台上，保存起来。

一句话概要：脚本写在脚本平台上，然后通过脚本平台提供的API我们通过脚本名去得到脚本对象。一般我们用接口来接收，随后调用接口的方法。

脚本平台如何实现

三歪在公司里边并没写过脚本平台，只是这次要写文章，就简单看了一下它的代码。脚本平台架构大概如下：

首先脚本平台给我们提供了一个页面入口，让我们去写脚本，填写脚本的基本信息（脚本唯一标识，用途，是哪个应用需要使用等等）

脚本在页面上填写完毕后，存储脚本，维护脚本的版本、状态等信息（比如可以回滚到上一个版本，将脚本禁用/启用）

到这里，我们可以简单的认为：就是把代码存起来而已，只不过加了一些对这份代码的一些功能（版本/状态)

脚本平台暴露出ScriptClient客户端供我们使用。在使用的过程中，我们只知道可以通过ScriptClient客户端拿到脚本对象，那怎么实现的呢？我如果更改了脚本的内容，那我们通过ScriptClient拿到的对象应该也是更改过的，是怎么办到的呢？

这种无需发布上线，更改即可生效的会让你想到什么？配置中心 （Nacos、Apollo、Spring Cloud Config等）

脚本平台就是通过「配置中心」类似的方式来实现的，其实我们要的是「能够动态监听变更」的功能，而配置中心刚好都有这些功能，于是我们就用它来承载了。

知道了这个以后，事情就变得简单起来了：ScriptServer保存完脚本以后，然后通知ScriptClient去解析脚本，ScriptClient解析脚本，反射成对象，用一个Map装载起来。每当我们修改脚本后，通知ScriptClient重新解析脚本、反射对象。

一句话总结：脚本实际上就是代码，只不过代码由我们自己来解析，反射成对象。代码的变更，我们利用「配置中心」就可以实现对象的变更（不过是重新解析脚本，反射成对象，替换旧的对象而已）

短信的一些事

上面花了挺大的篇幅去介绍脚本平台的，本来没想写那么多的，但怕只是提两句三歪怕你们看不懂，于是三歪就写多了点。

很多时候，明知某些流程/代码会变更的情况下，我们可以利用脚本去写，这样我们就不用经常上下线去发布代码了。现在新接入一个渠道（短信签名）对我这边来说是非常简单的，就写写脚本，本地测一下，代码都不用发布。工作效率就能提升很多

上面也提到了，短信渠道会有很多，我们可能的营销类短信可能就会有4~5个渠道能支持下发。

那渠道之间的流量分配我们又可以写在配置中心上，如果某个渠道突然要涨价了，我们只要把流量切过去别的渠道就好了。如果某个渠道不合作了，那我们把该渠道脚本禁用掉就OK了。完全不需要发布

最后

如果我们有的逻辑可能需要频繁变动，可能是校验逻辑，也有可能像我这种需要增加新的「渠道」。

可以考虑使用「脚本」的方式来接入，这样我们在上线新的「逻辑」/「渠道」的时候就不需要上下线了。这样会使我们的效率能够提高。

我司的脚本平台原理也很简单（主逻辑）：Server端负责把脚本存起来以及维护其状态，通知Client端脚本存在变动，Client端对脚本进行解析，反射成对象，对外使用。