go語言實現(xiàn)一個簡單的簡單網(wǎng)關(guān)

網(wǎng)關(guān)=反向代理+負載均衡+各種策略，技術(shù)實現(xiàn)也有多種多樣，有基于 nginx 使用 lua 的實現(xiàn)，比如 openresty、kong；也有基于 zuul 的通用網(wǎng)關(guān)；還有就是 golang 的網(wǎng)關(guān)，比如 tyk。

成都創(chuàng)新互聯(lián)：2013年至今為各行業(yè)開拓出企業(yè)自己的“網(wǎng)站建設(shè)”服務(wù)，為上千公司企業(yè)提供了專業(yè)的網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、網(wǎng)頁設(shè)計和網(wǎng)站推廣服務(wù)， 定制網(wǎng)站設(shè)計由設(shè)計師親自精心設(shè)計，設(shè)計的效果完全按照客戶的要求，并適當?shù)奶岢龊侠淼慕ㄗh，擁有的視覺效果，策劃師分析客戶的同行競爭對手，根據(jù)客戶的實際情況給出合理的網(wǎng)站構(gòu)架，制作客戶同行業(yè)具有領(lǐng)先地位的。

這篇文章主要是講如何基于 golang 實現(xiàn)一個簡單的網(wǎng)關(guān)。

轉(zhuǎn)自： troy.wang/docs/golang/posts/golang-gateway/

整理：go語言鐘文文檔:

啟動兩個后端 web 服務(wù)（代碼）

這里使用命令行工具進行測試

具體代碼

直接使用基礎(chǔ)庫 httputil 提供的NewSingleHostReverseProxy即可，返回的reverseProxy對象實現(xiàn)了serveHttp方法，因此可以直接作為 handler。

具體代碼

director中定義回調(diào)函數(shù)，入?yún)?http.Request，決定如何構(gòu)造向后端的請求，比如 host 是否向后傳遞，是否進行 url 重寫，對于 header 的處理，后端 target 的選擇等，都可以在這里完成。

director在這里具體做了：

modifyResponse中定義回調(diào)函數(shù)，入?yún)?http.Response，用于修改響應(yīng)的信息，比如響應(yīng)的 Body，響應(yīng)的 Header 等信息。

最終依舊是返回一個ReverseProxy，然后將這個對象作為 handler 傳入即可。

參考 2.2 中的NewSingleHostReverseProxy，只需要實現(xiàn)一個類似的、支持多 targets 的方法即可，具體實現(xiàn)見后面。

作為一個網(wǎng)關(guān)服務(wù)，在上面 2.3 的基礎(chǔ)上，需要支持必要的負載均衡策略，比如：

隨便 random 一個整數(shù)作為索引，然后取對應(yīng)的地址即可，實現(xiàn)比較簡單。

具體代碼

使用curIndex進行累加計數(shù)，一旦超過 rss 數(shù)組的長度，則重置。

具體代碼

輪詢帶權(quán)重，如果使用計數(shù)遞減的方式，如果權(quán)重是5,1,1那么后端 rs 依次為a,a,a,a,a,b,c,a,a,a,a…，其中 a 后端會瞬間壓力過大；參考 nginx 內(nèi)部的加權(quán)輪詢，或者應(yīng)該稱之為平滑加權(quán)輪詢，思路是：

后端真實節(jié)點包含三個權(quán)重：

操作步驟：

具體代碼

一致性 hash 算法，主要是用于分布式 cache 熱點/命中問題；這里用于基于某 key 的 hash 值，路由到固定后端，但是只能是基本滿足流量綁定，一旦后端目標節(jié)點故障，會自動平移到環(huán)上最近的那么個節(jié)點。

實現(xiàn)：

具體代碼

每一種不同的負載均衡算法，只需要實現(xiàn)添加以及獲取的接口即可。

然后使用工廠方法，根據(jù)傳入的參數(shù)，決定使用哪種負載均衡策略。

具體代碼

作為網(wǎng)關(guān)，中間件必不可少，這類包括請求響應(yīng)的模式，一般稱作洋蔥模式，每一層都是中間件，一層層進去，然后一層層出來。

