golang設備通訊服務,golang web伺服器

本文目錄一覽：

• 1、go語言實現一個簡單的簡單網關
• 2、golang有哪些不錯的遊戲伺服器框架
• 3、golang中怎麼處理socket長連接
• 4、深入理解golang
• 5、如何在兩個golang 程序中ipc息通信
• 6、golang socket通信 怎麼把一個客戶端發送的數據推送給其他客戶端

go語言實現一個簡單的簡單網關

網關=反向代理+負載均衡+各種策略，技術實現也有多種多樣，有基於 nginx 使用 lua 的實現，比如 openresty、kong；也有基於 zuul 的通用網關；還有就是 golang 的網關，比如 tyk。

這篇文章主要是講如何基於 golang 實現一個簡單的網關。

轉自： troy.wang/docs/golang/posts/golang-gateway/

整理：go語言鍾文文檔:

啟動兩個後端 web 服務（代碼）

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

具體代碼

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

具體代碼

director中定義回調函數，入參為*http.Request，決定如何構造向後端的請求，比如 host 是否向後傳遞，是否進行 url 重寫，對於 header 的處理，後端 target 的選擇等，都可以在這裡完成。

director在這裡具體做了：

modifyResponse中定義回調函數，入參為*http.Response，用於修改響應的信息，比如響應的 Body，響應的 Header 等信息。

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

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

作為一個網關服務，在上面 2.3 的基礎上，需要支持必要的負載均衡策略，比如：

隨便 random 一個整數作為索引，然後取對應的地址即可，實現比較簡單。

具體代碼

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

具體代碼

輪詢帶權重，如果使用計數遞減的方式，如果權重是5,1,1那麼後端 rs 依次為a,a,a,a,a,b,c,a,a,a,a…，其中 a 後端會瞬間壓力過大；參考 nginx 內部的加權輪詢，或者應該稱之為平滑加權輪詢，思路是：

後端真實節點包含三個權重：

操作步驟：

具體代碼

一致性 hash 演算法，主要是用於分散式 cache 熱點/命中問題；這裡用於基於某 key 的 hash 值，路由到固定後端，但是只能是基本滿足流量綁定，一旦後端目標節點故障，會自動平移到環上最近的那麼個節點。

實現：

具體代碼

每一種不同的負載均衡演算法，只需要實現添加以及獲取的介面即可。

然後使用工廠方法，根據傳入的參數，決定使用哪種負載均衡策略。

具體代碼

作為網關，中間件必不可少，這類包括請求響應的模式，一般稱作洋蔥模式，每一層都是中間件，一層層進去，然後一層層出來。

中間件的實現一般有兩種，一種是使用數組，然後配合 index 計數；一種是鏈式調用。

具體代碼

golang有哪些不錯的遊戲伺服器框架

為什麼golang的開發效率高？

golang是一編譯型的強類型語言，它在開發上的高效率主要來自於後發優勢，不用考慮舊有噁心的歷史，又有一個較高的工程視角。良好的避免了程序員因為「 { 需不需要獨佔一行 」這種革命問題打架，也解決了一部分趁編譯時間找產品妹妹搭訕的階級敵人。

它有自己的包管理機制，工具鏈成熟，從開發、調試到發布都很簡單方便；

有反向介面、defer、coroutine等大量的syntactic sugar；

編譯速度快，因為是強類型語言又有gc，只要通過編譯，非業務毛病就很少了；

它在語法級別上支持了goroutine，這是大家說到最多的內容，這裡重點提一下。首先，coroutine並不稀罕，語言並不能超越硬體、操作系統實現神乎其神的功能。golang可以做到事情，其他語言也可以做到，譬如c++，在boost庫裡面自己就有的coroutine實現（當然用起來跟其他boost庫一樣噁心）。golang做的事情，是把這一套東西的使用過程簡化了，並且提供了一套channel的通信模式，使得程序員可以忽略諸如死鎖等問題。

goroutine的目的是描述並發編程模型。並發與並行不同，它並不需要多核的硬體支持，它不是一種物理運行狀態，而是一種程序邏輯流程。它的主要目的不是利用多核提高運行效率，而是提供一種更容易理解、不容易出錯的語言來描述問題。

實際上golang默認就是運行在單OS進程上面的，通過指定環境變數GOMAXPROCS才能轉身跑在多OS進程上面。有人提到了的pomelo，開源本來是一件很不錯的事情，但是基於自己對callback hell的偏見，我一直持有這種態度：敢用nodejs寫大規模遊戲伺服器的人，都是真正的勇士 : ) 。

