基于go的websocket消息推送的集群實(shí)現(xiàn)

目前websocket技術(shù)已經(jīng)很成熟，選型Go語言，當(dāng)然是為了節(jié)省成本以及它強(qiáng)大的高并發(fā)性能。我使用的是第三方開源的websocket庫即gorilla/websocket。

成都創(chuàng)新互聯(lián)擁有網(wǎng)站維護(hù)技術(shù)和項(xiàng)目管理團(tuán)隊(duì)，建立的售前、實(shí)施和售后服務(wù)體系，為客戶提供定制化的做網(wǎng)站、網(wǎng)站制作、網(wǎng)站維護(hù)、內(nèi)江機(jī)房主機(jī)托管解決方案。為客戶網(wǎng)站安全和日常運(yùn)維提供整體管家式外包優(yōu)質(zhì)服務(wù)。我們的網(wǎng)站維護(hù)服務(wù)覆蓋集團(tuán)企業(yè)、上市公司、外企網(wǎng)站、商城網(wǎng)站開發(fā)、政府網(wǎng)站等各類型客戶群體，為全球近1000家企業(yè)提供全方位網(wǎng)站維護(hù)、服務(wù)器維護(hù)解決方案。

由于我們線上推送的量不小，推送后端需要部署多節(jié)點(diǎn)保持高可用，所以需要自己做集群，具體架構(gòu)方案如圖：

Auth Service：鑒權(quán)服務(wù)，根據(jù)Token驗(yàn)證用戶權(quán)限。

Collect Service：消息采集服務(wù)，負(fù)責(zé)收集業(yè)務(wù)系統(tǒng)消息，存入MongoDB后，發(fā)送給消息分發(fā)服務(wù)。

Dispatch Service：消息分發(fā)服務(wù)，根據(jù)路由規(guī)則分發(fā)至對應(yīng)消息推送服務(wù)節(jié)點(diǎn)上。

Push Service：消息推送服務(wù)，通過websocket將消息推送給用戶。

集群推送的關(guān)鍵點(diǎn)在于，web端與服務(wù)端建立長連接之后，具體跟哪個推送節(jié)點(diǎn)保持長連接的，如果我們能夠找到對應(yīng)的連接節(jié)點(diǎn)，那么我們就可以將消息推送出去。下面講解一下集群的大致流程：

1. web端用戶登錄之后，帶上token與后端推送服務(wù)（Push Service）保持長連接。

2. 推送服務(wù)收到連接請求之后，攜帶token去鑒權(quán)服務(wù)（Auth Service）驗(yàn)證此token權(quán)限，并返回用戶ID。

3. 把返回的用戶ID與長連接存入本地緩存，保持用戶ID與長連接綁定關(guān)系。

4. 再將用戶ID與本推送節(jié)點(diǎn)IP存入redis，建立用戶（即長連接）與節(jié)點(diǎn)綁定關(guān)系，并設(shè)置失效時間。

5. 采集服務(wù)（Collect Service）收集業(yè)務(wù)消息，首先存入mongodb，然后將消息透傳給分發(fā)服務(wù)（Dispatch Service）。

6. 分發(fā)服務(wù)收到消息之后，根據(jù)消息體中的用戶ID，從redis中獲取對應(yīng)的推送服務(wù)節(jié)點(diǎn)IP，然后轉(zhuǎn)發(fā)給對應(yīng)的推送節(jié)點(diǎn)。

7. 推送服務(wù)節(jié)點(diǎn)收到消息之后，根據(jù)用戶ID，從本地緩存中取出對應(yīng)的長連接，將消息推送給客戶端。

其他注意事項(xiàng)：

為什么要使用 Go 語言?Go 語言的優(yōu)勢在哪里?

1、簡單易學(xué)。

Go語言的作者本身就很懂C語言，所以同樣Go語言也會有C語言的基因，所以對于程序員來說，Go語言天生就會讓人很熟悉，容易上手。

2、并發(fā)性好。

Go語言天生支持并發(fā)，可以充分利用多核，輕松地使用并發(fā)。 這是Go語言最大的特點(diǎn)。

描述

