多短信推送平台的客户端设计

April 19, 2015 15:07


现在云短信平台比较多,如云片、推立方、亿美、微米等等,各各平台的在使用上、 短信到达率及费用各不相同。为了让用户得到更好的体验,我们也不能把自己绑到一个平台上。 在选用时,我们可以同时选择多家平台,智能的在各平台之前切换, 以免因一家出问题,而导致用户接收不到消息。

那么我们如何写一个支持多个平台的短信发送客户端呢?首先来理一下基本的流程:


                              -------------
                              | Service 1 |
  --------------   select     | --------- |         --------------------
  | Client.push | ========>   | Service 2 | ======> | push by Service X |
  --------------   service    | --------- |         --------------------
                              | Service 3 |
                              -------------
  1. Client 调用 push
  2. 选择一个适当的推送服务
  3. 使用选择的服务推送

嗯,这流程一看就是非常简单的,那么,我们应该怎么去选择一个适当的 service 呢? 如何知道一个 service 当前是否可用,如何知道用户已经正常收到了我们 push 的消息? 最终我通过了下面几种方式来判断一个服务的可用性

那么,接下来,我们就来重新规划发送流程:


                            -------------
                            | Selector  |
  ---------------  fetch    |-----------|         --------------
  | Client.push | ========> | Service 1 | ====>  | Service.push |
  ---------------  service  |-----------|         --------------
                            | Service 2 |              ||
                            -------------              ||
                                  /\                   || Feedback
                                 /||\                  ||
                                  ||                  \||/
                                  ||                   \/
                                  \\ Update       ------------
                                   \============= | Recorder |
                                    Services list ------------


  1. 准备推送一条消息
  2. 在服务列表中选择一个可用的 service
  3. 进行推送,并将本来推送的目标、内容、结果反馈给 Recorder
  4. Recorder 根据目标和内容来判断当前是否是一次重复的推送(用户请求重新发送),根据结果得知推送是否正常,根据这些数据对 Selector 进行调整,比如1分钟内失败了10次就关闭一个 service 一段时间

到这里,就差写代码了,下面一些在代码方面的简单思路


在使用过程中,如果按用户是否请求重复发送消息来判断服务可用性的话,可能会因恶意请求造成所有 service 被视为不可用,所以这种方式还是得酌情使用

Comments: