建站
咨詢
售后
建站咨詢
新聞中心
基于go的websocket消息推送的集群實現(xiàn)
目前websocket技術已經很成熟，選型Go語言，當然是為了節(jié)省成本以及它強大的高并發(fā)性能。我使用的是第三方開源的websocket庫即gorilla/websocket。
成都創(chuàng)新互聯(lián)公司是一家集網站建設,迭部企業(yè)網站建設,迭部品牌網站建設,網站定制,迭部網站建設報價,網絡營銷,網絡優(yōu)化,迭部網站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強企業(yè)競爭力。可充分滿足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學習、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網站。
由于我們線上推送的量不小，推送后端需要部署多節(jié)點保持高可用，所以需要自己做集群，具體架構方案如圖：
Auth Service：鑒權服務，根據(jù)Token驗證用戶權限。
Collect Service：消息采集服務，負責收集業(yè)務系統(tǒng)消息，存入MongoDB后，發(fā)送給消息分發(fā)服務。
Dispatch Service：消息分發(fā)服務，根據(jù)路由規(guī)則分發(fā)至對應消息推送服務節(jié)點上。
Push Service：消息推送服務，通過websocket將消息推送給用戶。
集群推送的關鍵點在于，web端與服務端建立長連接之后，具體跟哪個推送節(jié)點保持長連接的，如果我們能夠找到對應的連接節(jié)點，那么我們就可以將消息推送出去。下面講解一下集群的大致流程：
1. web端用戶登錄之后，帶上token與后端推送服務（Push Service）保持長連接。
2. 推送服務收到連接請求之后，攜帶token去鑒權服務（Auth Service）驗證此token權限，并返回用戶ID。
3. 把返回的用戶ID與長連接存入本地緩存，保持用戶ID與長連接綁定關系。
4. 再將用戶ID與本推送節(jié)點IP存入redis，建立用戶（即長連接）與節(jié)點綁定關系，并設置失效時間。
5. 采集服務（Collect Service）收集業(yè)務消息，首先存入mongodb，然后將消息透傳給分發(fā)服務（Dispatch Service）。
6. 分發(fā)服務收到消息之后，根據(jù)消息體中的用戶ID，從redis中獲取對應的推送服務節(jié)點IP，然后轉發(fā)給對應的推送節(jié)點。
7. 推送服務節(jié)點收到消息之后，根據(jù)用戶ID，從本地緩存中取出對應的長連接，將消息推送給客戶端。
其他注意事項：
15 Go 鑒權（一）：鑒權機制概述
在現(xiàn)代web開發(fā)中，系統(tǒng)鑒權服務已是基本標配模塊，有些開發(fā)框架甚至內置了鑒權模塊的實現(xiàn)，或者提供一些鑒權的工具類，然而鑒權的方式也分為多種，了解各種鑒權方式的特點及使用場景可以幫助我們構建更健壯的web系統(tǒng)。以下列出四種常見的鑒權方式，我們來認識一下：
HTTP 基本身份驗證，允許客戶端在標準的 HTTP 頭中發(fā)送用戶名和密碼。服務端可以驗證這些信息，并確認客戶端是否有權訪問服務。這樣做的好處在于，這是一種非常容易理解且得到廣泛支持的協(xié)議。問題在于，通過 HTTP 有很高的風險，因為用戶名和密碼并沒有以安全的方式發(fā)送。任何中間方都可以看到 HTTP 頭的信息并讀取里面的數(shù)據(jù)。因此，HTTP 基本身份驗證通常應該通過 HTTPS 進行通信。
當使用 HTTPS 時，客戶端獲得強有力的保證，它所通信的服務端就是客戶端想要通信的服務端。它給予我們額外的保護，避免人們竊聽客戶端和服務端之間的通信，或篡改有效負載。
服務端需要管理自己的SSL證書，當需要管理多臺機器時會出現(xiàn)問題。一些組織自己承擔簽發(fā)證書的過程，這是一個額外的行政和運營負擔。管理這方面的自動化工具遠不夠成熟，使用它們后你會發(fā)現(xiàn)，需要自己處理的事情就不止證書簽發(fā)了。自簽名證書不容易撤銷，因此需要對災難情景有更多的考慮。看看你是否能夠避免自簽名，以避開所有的這些工作。
SSL 之上的流量不能被反向代理服務器（比如 Varnish 或 Squid）所緩存，這是使用 HTTPS 的另一個缺點。這意味著，如果你需要緩存信息，就不得不在服務端或客戶端內部實現(xiàn)。你可以在負載均衡中把 Https 的請求轉成 Http 的請求，然后在負載均衡之后就可以使用緩存了。
還需要考慮，如果我們已經在使用現(xiàn)成的 SSO 方案（比如包含用戶名密碼信息的 SAML），該怎么辦。我們想要基本身份驗證使用同一套認證信息，然后在同一個進程里頒發(fā)和撤銷嗎？讓服務與實現(xiàn) SSO 所使用的那個目錄服務進行通信即可做到這一點。或者，我們可以在服務內部存儲用戶名和密碼，但需要承擔存在重復行為的風險。
注意：使用這種方法，服務器只知道客戶端有用戶名和密碼。我們不知道這個信息是否來自我們期望的機器；它可能來自網絡中的其他人。
HTTP 基本身份驗證是一種簡單但不那么安全的認證方式，不太建議用于公開的商業(yè)應用，在此便不再展開，我們關注以下幾種認證方式。
http協(xié)議是一種無狀態(tài)的協(xié)議，如果沒有任何認證機制，服務端對任何客戶端的請求都是無差別的。在Web2.0時代，為了加強B/S交互的安全性，衍生出了Session-Cookie鑒權機制，通過在服務端開啟會話，客戶端存儲SessionID，在每次請求時通過cookie傳輸SessionID的形式實現(xiàn)服務端基本鑒權。
cookie是保存在本地終端的數(shù)據(jù)。cookie由服務器生成，發(fā)送給瀏覽器，瀏覽器把cookie以kv形式保存到某個目錄下的文本文件內，下一次請求同一網站時會把該cookie發(fā)送給服務器。由于cookie是存在客戶端上的，所以瀏覽器加入了一些限制確保cookie不會被惡意使用，同時不會占據(jù)太多磁盤空間，所以每個域的cookie數(shù)量是有限的。
cookie的組成有：名稱(key)、值(value)、有效域(domain)、路徑(域的路徑，一般設置為全局:"")、失效時間、安全標志(指定后，cookie只有在使用SSL連接時才發(fā)送到服務器(https))。
Session的中文翻譯是“會話”，當用戶打開某個web應用時，便與web服務器產生一次session。服務器使用session把用戶的信息臨時保存在了服務器上，用戶離開網站后session會被銷毀。這種用戶信息存儲方式相對cookie來說更安全，可是session有一個缺陷：如果web服務器做了負載均衡，那么下一個操作請求到了另一臺服務器的時候session會丟失。
當程序需要為某個客戶端的請求創(chuàng)建一個session時，服務器首先檢查這個客戶端的請求里是否已包含了一個session標識（稱為SessionID），如果已包含則說明以前已經為此客戶端創(chuàng)建過Session，服務器就按照SessionID把這個Session檢索出來使用（檢索不到，會新建一個），如果客戶端請求不包含SessionID，則為此客戶端創(chuàng)建一個Session并且生成一個與此Session相關聯(lián)的SessionID，SessionID的值應該是一個既不會重復，又不容易被找到規(guī)律以仿造的字符串，這個SessionID將被在本次響應中返回給客戶端保存。
保存這個SessionID的方式可以采用Cookie，這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)揮給服務器。一般這個Cookie的名字都是類似于SEEESIONID。但Cookie可以被人為的禁止，則必須有其他機制以便在Cookie被禁止時仍然能夠把SessionID傳遞回服務器。
客戶端第一次發(fā)送請求給服務器，此時服務器啟動Session會話，產生一個唯一的SessionID，并通過Response的SetCookie返回給客戶端，保存于客戶端(一般為瀏覽器)，并與一個瀏覽器窗口對應著,由于HTTP協(xié)議的特性，這一次Request-Response
后連接就斷開了。以后此客戶端再發(fā)送請求給服務器的時候，就會在請求Request頭中攜帶cookie,由于cookie中帶有Key為sessionID的數(shù)據(jù),所以服務器就知道這是剛才那個客戶端。
正如我們前面所討論的，如果擔心用戶名和密碼被泄露，HTTP基本身份驗證使用普通 HTTP 并不是非常明智的。傳統(tǒng)的替代方式是使用HTTPS路由通信，但也有一些缺點。除了需要管理證書，HTTPS通信的開銷使得服務器壓力增加，而且通信難以被輕松地緩存。另外Session-Cookie機制也會有被客戶限制的隱患，如果用戶禁用Cookie則必須由其它方式實現(xiàn)鑒權。
所謂Token，即令牌。客戶端需要鑒權訪問私人信息時，會首次向服務端發(fā)送身份驗證信息（如用戶名、密碼），服務端校驗正確后會根據(jù)一定的加密算法生成Token令牌發(fā)放給客戶端，此后客戶端只需通過Token，服務端只需驗證Token就可識別客戶并進行交互，Token可存放于HTTP Header也可存放與Cookie。
以上為一個簡單的Token鑒權過程。
關于Token機制，業(yè)界有一種叫JWT（JsonWebToken）的實現(xiàn)機制，下面我們來了解JWT。
JWT.io 對JSON Web Tokens進行了很好的介紹，
國內阮一峰的 《JSON Web Token 入門教程》 也講得非常好懂，可以出門右拐了解一下。
簡而言之，它是一個簽名的JSON對象，可以執(zhí)行一些有用的操作（例如，身份驗證）。它是一組字串，分Header（頭部）、Payload（負載）、Signature（簽名）三部分，由'.'號連接，看起來就像下面這樣：
用戶發(fā)送認證信息給服務端后，服務端通過JWT生成規(guī)則，生成JWT字串作為Token發(fā)放給用戶，用戶以后每次訪問都在HTTP Header攜帶JWT字串，已達到鑒權目的。由于其內部攜帶用戶信息，部分使用者已經發(fā)現(xiàn)其安全隱患，但其安全度不至于太過容易破解，在移動應用中的鑒權機制使用較多，除此之外，一些分布式的微服務應用也通過JWT進行模塊間的鑒權，還是有一定的使用場景的。
Go開源社區(qū)已有比較成熟的JWT包實現(xiàn)： jwt-go ，內附有JWT編解碼的使用用例，還是很好懂的，感興趣的可get來使用。在另一篇中也做了Go 使用JWT鑒權的示例： 《Go 鑒權（三）：JWT》 ,感興趣可閱讀以下，自己也在項目中實踐一下。
OAUTH協(xié)議為用戶資源的授權提供了一個安全的、開放而又簡易的標準。同時，任何第三方都可以使用OAUTH認證服務，任何服務提供商都可以實現(xiàn)自身的OAUTH認證服務，因而OAUTH是開放的。
OpenID Connect 是 OAuth 2.0 具體實現(xiàn)中的一個標準。它使用簡單的 REST 調用，因為提高了其易用性。對于一個面向公眾的網站，你或許可以使用Google、Facebook、Github等作為提供者，國內可以使用QQ、微信、淘寶等作為提供者。但對于內部系統(tǒng)，或對于數(shù)據(jù)需要有更多控制權的系統(tǒng)而言，你會希望有自己的內部身份提供者。
OAuth2.0有四種授權模式，具體可看阮一峰的 《理解OAuth2.0》 ,其內容非常詳細且好理解。
我們這里說一下最完整的授權碼模式：
以上為OAuth2.0的認證過程。
各大廠都有提供基于OAuth2.0的三方授權服務，如QQ、微信、淘寶等等，有需要可移步到各自的開放平臺查看文檔，大都有提供Go的接口實現(xiàn)；另你也可參考使用Go官方提供實現(xiàn)的包 ，里面包含多數(shù)熱門的OAuth客戶端。
推薦使用 這個開源項目，幫助你構建自己的OAuth服務
Go 1.8使用Protocol Buffer
最近在寫一個在線客服模塊，秉著簡單，可控，可維護，可擴展，滿足需求的原則，找了一個開源項目： 。
當然對于原始項目，肯定還是需要一些改動的，比如：鑒權，用戶體系，文件類型消息的處理（存在阿里云OSS上）等等。
為了滿足需求，修改了原始的基于protocol buffer的message，修改后在重新生成對應的go文件時候，遇到了一些問題，可以參考以下解決方法。
github上的protobuf（ ）已經說明，需要使用： google.golang.org/protobuf 。
安裝官方文檔 安裝對應的插件模塊，mac需要在.zshrc文件添加以下內容：
以下是message proto文件：
執(zhí)行以下命令生產對應的go文件：
本文題目：go語言有鑒權嗎 go語言干嘛的
文章位置：http://www.ef60e0e.cn/article/ddsggoo.html