2、Erlang與Golang的coroutine有啥區別，coroutine是啥？

coroutine本質上是語言開發者自己實現的、處於user space內的線程，無論是erlang、還是golang都是這樣。需要解決沒有時鐘中斷；碰著阻塞式i\o，整個進程都會被操作系統主動掛起；需要自己擁有調度控制能力（放在並行環境下面還是挺麻煩的一件事）等等問題。那為啥要廢老大的勁自己做一套線程放user space裡面呢？

並發是伺服器語言必須要解決的問題；

system space的進程還有線程調度都太慢了、佔用的空間也太大了。

把線程放到user space的可以避免了陷入system call進行上下文切換以及高速緩衝更新，線程本身以及切換等操作可以做得非常的輕量。這也就是golang這類語言反覆提及的超高並發能力，分分鐘給你開上幾千個線程不費力。

不同的是，golang的並發調度在i/o等易發阻塞的時候才會發生，一般是內封在庫函數內；erlang則更誇張，對每個coroutine維持一個計數器，常用語句都會導致這個計數器進行reduction，一旦到點，立即切換調度函數。

中斷介入程度的不同，導致erlang看上去擁有了preemptive scheduling的能力，而golang則是cooperative shceduling的。golang一旦寫出純計算死循環，進程內所有會話必死無疑；要有大計算量少i\o的函數還得自己主動叫runtime.Sched()來進行調度切換。

3、golang的運行效率怎麼樣？

我是相當反感所謂的ping\pong式benchmark，運行效率需要放到具體的工作環境下面考慮。

首先，它再快也是快不過c的，畢竟底下做了那麼多工作，又有調度，又有gc什麼的。那為什麼在那些benchmark裡面，golang、nodejs、erlang的響應效率看上去那麼優秀呢，響應快，並發強？並發能力強的原因上面已經提到了，響應快是因為大量非阻塞式i\o操作出現的原因。這一點c也可以做到，並且能力更強，但是得多寫不少優質代碼。

然後，針對遊戲伺服器這種高實時性的運行環境，GC所造成的跳幀問題確實比較麻煩，前面的大神 @達達 有比較詳細的論述和緩解方案，就不累述了 。隨著golang的持續開發，相信應該會有非常大的改進。一是屏蔽內存操作是現代語言的大勢所趨，它肯定是需要被實現的；二是GC演算法已經相當的成熟，效率勉勉強強過得去；三是可以通過incremental的操作來均攤cpu消耗。

用這一點點效率損失換取一個更高的生產能力是不是值得呢？我覺得是值得的，硬體已經很便宜了，人生苦短，讓自己的生活更輕鬆一點吧: )。

4、基於以上的論述，我認為採用go進行小範圍的MMORPG開發是可行的。

golang中怎麼處理socket長連接

實際上需要 3 個 goroutine，一個 read，一個 send，還有一個 handle。

read goroutine 讀，然後寫入 recevice chan。

write goroutine 把 send chan 的東西寫。

handle goroutine 是 conn 的主要處理邏輯，負責把 recevice chan 的東西讀出來 call 業務邏輯。

業務邏輯中要寫數據就直接寫入 send chan。

這樣就可以保證，業務邏輯的讀寫都是在 handle goroutine 上處理，而避免 race 產生。

如果需要定時任務（比如心跳），就在 handle goroutine 上加上一個 timer.C；

如果需要 goroutine 下發任務，在 handle goroutine 增加一個 task chan，hanlde 收到 task 後處理業務；