中間件的實現(xiàn)一般有兩種，一種是使用數(shù)組，然后配合 index 計數(shù)；一種是鏈式調(diào)用。

具體代碼

WebSocket+SLB（負載均衡）會話保持解決重連問題

寫在最前面：由于現(xiàn)在游戲基本上采用全球大區(qū)的模式，全球玩家在同一個大區(qū)進行游戲，傳統(tǒng)的單服模式已經(jīng)不能夠滿足當前的服務(wù)需求，所以現(xiàn)在游戲服務(wù)器都在往微服務(wù)架構(gòu)發(fā)展。當前我們游戲也是利用微服務(wù)架構(gòu)來實現(xiàn)全球玩家同服游戲。

玩家每次斷線（包括切換網(wǎng)絡(luò)/超時斷線）后應(yīng)該會重新連接服務(wù)器，重連成功的話可以繼續(xù)當前情景繼續(xù)游戲，但是之前寫的底層重連機制一直不能生效，導致每次玩家斷線后重連都失敗，要從賬號登陸開始重新登陸，該文章寫在已經(jīng)定位了重連問題是由SLB引起后，提出的解決方案。

每次重連后，客戶端向SLB發(fā)送建立連接，SLB都會重新分配一個網(wǎng)關(guān)節(jié)點，導致客戶端連接到其他網(wǎng)關(guān)，重連失敗。

會話保持的作用是什么？

開啟SLB會話保持功能后，SLB會記錄客戶端的IP地址，在一定時間內(nèi)，自動將同一個IP的連接轉(zhuǎn)發(fā)到上次連接的網(wǎng)關(guān)。

在網(wǎng)絡(luò)不穩(wěn)定的情況下，游戲容易心跳或者發(fā)包超時，開啟會話保持，能解決大部分情況下的重連問題。

但是在切換網(wǎng)絡(luò)的時候，手機網(wǎng)絡(luò)從Wifi切換成4G，自身IP會變，這時候連接必定和服務(wù)器斷開，需要重新建立連接。由于IP已經(jīng)變化，SLB不能識別到是同一個客戶端發(fā)出的請求，會將連接轉(zhuǎn)發(fā)到其他網(wǎng)關(guān)節(jié)點。所以使用TCP連接的情況下，SLB開啟會話保持并不能解決所有的重連問題。

另外某些時刻，手機頻繁開啟和斷開WI-FI，有時候可能不會斷開網(wǎng)絡(luò)，這并不是因為4G切換WI-FI時網(wǎng)絡(luò)沒斷開，從4G切換到Wi-Fi網(wǎng)絡(luò)，因為IP變了，服務(wù)器不能識別到新的IP，連接肯定是斷開的。這時候網(wǎng)絡(luò)沒斷開，主要是因為現(xiàn)在智能手機會對4G和Wi-Fi網(wǎng)絡(luò)做個權(quán)重判斷，當Wi-Fi網(wǎng)絡(luò)頻繁打開關(guān)閉時，手機會判斷Wi-Fi網(wǎng)絡(luò)不穩(wěn)定，所有流量都走4G。所以網(wǎng)絡(luò)沒斷開是因為一直使用4G連接，才沒有斷開。想要驗證，只需要切換Wi-Fi時，把4G網(wǎng)絡(luò)關(guān)閉，這樣流量就必定走Wi-Fi。

上面說過，四層的TCP協(xié)議主要是基于IP來實現(xiàn)會話保持。但是切換網(wǎng)絡(luò)的時候客戶端的IP會變。所以要解決切換網(wǎng)絡(luò)時的重連問題，只有兩個方法：1. 當客戶端成功連接網(wǎng)關(guān)節(jié)點后，記錄下網(wǎng)關(guān)節(jié)點的IP，下次重連后不經(jīng)過SLB，直接向網(wǎng)關(guān)節(jié)點發(fā)送連接請求。2.使用 SLB的七層（HTTP）轉(zhuǎn)發(fā)服務(wù)。