Go的語法接近C語言，但對于變量的聲明有所不同。Go支持垃圾回收功能。Go的并行模型是以東尼·霍爾的通信順序進(jìn)程（CSP）為基礎(chǔ)，采取類似模型的其他語言包括Occam和Limbo，但它也具有Pi運(yùn)算的特征，比如通道傳輸。

在1.8版本中開放插件（Plugin）的支持，這意味著現(xiàn)在能從Go中動態(tài)加載部分函數(shù)。

與C++相比，Go并不包括如枚舉、異常處理、繼承、泛型、斷言、虛函數(shù)等功能，但增加了 切片(Slice) 型、并發(fā)、管道、垃圾回收、接口（Interface）等特性的語言級支持。

15 Go 鑒權(quán)（一）：鑒權(quán)機(jī)制概述

在現(xiàn)代web開發(fā)中，系統(tǒng)鑒權(quán)服務(wù)已是基本標(biāo)配模塊，有些開發(fā)框架甚至內(nèi)置了鑒權(quán)模塊的實(shí)現(xiàn)，或者提供一些鑒權(quán)的工具類，然而鑒權(quán)的方式也分為多種，了解各種鑒權(quán)方式的特點(diǎn)及使用場景可以幫助我們構(gòu)建更健壯的web系統(tǒng)。以下列出四種常見的鑒權(quán)方式，我們來認(rèn)識一下：

HTTP 基本身份驗(yàn)證，允許客戶端在標(biāo)準(zhǔn)的 HTTP 頭中發(fā)送用戶名和密碼。服務(wù)端可以驗(yàn)證這些信息，并確認(rèn)客戶端是否有權(quán)訪問服務(wù)。這樣做的好處在于，這是一種非常容易理解且得到廣泛支持的協(xié)議。問題在于，通過 HTTP 有很高的風(fēng)險(xiǎn)，因?yàn)橛脩裘兔艽a并沒有以安全的方式發(fā)送。任何中間方都可以看到 HTTP 頭的信息并讀取里面的數(shù)據(jù)。因此，HTTP 基本身份驗(yàn)證通常應(yīng)該通過 HTTPS 進(jìn)行通信。

當(dāng)使用 HTTPS 時，客戶端獲得強(qiáng)有力的保證，它所通信的服務(wù)端就是客戶端想要通信的服務(wù)端。它給予我們額外的保護(hù)，避免人們竊聽客戶端和服務(wù)端之間的通信，或篡改有效負(fù)載。

服務(wù)端需要管理自己的SSL證書，當(dāng)需要管理多臺機(jī)器時會出現(xiàn)問題。一些組織自己承擔(dān)簽發(fā)證書的過程，這是一個額外的行政和運(yùn)營負(fù)擔(dān)。管理這方面的自動化工具遠(yuǎn)不夠成熟，使用它們后你會發(fā)現(xiàn)，需要自己處理的事情就不止證書簽發(fā)了。自簽名證書不容易撤銷，因此需要對災(zāi)難情景有更多的考慮?？纯茨闶欠衲軌虮苊庾院灻?，以避開所有的這些工作。

SSL 之上的流量不能被反向代理服務(wù)器（比如 Varnish 或 Squid）所緩存，這是使用 HTTPS 的另一個缺點(diǎn)。這意味著，如果你需要緩存信息，就不得不在服務(wù)端或客戶端內(nèi)部實(shí)現(xiàn)。你可以在負(fù)載均衡中把 Https 的請求轉(zhuǎn)成 Http 的請求，然后在負(fù)載均衡之后就可以使用緩存了。

還需要考慮，如果我們已經(jīng)在使用現(xiàn)成的 SSO 方案（比如包含用戶名密碼信息的 SAML），該怎么辦。我們想要基本身份驗(yàn)證使用同一套認(rèn)證信息，然后在同一個進(jìn)程里頒發(fā)和撤銷嗎？讓服務(wù)與實(shí)現(xiàn) SSO 所使用的那個目錄服務(wù)進(jìn)行通信即可做到這一點(diǎn)?；蛘?，我們可以在服務(wù)內(nèi)部存儲用戶名和密碼，但需要承擔(dān)存在重復(fù)行為的風(fēng)險(xiǎn)。

