day 20 - 新增需求：随时通知目前统计状况 nsq / websocket 介绍

假设收到一个回馈, 希望能即时把目前的点数状况反应在操作画面上, 让调度员可以随时掌握点数的状况来做调度跟分配。

在跳坑Go以前开发的API多是由介接端主动往Server去问资料, 如果想持续更新资料, 介接的服务要自己设定一个时间区间N秒不断地询问Server是否有更新, 有拿到更新资料再继续後续的动作, 这个方式一来是更新不够即时, 二来是可能会拿回很多次不需要异动的API结果。
後来有了WebSocket, 前端注册channel就可以收到後端主动发过来的讯息, 让画面的即时更新可以更有效率。Go开发之後我们大量使用了NSQ来控制事件的流程, 由起点主动发送事件到NSQ, 再由需要监听事件的服务自己监听事件来进行动作。但是NSQ无法让前端直接收到讯息, 它没有提供WebSocket支援, 所以如果需要转发到前端就要有服务负责接收NSQ讯号再把讯息转到WebSocket, 查看NSQ的issue,看起来似乎也不会有支援webSocket的打算。

简介一下这两样工具:

• NSQ

  一款Go开发的分散式即时讯息平台, 可以分为三个部分: nsqd, nsqlookupd, nsqadmin; nsqd 负责跟nsqlookupd 注册topic与接收发送方的讯息, client端会去监听nsqlookupd上面的TOPIC, 对TOPIC注册channel, 这样就可以收到打给nsqd的讯息, nsqadmin则是一个web介面, 可以看到每个TOPIC里面有几个channel在监听, 以及TOPIC&channel收到的讯息数量与堆积的讯息数量等。

  主要有两个角色: Producer 和 Consumer。
  Producer 是负责发送讯息那一方, Consumer 是接收讯息那一方。

  有几种安装方式可参考官网
  或是透过docker 分别跑 nsqd, nsqlookupd, nsqadm也可以。

• Websocket

  webcosket 是一个网路应用层的通讯协定,是从HTML 5 开始提供的一种让Client端浏览器和Server之间能进行双向通讯的技术, 主要是用来补足http协定无法持久连线的不足。http协定只有在client端主动发起request时才会建立连线, 等到API回应之後又会断开连线。Websocket让浏览器对Server注册频道之後就可以保持长连线随时收到Server发送过来的讯息。
  我们团队主要是使用syhlion/gusher.cluster来做为Websocket转发的Proxy, 由一个服务负责监听所有NSQ讯息再转发给Client端。所以後端的服务只要发送NSQ讯号就好。

使用NSQ发送事件的好处是: 接收方的服务只要对nsqlookupd注册就可以收到讯息。
发送方握有主动权可以主动通知事件让监听TOPIC的服务们在收到事件之後能马上做出对应的动作, 不需要再像以前一样不断地询问Server是否有事件需要处理, 另外如果是可以分散处理的工作, 服务也可以透过多Pod注册同一个channel, 各别跟NSQ领取事件来加速处理事件。不过NSQ因为是个别通知的事件,如果发送方在同一时间把大量事件推到NSQ, 并无法保证接收方收到的顺序, 这时候可以在讯息内容加上发送时的timestamp做识别。

今天先到这里, 明天再来实作。