當客戶端經(jīng)過SLB將連接轉(zhuǎn)發(fā)到網(wǎng)關(guān)時，二次握手驗證成功后向客戶端發(fā)送自己節(jié)點的IP，這樣客戶端下次連接的時候就能直接連接網(wǎng)關(guān)節(jié)點。但是這樣會暴露網(wǎng)關(guān)的IP地址，為安全留下隱患。

如果不希望暴露網(wǎng)關(guān)的IP地址，就需要增加一層代理層，SLB將客戶端請求轉(zhuǎn)發(fā)到代理層，代理層再根據(jù)客戶端帶有的key，轉(zhuǎn)發(fā)到正確的網(wǎng)關(guān)節(jié)點上。增加一層代理層，不僅會增加請求的響應(yīng)時間，還會增加整體框架的復雜度。

阿里云的七層SLB會話保持服務(wù)，主要是基于cookie的會話保持?？蛻舳嗽谕?wù)器發(fā)送HTTP請求后，服務(wù)器會返回客戶端一個Response，SLB會在這時候，將經(jīng)過的Response插入或者重寫cookie?？蛻舳双@取到這個cookie，下次請求時會帶上cookie，SLB判斷Request的Headers里面有cookie，就將連接轉(zhuǎn)發(fā)到之前的網(wǎng)關(guān)節(jié)點。

HTTP是短鏈接，我們游戲是長連接，所以用HTTP肯定不合適。但是可以考慮基于HTTP的WebSocket。

什么是WebSocket？

WSS（Web Socket Secure）是WebSocket的加密版本。

SLB對WebSocket的支持

查看阿里云SLB文檔對WS的支持，說明SLB是支持WS協(xié)議的，并且SLB對于WS無需配置，只需要選用HTTP監(jiān)聽時，就能夠轉(zhuǎn)發(fā)WS協(xié)議。說明WS協(xié)議在SLB這邊看來就是一個HTTP，這樣WS走的也是七層的轉(zhuǎn)發(fā)服務(wù)。只要SLB能夠正常識別WS握手協(xié)議里Request的cookie和正常識別服務(wù)器返回的Response并且往里面插入cookie，就可以利用會話保持解決重連問題。

Go語言實現(xiàn)WS服務(wù)器有兩種方法，一種是利用golang.org/x/net下的websocket包，另外一種方法就是自己解讀Websocket協(xié)議來實現(xiàn)，由于WS協(xié)議一樣是基于TCP協(xié)議之上，完全可以通過監(jiān)聽TCP端口來實現(xiàn)。

客戶端發(fā)送Request消息

服務(wù)器返回Response消息

其中服務(wù)器返回的Sec-WebSocket-Accept字段，主要是用于客戶端需要驗證服務(wù)器是否支持WS。RFC6455文檔中規(guī)定，在WebSocket通信協(xié)議中服務(wù)端為了證實已經(jīng)接收了握手，它需要把兩部分的數(shù)據(jù)合并成一個響應(yīng)。一部分信息來自客戶端握手的Sec-WebSocket-Keyt頭字段：Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==。對于這個字段，服務(wù)端必須得到這個值（頭字段中經(jīng)過base64編碼的值減去前后的空格）并與GUID"258EAFA5-E914-47DA-95CA-C5AB0DC85B11"組合成一個字符串，這個字符串對于不懂WebSocket協(xié)議的網(wǎng)絡(luò)終端來說是不能使用的。這個組合經(jīng)過SHA-1掩碼，base64編碼后在服務(wù)端的握手中返回。如果這個Sec-WebSocket-Accept計算錯誤瀏覽器會提示：Sec-WebSocket-Accept dismatch

如果返回成功，Websocket就會回調(diào)onopen事件

游戲服務(wù)器的使用的TCP協(xié)議，是在協(xié)議的包頭使用4Byte來聲明本協(xié)議長度，然后將協(xié)議一次性發(fā)送。但是在WS協(xié)議是通過Frame形式發(fā)送的，會將一條消息分為幾個frame，按照先后順序傳輸出去。這樣做會有幾個好處：

websocket的協(xié)議格式：

參數(shù)說明如下：

阿里云的SLB開啟HTTP監(jiān)聽后，會檢查過往的Request和Response請求，收到服務(wù)器返回的Response后，會往Response插入一個Cookie