注意：使用這種方法，服務(wù)器只知道客戶端有用戶名和密碼。我們不知道這個信息是否來自我們期望的機(jī)器；它可能來自網(wǎng)絡(luò)中的其他人。

HTTP 基本身份驗(yàn)證是一種簡單但不那么安全的認(rèn)證方式，不太建議用于公開的商業(yè)應(yīng)用，在此便不再展開，我們關(guān)注以下幾種認(rèn)證方式。

http協(xié)議是一種無狀態(tài)的協(xié)議，如果沒有任何認(rèn)證機(jī)制，服務(wù)端對任何客戶端的請求都是無差別的。在Web2.0時代，為了加強(qiáng)B/S交互的安全性，衍生出了Session-Cookie鑒權(quán)機(jī)制，通過在服務(wù)端開啟會話，客戶端存儲SessionID，在每次請求時通過cookie傳輸SessionID的形式實(shí)現(xiàn)服務(wù)端基本鑒權(quán)。

cookie是保存在本地終端的數(shù)據(jù)。cookie由服務(wù)器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內(nèi)，下一次請求同一網(wǎng)站時會把該cookie發(fā)送給服務(wù)器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的。

cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設(shè)置為全局:"")、失效時間、安全標(biāo)志(指定后，cookie只有在使用SSL連接時才發(fā)送到服務(wù)器(https))。

Session的中文翻譯是“會話”，當(dāng)用戶打開某個web應(yīng)用時，便與web服務(wù)器產(chǎn)生一次session。服務(wù)器使用session把用戶的信息臨時保存在了服務(wù)器上，用戶離開網(wǎng)站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務(wù)器做了負(fù)載均衡，那么下一個操作請求到了另一臺服務(wù)器的時候session會丟失。

當(dāng)程序需要為某個客戶端的請求創(chuàng)建一個session時，服務(wù)器首先檢查這個客戶端的請求里是否已包含了一個session標(biāo)識（稱為SessionID），如果已包含則說明以前已經(jīng)為此客戶端創(chuàng)建過Session，服務(wù)器就按照SessionID把這個Session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含SessionID，則為此客戶端創(chuàng)建一個Session并且生成一個與此Session相關(guān)聯(lián)的SessionID，SessionID的值應(yīng)該是一個既不會重復(fù)，又不容易被找到規(guī)律以仿造的字符串，這個SessionID將被在本次響應(yīng)中返回給客戶端保存。

保存這個SessionID的方式可以采用Cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標(biāo)識發(fā)揮給服務(wù)器。一般這個Cookie的名字都是類似于SEEESIONID。但Cookie可以被人為的禁止，則必須有其他機(jī)制以便在Cookie被禁止時仍然能夠把SessionID傳遞回服務(wù)器。

客戶端第一次發(fā)送請求給服務(wù)器，此時服務(wù)器啟動Session會話，產(chǎn)生一個唯一的SessionID，并通過Response的SetCookie返回給客戶端，保存于客戶端(一般為瀏覽器)，并與一個瀏覽器窗口對應(yīng)著,由于HTTP協(xié)議的特性，這一次Request-Response

后連接就斷開了。以后此客戶端再發(fā)送請求給服務(wù)器的時候，就會在請求Request頭中攜帶cookie,由于cookie中帶有Key為sessionID的數(shù)據(jù),所以服務(wù)器就知道這是剛才那個客戶端。

正如我們前面所討論的，如果擔(dān)心用戶名和密碼被泄露，HTTP基本身份驗(yàn)證使用普通 HTTP 并不是非常明智的。傳統(tǒng)的替代方式是使用HTTPS路由通信，但也有一些缺點(diǎn)。除了需要管理證書，HTTPS通信的開銷使得服務(wù)器壓力增加，而且通信難以被輕松地緩存。另外Session-Cookie機(jī)制也會有被客戶限制的隱患，如果用戶禁用Cookie則必須由其它方式實(shí)現(xiàn)鑒權(quán)。

