序
一直就想搭建消息队列的，因为目前业务发展还没有到这块，一直没有搭建。刚好今天接到的一个需求是web系统实现微信扫码登录，另外我们的微信对接是统一的中台接口对接，所以我们没办法做到回调我们的web业务系统。于是经过与同事讨论，分析场景逻辑，得出了一套web与中台、微信、消息服务的交互。
经过一夜消化，我画出了如下时序图
这里说明下，首先微信公众号只能绑定有限的回调域名，这大家都知道。因为我们公司的项目比较多，所以我们统一中台对接微信公众号，实际就是为了能有一个公用的微信openId。这个id是微信再每个平台的唯一标识，因为都用于我们的系统，所以这个id我们要一个就ok了，实际上别的公司以后可以对接我们的这个服务，实现web系统微信扫码登录。就跟我上次统一的支付平台一样。要知道微信的这个扫码登录得300块钱啊。
二、实现的模式
后端放置消息到消息队列，主题就是终端的clientId，终端的websocket连接消息队列的ws服务，主题监听clientId。所以就实现了点对点（开2个浏览器也不怕，因为我们用的时间戳，不会有这么巧精确到毫秒吧）。
前端通过收到的信息，其实这个信息我也包装下成http接口请求返回有code，msg，data一样格式的json字符串。这样就当是前端请求接口的返回数据一样，根据code值做不同的业务响应。
三、遇到的坑
先前我花了大力气有了初步想法，找中台讨论，推动搭建消息队列，但是似乎不怎么认可方案。然后，第二天一大早我就来画的时序图，加上我之前其实搭建过MQTT服务，并且自己玩了下。我就利用这验证了我的方案可行，可以说是从后端、前端、mqtt服务，我自己都串起来，验证可行了。终于是说服了对方支持，得亏最近在看书，要是以前，我TM就自己带着前端去玩了。然后他有要用他熟悉的RabbitMQ，鄙视我用的apollo不能集群。我实际上就只要你的服务，那你说怎么就怎么吧。消息我自己发，不用中台提供接口。后来又说一个终端建一个主题伤性能，之前我说1000人同时高并发，反驳我时做梦。。。
宝宝心里苦啊，想搞点新玩意，促进大家一起进步，真的是带不动。
mqtt的相关代码，涉及到公司机密就不贴了，apollo的网上一大把，按照我的这个时序就可以省300每年，不用微信的扫码登录，实在有疑惑的地方，可以博客留言。我这里也就不贴代码了，唯一说洗啊就是内容有中文，前端收到的有乱码的问题。我这里是用的org.fusesource.hawtbuf的AsciiBuffer转码。