如果需要輸出結果，那就增加 result chan，業務邏輯把數據輸出即可。

—————————-

還有，如果我開2個goroutine的話，client斷開連接了，假設recv goroutine先發生err並且close(fd)，那在send goroutine中該如何處理呢？有可能不應該這樣處理，那應該怎麼處理呢？

如果 net.Conn Close() 了，不論 Read() 阻塞還是 Write() 阻塞都會立即收到 err 返回。

一般來說，Write() 是不可能主動知道連接斷開的，除非是 SetDeadline() 猜測對方斷掉了，指定時間內沒有寫成功就認為是斷開。Read() 是可以主動收到對方發來的斷開（TCP FIN），但也沒辦法知道異常的斷開（當然也可以設置超時）。

無論是誰，是確實收到 FIN 還是 Deadline 猜測斷開，只要 Close() 大家就知道連接斷開了。

handle goroutine 還有一個用處就是：你的程序主動結束的時候，能正確的 close conn，讓對方知道你是真的斷開了，而不用去猜。

深入理解golang

最近三年，在工作中使用go開發了不少服務。深感go的便捷，以及它的runtime的複雜。我覺得需要定期的進行總結，因此決定寫這篇文章，也許更準確的，應該叫筆記。

最近終於解決了一個和cgo有關的問題。這個問題從發現到解決前後經歷了接近4個月，當然，和人手不足也有關係。而對於我個人而言，這個問題其實歷時2年！這得從頭說起。

在上一家公司的一個項目里，有一個服務做音視頻數據的提取，這個服務運行在嵌入式設備TX2上。音視頻提取這一關鍵功能主要利用nvidia基於gstreamer開發的插件，這個插件可以發揮nvidia gpu的硬體解碼功能。當時這個服務使用go和c混編的方式，問題的癥狀是服務運行一段時間後，不輸出音視頻數據。遺憾的是，由於疫情，項目停止，因此沒有機會繼續研究這個問題。

時間來到去年底。當前這個項目進行壓力測試，發現關鍵的語音處理服務運行一段時間後，會出現不拉流的情況，因此也沒有後續的結果輸出。癥狀和上一個項目非常像。雖然使用的第三方SDK不一樣，但同樣用了go和c混編的方式。一開始，焦點就放在go的運行時上，覺得可能是go和c相互調用的方式不對。經過合理猜測，並用測試進行驗證後，發現問題還是在第三方拉流的SDK上，它們的回調函數必須要快，否則有可能會阻塞它們的回調線程。當然，在go調用c的時候，如果耗時比較長，會對go的運行時造成一些副作用；在c回調go的時候，go的運行時也有可能阻塞c的回調線程。但go的運行時已經比較成熟，因此我覺得它對這個問題的貢獻不大。以上採用了假設-驗證的方法，主要的原因還是第三方的拉流SDK不開源。在定位問題的過程中，使用了gdb的gcore來生成堆棧；也搭建了灰度環境來進行壓力測試，以及完善監控，這些都是解決方法的一部分。

正是這一問題，促使我更多的了解go的運行時。而我看得越多，越覺得go的運行時是一個龐大的怪物。因此，抱著能了解一點是一點的心態，不斷的完善這篇筆記。

如何在兩個golang 程序中ipc息通信

通訊是可以的。 1、exe中作為服務端，創建對象調用dll介面，然後把委託函數傳過去。 2、exe調用dll介面方法, 當該dll介面方法做到其中一個步驟後，就調用委託函數，把信息傳回 來給exe 3、這樣就能實現通訊

golang socket通信 怎麼把一個客戶端發送的數據推送給其他客戶端

Socket通信的原理還是比較簡單的， 它大致分為以下幾個步驟。 伺服器端的步驟如下。 （1）建立伺服器端的Socket，開始偵聽整個網路中的連接請求。 （2）當檢測到來自客戶端的連接請求時，向客戶端發送收到連接請求的信息，並建立與客戶端之間的…