所謂Token，即令牌?？蛻舳诵枰b權(quán)訪問私人信息時，會首次向服務(wù)端發(fā)送身份驗(yàn)證信息（如用戶名、密碼），服務(wù)端校驗(yàn)正確后會根據(jù)一定的加密算法生成Token令牌發(fā)放給客戶端，此后客戶端只需通過Token，服務(wù)端只需驗(yàn)證Token就可識別客戶并進(jìn)行交互，Token可存放于HTTP Header也可存放與Cookie。

以上為一個簡單的Token鑒權(quán)過程。

關(guān)于Token機(jī)制，業(yè)界有一種叫JWT（JsonWebToken）的實(shí)現(xiàn)機(jī)制，下面我們來了解JWT。

JWT.io 對JSON Web Tokens進(jìn)行了很好的介紹，

國內(nèi)阮一峰的 《JSON Web Token 入門教程》 也講得非常好懂，可以出門右拐了解一下。

簡而言之，它是一個簽名的JSON對象，可以執(zhí)行一些有用的操作（例如，身份驗(yàn)證）。它是一組字串，分Header（頭部）、Payload（負(fù)載）、Signature（簽名）三部分，由'.'號連接，看起來就像下面這樣：

用戶發(fā)送認(rèn)證信息給服務(wù)端后，服務(wù)端通過JWT生成規(guī)則，生成JWT字串作為Token發(fā)放給用戶，用戶以后每次訪問都在HTTP Header攜帶JWT字串，已達(dá)到鑒權(quán)目的。由于其內(nèi)部攜帶用戶信息，部分使用者已經(jīng)發(fā)現(xiàn)其安全隱患，但其安全度不至于太過容易破解，在移動應(yīng)用中的鑒權(quán)機(jī)制使用較多，除此之外，一些分布式的微服務(wù)應(yīng)用也通過JWT進(jìn)行模塊間的鑒權(quán)，還是有一定的使用場景的。

Go開源社區(qū)已有比較成熟的JWT包實(shí)現(xiàn)： jwt-go ，內(nèi)附有JWT編解碼的使用用例，還是很好懂的，感興趣的可get來使用。在另一篇中也做了Go 使用JWT鑒權(quán)的示例： 《Go 鑒權(quán)（三）：JWT》 ,感興趣可閱讀以下，自己也在項(xiàng)目中實(shí)踐一下。

OAUTH協(xié)議為用戶資源的授權(quán)提供了一個安全的、開放而又簡易的標(biāo)準(zhǔn)。同時，任何第三方都可以使用OAUTH認(rèn)證服務(wù)，任何服務(wù)提供商都可以實(shí)現(xiàn)自身的OAUTH認(rèn)證服務(wù)，因而OAUTH是開放的。

OpenID Connect 是 OAuth 2.0 具體實(shí)現(xiàn)中的一個標(biāo)準(zhǔn)。它使用簡單的 REST 調(diào)用，因?yàn)樘岣吡似湟子眯?。對于一個面向公眾的網(wǎng)站，你或許可以使用Google、Facebook、Github等作為提供者，國內(nèi)可以使用QQ、微信、淘寶等作為提供者。但對于內(nèi)部系統(tǒng)，或?qū)τ跀?shù)據(jù)需要有更多控制權(quán)的系統(tǒng)而言，你會希望有自己的內(nèi)部身份提供者。

OAuth2.0有四種授權(quán)模式，具體可看阮一峰的 《理解OAuth2.0》 ,其內(nèi)容非常詳細(xì)且好理解。

我們這里說一下最完整的授權(quán)碼模式：

以上為OAuth2.0的認(rèn)證過程。

各大廠都有提供基于OAuth2.0的三方授權(quán)服務(wù)，如QQ、微信、淘寶等等，有需要可移步到各自的開放平臺查看文檔，大都有提供Go的接口實(shí)現(xiàn)；另你也可參考使用Go官方提供實(shí)現(xiàn)的包 ，里面包含多數(shù)熱門的OAuth客戶端。

推薦使用 這個開源項(xiàng)目，幫助你構(gòu)建自己的OAuth服務(wù)