客戶端收到服務(wù)器的Response后，可以在Header中查到有個“Set-Cookie”字段，里面是SLB插入的Cookie值

客戶端斷開連接后，下次發(fā)送請求需要往Headers插入Cookie字段

分別在阿里云的兩臺ECS實例上部署WS服務(wù)器，打開8000端口，開啟一個SLB服務(wù)，SLB服務(wù)選擇HTTP方式監(jiān)聽，并且打開會話保持功能，Cookie處理方式選擇植入Cookie。Demo服務(wù)器沒有做HTTP健康監(jiān)聽的處理，健康檢查這塊可以先關(guān)掉。

在兩臺ECS上啟動WS服務(wù)器，然后本地運行客戶端，分別測試兩臺服務(wù)器是否能正常連接，測試完畢后，測試SLB能否正常工作。服務(wù)器和SLB都正常的情況下，運行客戶端，客戶端會得到以下結(jié)果

收到的三次Cookie都相同，說明Cookie是有正常植入工作的，并且三次都被SLB正確抓取了。

收到的三次serverId也都是同樣的值，說明三次都是同一個ECS上的服務(wù)器響應(yīng)。

至此，驗證成功。

Websocket+SLB會話保持能夠解決超時重連和切換網(wǎng)絡(luò)時重連的問題。

參考：

阿里云會話保持

解答Wi-Fi與4G網(wǎng)絡(luò)切換的困惑

WebSocket的實現(xiàn)原理

阿里云SLB對WebSocket的支持

HTTP Headers和Cookie

Go微服務(wù)--常見的微服務(wù)框架

近幾年誕生了很多微服務(wù)框架，比如JAVA的Spring Cloud、Dubbo;Golang的GoKit和GoMicro以及NodeJs的Seneca。幾乎每種主流語言都有其對應(yīng)的微服務(wù)框架。

Go在微服務(wù)框架中有其獨特的優(yōu)勢，至于優(yōu)勢在哪，自行g(shù)oogle。

1、GoKit框架

這是一個工具包的集合，可以幫助攻城獅構(gòu)建強大、可靠和可維護的微服務(wù)。提供了用于實現(xiàn)系統(tǒng)監(jiān)控和彈性模式組件的庫，例如日志、跟蹤、限流、熔斷等。

基于這個框架的應(yīng)用程序架構(gòu)由三個主要的部分組成：

傳輸層：用于網(wǎng)絡(luò)通信，服務(wù)通常使用HTTP或者gRPC等網(wǎng)絡(luò)傳輸協(xié)議，或者使用NATS等發(fā)布訂閱系統(tǒng)相互通信。

接口層：是服務(wù)器和客戶端的基本構(gòu)建塊。每個對外提供的接口方法都會定義為一個Endpoint，一遍在服務(wù)器和客戶端之間進行網(wǎng)絡(luò)通信，每個端點使用傳輸層通過HTTP或gRPC等具體通信模式對外提供服務(wù)

服務(wù)成：具體的業(yè)務(wù)邏輯實現(xiàn)

2、GoMicro框架

這是一個基于Go語言實現(xiàn)的插件化RPC微服務(wù)框架。提供了服務(wù)發(fā)現(xiàn)、負載均衡、同步傳輸、異步通信以及事件驅(qū)動等機制，嘗試簡化分布式系統(tǒng)之間的通信，讓開發(fā)者更專注于自身業(yè)務(wù)邏輯的開發(fā)。

GoMicro的設(shè)計哲學是可插拔的架構(gòu)理念，提供了可快速構(gòu)建系統(tǒng)的組件，并且可以根據(jù)自身的需求對GoMicro提供的默認實現(xiàn)進行定制。所有插件都可在倉庫github.com/micro/go-plugins 中找到。

網(wǎng)站名稱：go語言負載均衡 負載均衡getshell
網(wǎng)站路徑：http://m.rwnh.cn/article12/dosgogc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供定制網(wǎng)站、、做網(wǎng)站、營銷型網(wǎng)站建設(shè)、網(wǎng)站設(shè)計、定制開發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)