golang模塊總結,golang知識點總結

本文目錄一覽：

• 1、golang 有哪些比較穩定的 web 開發框架
• 2、組件分享之後端組件——一款基於Golang的認證全套模塊Casdoor
• 3、深入理解golang
• 4、面試問題總結（一）Golang
• 5、Golang 遊戲leaf系列(六) Go模塊

golang 有哪些比較穩定的 web 開發框架

第一個：Beego框架

Beego框架是astaxie的GOWeb開發的開源框架。Beego框架最大的特點是由八個大的基礎模塊組成，八大基礎模塊的特點是可以根據自己的需要進行引入，模塊相互獨立，模塊之間耦合性低。

相應的Beego的缺點就是全部使用時比較臃腫，通過bee工具來構建項目時，直接生成項目目錄和耦合關係，從而會導致在項目開發過程中受制性較大。

第二個：Gin框架

Gin是一個GOlang的微框架，封裝比較優雅，API友好，源碼注釋比較明確，已經發佈了1.0版本;具有快速靈活、容錯方便等特點，其實對於golang而言，web框架的依賴遠比Python、Java更小。

目前在很多使用golang的中小型公司中進行業務開發，使用Gin框架的很多，大家如果想使用golang進行熟練Web開發，可以多關注一下這個框架。

第三個：Iris框架

Iris框架在其官方網站上被描述為GO開發中最快的Web框架，並給出了多框架和多語言之前的性能對比。目前在github上，Iris框架已經收穫了14433個star和1493個fork，可見是非常受歡迎的。

在實際開發中，Iris框架與Gin框架的學習曲線幾乎相同，所以掌握了Gin就可以輕鬆掌握Iris框架。

第四個：Echo框架

也是golang的微型Web框架，其具備快速HTTP路由器、支持擴展中間件，同時還支持靜態文件服務、Websocket以及支持制定綁定函數，制定相應渲染函數，並允許使用任意的HTML模版引擎。

組件分享之後端組件——一款基於Golang的認證全套模塊Casdoor

近期正在探索前端、後端、系統端各類常用組件與工具，對其一些常見的組件進行再次整理一下，形成標準化組件專題，後續該專題將包含各類語言中的一些常用組件。歡迎大家進行持續關注。

如果你正在進行編寫一個項目，但是缺少一個認證模塊，這時就可以使用本節中分享的組件 casdoor 了，它支持OAuth 2.0、OIDC 和 SAML 的 UI 優先集中式身份驗證/單點登錄 (SSO) 平台，與 Casbin RBAC 和 ABAC 權限管理集成。能讓我們的系統快速集成一套完整的認證體系，同時它支持第三方應用程序登錄，包括國內國外常見的平台，具體可查看 官方 描述，這裡就不具體說明了。

以下是官方說明的一些特點：

這個認證模塊是基於Golang語言，OAuth2協議基礎上提供相關功能的，不熟悉OAuth2協議的先去了解一下，防止使用過程中難於理解。

深入理解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

使用go語言的好處: go語言的設計是務實的, go在針對並發上進行了優化, 並且支持大規模高並發, 又由於單一的碼格式, 相比於其他語言更具有可讀性, 在垃圾回收上比java和Python更有效, 因為他是和程序同時執行的.

1. 進程, 線程, 協程的區別, 協程的優勢

2. 講一下GMP模型(重點)

3. Go的GC, 混合寫屏障(重點)

4. go的Slice和數組的區別, slice的擴容原理(重點)

5. 講一下channel,實現原理(重點)

6. 講一下Go的Map的實現原理, 是否線程安全, 如何實現安全(重點)

7. new 和 make 的區別

8. 說一下內存逃逸

9. 函數傳指針和傳值有什麼區別

10. goroutine之間的通信方式

11. 測試是怎麼做的(單元測試, 壓力測試)

12. 堆和棧的區別

Golang 遊戲leaf系列(六) Go模塊

在 Golang 遊戲leaf系列(一) 概述與示例 (下文簡稱系列一)中，提到過Go模塊用於創建能夠被 Leaf 管理的 goroutine。Go模塊是對golang中go提供一些額外功能。Go提供回調功能，LinearContext提供順序調用功能。善用 goroutine 能夠充分利用多核資源，Leaf 提供的 Go 機制解決了原生 goroutine 存在的一些問題：

我們來看一個例子（可以在 LeafServer 的模塊的 OnInit 方法中測試）：

這裡的 Go 方法接收 2 個函數作為參數，第一個函數會被放置在一個新創建的 goroutine 中執行，在其執行完成之後，第二個函數會在當前 goroutine 中被執行。由此，我們可以看到變量 res 同一時刻總是只被一個 goroutine 訪問，這就避免了同步機制的使用。Go 的設計使得 CPU 得到充分利用，避免操作阻塞當前 goroutine，同時又無需為共享資源同步而憂心。

這裡主動調用了 d.Cb(-d.ChanCb) ，把這個回調取出來了。實際上，在skeleton.Run里會自己取這個通道

看一下源碼：

New方法，會生成指定緩衝長度的ChanCb。然後調用Go方法就是先執行第一個func,然後把第二個放到Cb里。現在手動造一個例子：

這裡解釋一下，d.Go根據源碼來看，實際也是調用了一個協程。然後上面兩次d.Go並不能保證先後順序。目前的輸出結果是1+2那個先執行了，把3寫入d.ChanCb，然後把3讀出來，繼續讀時，d.ChanCb里沒有東西，阻塞了。然後1+1那個協程啟動了，最後又讀到了2。

現在把time.Sleep(time.Second)的注釋解開，會是啥結果呢

這裡執行到time.Sleep睡著了，上面兩個d.Go仍然是不確定順序的，但是會各自的function先執行掉，然後陸續把cb寫入d.ChanCb。看這次輸出，1+2先寫進去的。所以最後執行d.Cb時，就把3先讀出來了。然後d.ChanCb的長度為1，說明還有一個，就是輸出2了。

另外，就是close時會判斷g.pendingGo

這個例子的意思很明顯，NewLinearContext這種方式，即使先調用的慢了半秒，它還是會先執行完。

這裡先是用了一個list，加入的時候用mutexLinearGo鎖了，都加到最後。然後新開協程去處理，讀的時候從最前面開始讀，也要用mutexLinearGo鎖。執行的時候，也要上鎖mutexExecution，確保f()執行完並且寫入g.ChanCb回調，這個mutexExecution鎖才會解除。現在可以改造一個帶回調的例子：

結果說明，確實是2先被寫入了d.ChanCb。