序
一直就想搭建消息隊列的，因爲目前業務發展還沒有到這塊，一直沒有搭建。剛好今天接到的一個需求是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轉碼。
