golang企業級實踐,Golang 框架

本文目錄一覽：

• 1、【golang詳解】go語言GMP(GPM)原理和調度
• 2、Golang 中更好的錯誤處理：理論和實踐技巧
• 3、golang適合做web開發嗎
• 4、Golang項目部署3，容器部署

【golang詳解】go語言GMP(GPM)原理和調度

Goroutine調度是一個很複雜的機制，下面嘗試用簡單的語言描述一下Goroutine調度機制，想要對其有更深入的了解可以去研讀一下源碼。

首先介紹一下GMP什麼意思：

G ———– goroutine: 即Go協程，每個go關鍵字都會創建一個協程。

M ———- thread內核級線程，所有的G都要放在M上才能運行。

P ———– processor處理器，調度G到M上，其維護了一個隊列，存儲了所有需要它來調度的G。

Goroutine 調度器P和 OS 調度器是通過 M 結合起來的，每個 M 都代表了 1 個內核線程，OS 調度器負責把內核線程分配到 CPU 的核上執行

模型圖：

避免頻繁的創建、銷毀線程，而是對線程的復用。

1）work stealing機制

  當本線程無可運行的G時，嘗試從其他線程綁定的P偷取G，而不是銷毀線程。

2）hand off機制

  當本線程M0因為G0進行系統調用阻塞時，線程釋放綁定的P，把P轉移給其他空閑的線程執行。進而某個空閑的M1獲取P，繼續執行P隊列中剩下的G。而M0由於陷入系統調用而進被阻塞，M1接替M0的工作，只要P不空閑，就可以保證充分利用CPU。M1的來源有可能是M的緩存池，也可能是新建的。當G0系統調用結束後，根據M0是否能獲取到P，將會將G0做不同的處理：

如果有空閑的P，則獲取一個P，繼續執行G0。

如果沒有空閑的P，則將G0放入全局隊列，等待被其他的P調度。然後M0將進入緩存池睡眠。

如下圖

GOMAXPROCS設置P的數量，最多有GOMAXPROCS個線程分布在多個CPU上同時運行

在Go中一個goroutine最多佔用CPU 10ms，防止其他goroutine被餓死。

具體可以去看另一篇文章

【Golang詳解】go語言調度機制 搶佔式調度

當創建一個新的G之後優先加入本地隊列，如果本地隊列滿了，會將本地隊列的G移動到全局隊列裡面，當M執行work stealing從其他P偷不到G時，它可以從全局G隊列獲取G。

協程經歷過程

我們創建一個協程 go func()經歷過程如下圖：

說明：

這裡有兩個存儲G的隊列，一個是局部調度器P的本地隊列、一個是全局G隊列。新創建的G會先保存在P的本地隊列中，如果P的本地隊列已經滿了就會保存在全局的隊列中；處理器本地隊列是一個使用數組構成的環形鏈表，它最多可以存儲 256 個待執行任務。

G只能運行在M中，一個M必須持有一個P，M與P是1：1的關係。M會從P的本地隊列彈出一個可執行狀態的G來執行，如果P的本地隊列為空，就會想其他的MP組合偷取一個可執行的G來執行；

一個M調度G執行的過程是一個循環機制；會一直從本地隊列或全局隊列中獲取G

上面說到P的個數默認等於CPU核數，每個M必須持有一個P才可以執行G，一般情況下M的個數會略大於P的個數，這多出來的M將會在G產生系統調用時發揮作用。類似線程池，Go也提供一個M的池子，需要時從池子中獲取，用完放回池子，不夠用時就再創建一個。

work-stealing調度演算法：當M執行完了當前P的本地隊列隊列里的所有G後，P也不會就這麼在那躺屍啥都不幹，它會先嘗試從全局隊列隊列尋找G來執行，如果全局隊列為空，它會隨機挑選另外一個P，從它的隊列里中拿走一半的G到自己的隊列中執行。

如果一切正常，調度器會以上述的那種方式順暢地運行，但這個世界沒這麼美好，總有意外發生，以下分析goroutine在兩種例外情況下的行為。

Go runtime會在下面的goroutine被阻塞的情況下運行另外一個goroutine：

用戶態阻塞/喚醒

當goroutine因為channel操作或者network I/O而阻塞時（實際上golang已經用netpoller實現了goroutine網路I/O阻塞不會導致M被阻塞，僅阻塞G，這裡僅僅是舉個栗子），對應的G會被放置到某個wait隊列(如channel的waitq)，該G的狀態由_Gruning變為_Gwaitting，而M會跳過該G嘗試獲取並執行下一個G，如果此時沒有可運行的G供M運行，那麼M將解綁P，並進入sleep狀態；當阻塞的G被另一端的G2喚醒時（比如channel的可讀/寫通知），G被標記為，嘗試加入G2所在P的runnext（runnext是線程下一個需要執行的 Goroutine。）， 然後再是P的本地隊列和全局隊列。

系統調用阻塞

當M執行某一個G時候如果發生了阻塞操作，M會阻塞，如果當前有一些G在執行，調度器會把這個線程M從P中摘除，然後再創建一個新的操作系統的線程(如果有空閑的線程可用就復用空閑線程)來服務於這個P。當M系統調用結束時候，這個G會嘗試獲取一個空閑的P執行，並放入到這個P的本地隊列。如果獲取不到P，那麼這個線程M變成休眠狀態， 加入到空閑線程中，然後這個G會被放入全局隊列中。

隊列輪轉

可見每個P維護著一個包含G的隊列，不考慮G進入系統調用或IO操作的情況下，P周期性的將G調度到M中執行，執行一小段時間，將上下文保存下來，然後將G放到隊列尾部，然後從隊列中重新取出一個G進行調度。

除了每個P維護的G隊列以外，還有一個全局的隊列，每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中G的來源，主要有從系統調用中恢復的G。之所以P會周期性地查看全局隊列，也是為了防止全局隊列中的G被餓死。

除了每個P維護的G隊列以外，還有一個全局的隊列，每個P會周期性地查看全局隊列中是否有G待運行並將其調度到M中執行，全局隊列中G的來源，主要有從系統調用中恢復的G。之所以P會周期性地查看全局隊列，也是為了防止全局隊列中的G被餓死。

M0

M0是啟動程序後的編號為0的主線程，這個M對應的實例會在全局變數rutime.m0中，不需要在heap上分配，M0負責執行初始化操作和啟動第一個G，在之後M0就和其他的M一樣了

G0

G0是每次啟動一個M都會第一個創建的goroutine，G0僅用於負責調度G，G0不指向任何可執行的函數，每個M都會有一個自己的G0，在調度或系統調用時會使用G0的棧空間，全局變數的G0是M0的G0

一個G由於調度被中斷，此後如何恢復？

中斷的時候將寄存器里的棧信息，保存到自己的G對象裡面。當再次輪到自己執行時，將自己保存的棧信息複製到寄存器裡面，這樣就接著上次之後運行了。

我這裡只是根據自己的理解進行了簡單的介紹，想要詳細了解有關GMP的底層原理可以去看Go調度器 G-P-M 模型的設計者的文檔或直接看源碼

參考： ()

()

Golang 中更好的錯誤處理：理論和實踐技巧

雲和安全管理服務專家新鈦雲服 張春翻譯

這種方法有幾個缺點。首先，它可以對程序員隱藏錯誤處理路徑，特別是在捕獲異常不是強制性的情況下，例如在 Python 中。即使在具有必須處理的 Java 風格的檢查異常的語言中，如果在與原始調用不同的級別上處理錯誤，也並不總是很明顯錯誤是從哪裡引發的。

我們都見過長長的代碼塊包裝在一個 try-catch 塊中。在這種情況下，catch 塊實際上充當 goto 語句，這通常被認為是有害的（奇怪的是，C 中的關鍵字被認為可以接受的少數用例之一是錯誤後清理，因為該語言沒有 Golang- 樣式延遲語句）。

如果你確實從源頭捕獲異常，你會得到一個不太優雅的 Go 錯誤模式版本。這可能會解決混淆代碼的問題，但會遇到另一個問題：性能。在諸如 Java 之類的語言中，拋出異常可能比函數的常規返回慢數百倍。

Java 中最大的性能成本是由列印異常的堆棧跟蹤造成的，這是昂貴的，因為運行的程序必須檢查編譯它的源代碼 。僅僅進入一個 try 塊也不是空閑的，因為需要保存 CPU 內存寄存器的先前狀態，因為它們可能需要在拋出異常的情況下恢復。

如果您將異常視為通常不會發生的異常情況，那麼異常的缺點並不重要。這可能是傳統的單體應用程序的情況，其中大部分代碼庫不必進行網路調用——一個操作格式良好的數據的函數不太可能遇到錯誤（除了錯誤的情況）。一旦您在代碼中添加 I/O，無錯誤代碼的夢想就會破滅：您可以忽略錯誤，但不能假裝它們不存在！

try {

doSometing()

} catch (IOException e) {

// ignore it

}

與大多數其他編程語言不同，Golang 接受錯誤是不可避免的。 如果在單體架構時代還不是這樣，那麼在今天的模塊化後端服務中，服務通常和外部 API 調用、資料庫讀取和寫入以及與其他服務通信 。

以上所有方法都可能失敗，解析或驗證從它們接收到的數據（通常在無模式 JSON 中）也可能失敗。Golang 使可以從這些調用返回的錯誤顯式化，與普通返回值的等級相同。從函數調用返回多個值的能力支持這一點，這在大多數語言中通常是不可能的。Golang 的錯誤處理系統不僅僅是一種語言怪癖，它是一種將錯誤視為替代返回值的完全不同的方式！

重複 if err != nil

對 Go 錯誤處理的一個常見批評是被迫重複以下代碼塊：

res, err := doSomething()

if err != nil {

// Handle error

}

對於新用戶來說，這可能會覺得沒用而且浪費行數：在其他語言中需要 3 行的函數很可能會增長到 12 行 ：

這麼多行代碼！這麼低效！如果您認為上述內容不優雅或浪費代碼，您可能忽略了我們檢查代碼中的錯誤的全部原因：我們需要能夠以不同的方式處理它們！對 API 或資料庫的調用可能會被重試。

有時事件的順序很重要：調用外部 API 之前發生的錯誤可能不是什麼大問題（因為數據從未通過發送），而 API 調用和寫入本地資料庫之間的錯誤可能需要立即注意，因為 這可能意味著系統最終處於不一致的狀態。即使我們只想將錯誤傳播給調用者，我們也可能希望用失敗的解釋來包裝它們，或者為每個錯誤返回一個自定義錯誤類型。

並非所有錯誤都是相同的，並且向調用者返回適當的錯誤是 API 設計的重要部分，無論是對於內部包還是 REST API 。

不必擔心在你的代碼中重複 if err != nil ——這就是 Go 中的代碼應該看起來的樣子。

自定義錯誤類型和錯誤包裝

從導出的方法返回錯誤時，請考慮指定自定義錯誤類型，而不是單獨使用錯誤字元串。字元串在意外代碼中是可以的，但在導出的函數中，它們成為函數公共 API 的一部分。更改錯誤字元串將是一項重大更改——如果沒有明確的錯誤類型，需要檢查返回錯誤類型的單元測試將不得不依賴原始字元串值！事實上，基於字元串的錯誤也使得在私有方法中測試不同的錯誤案例變得困難，因此您也應該考慮在包中使用它們。回到錯誤與異常的爭論，返回錯誤也使代碼比拋出異常更容易測試，因為錯誤只是要檢查的返回值。不需要測試框架或在測試中捕獲異常 。

可以在 database/sql 包中找到簡單自定義錯誤類型的一個很好的示例。它定義了一個導出常量列表，表示包可以返回的錯誤類型，最著名的是 sql.ErrNoRows。雖然從 API 設計的角度來看，這種特定的錯誤類型有點問題（您可能會爭辯說 API 應該返回一個空結構而不是錯誤），但任何需要檢查空行的應用程序都可以導入該常量並在代碼中使用它不必擔心錯誤消息本身會改變和破壞代碼。

對於更複雜的錯誤處理，您可以通過實現返回錯誤字元串的 Error() 方法來定義自定義錯誤類型。自定義錯誤可以包括元數據，例如錯誤代碼或原始請求參數。如果您想表示錯誤類別，它們很有用。DigitalOcean 的本教程展示了如何使用自定義錯誤類型來表示可以重試的一類臨時錯誤。

通常，錯誤會通過將低級錯誤與更高級別的解釋包裝起來，從而在程序的調用堆棧中傳播。例如，資料庫錯誤可能會以下列格式記錄在 API 調用處理程序中：調用 CreateUser 端點時出錯：查詢資料庫時出錯：pq：檢測到死鎖。這很有用，因為它可以幫助我們跟蹤錯誤在系統中傳播的過程，向我們展示根本原因（資料庫事務引擎中的死鎖）以及它對更廣泛系統的影響（調用者無法創建新用戶）。

自 Go 1.13 以來，此模式具有特殊的語言支持，並帶有錯誤包裝。通過在創建字元串錯誤時使用 %w 動詞，可以使用 Unwrap() 方法訪問底層錯誤。除了比較錯誤相等性的函數 errors.Is() 和 errors.As() 外，程序還可以獲取包裝錯誤的原始類型或標識。這在某些情況下可能很有用，儘管我認為在確定如何處理所述錯誤時最好使用頂級錯誤的類型。

Panics

不要 panic()！長時間運行的應用程序應該優雅地處理錯誤而不是panic。即使在無法恢復的情況下（例如在啟動時驗證配置），最好記錄一個錯誤並優雅地退出。panic比錯誤消息更難診斷，並且可能會跳過被推遲的重要關閉代碼。

Logging

我還想簡要介紹一下日誌記錄，因為它是處理錯誤的關鍵部分。通常你能做的最好的事情就是記錄收到的錯誤並繼續下一個請求。

除非您正在構建簡單的命令行工具或個人項目，否則您的應用程序應該使用結構化的日誌庫，該庫可以為日誌添加時間戳，並提供對日誌級別的控制。最後一部分特別重要，因為它將允許您突出顯示應用程序記錄的所有錯誤和警告。通過幫助將它們與信息級日誌分開，這將為您節省無數時間。

微服務架構還應該在日誌行中包含服務的名稱以及機器實例的名稱。默認情況下記錄這些時，程序代碼不必擔心包含它們。您也可以在日誌的結構化部分中記錄其他欄位，例如收到的錯誤（如果您不想將其嵌入日誌消息本身）或有問題的請求或響應。只需確保您的日誌沒有泄露任何敏感數據，例如密碼、API 密鑰或用戶的個人數據！

對於日誌庫，我過去使用過 logrus 和 zerolog，但您也可以選擇其他結構化日誌庫。如果您想了解更多信息，互聯網上有許多關於如何使用這些的指南。如果您將應用程序部署到雲中，您可能需要日誌庫上的適配器來根據您的雲平台的日誌 API 格式化日誌 – 沒有它，雲平台可能無法檢測到日誌級別等某些功能。

如果您在應用程序中使用調試級別日誌（默認情況下通常不記錄），請確保您的應用程序可以輕鬆更改日誌級別，而無需更改代碼。更改日誌級別還可以暫時使信息級別甚至警告級別的日誌靜音，以防它們突然變得過於嘈雜並開始淹沒錯誤。您可以使用在啟動時檢查以設置日誌級別的環境變數來實現這一點。

原文：

golang適合做web開發嗎

適合。框架足夠成熟了 A Survey of 5 Go Web Frameworks

小型項目你甚至不用框架，用net/http http – The Go Programming Language

常用庫也成熟了 Top – Go Search

golang的web後端即使不concurrent也比php，ruby，python快很多很多

golang里用concurrent真的非常方便，非常非常快，超大web項目golang scale成本低

如果你想，golang的部署可以比php更方便，使用go get和http.ServeAndListen()可以不用nginx和apache

對於文件改動重新編譯其實並不是大問題，看pilu/fresh · GitHub，其實你自己寫shell腳本（也可以直接用go寫，因為它本身就是系統語言）監控文件系統改動然後自動重新build，即使是C/C++的項目這也不是大問題，人們不用C/C++寫web是因為它們不是寫web app的最佳選擇

golang寫的代碼編譯通過後，要比scripting language魯棒，因為go compiler強制一些最佳實踐

Golang項目部署3，容器部署

容器部署即使用 docker 化部署 golang 應用程序，這是在雲服務時代最流行的部署方式，也是最推薦的部署方式。

跨平台交叉編譯是 golang 的特點之一，可以非常方便地編譯出我們需要的目標伺服器平台的版本，而且是靜態編譯，非常容易地解決了運行依賴問題。

使用以下指令可以靜態編譯 Linux 平台 amd64 架構的可執行文件：

生成的 main 便是我們靜態編譯的，可部署於 Linux amd64 上的可執行文件。

我們需要將該可執行文件 main 編譯生成 docker 鏡像，以便於分發及部署。 Golang 的運行環境推薦使用 alpine 基礎系統鏡像，編譯出的容器鏡像約為 20MB 左右。

一個參考的 Dockerfile 文件如下：

其中，我們的基礎鏡像使用了 loads/alpine:3.8 ，中國國內的用戶推薦使用該基礎鏡像，基礎鏡像的 Dockerfile 地址： ，倉庫地址：

隨後使用 ” docker build -t main . ” 指令編譯生成名為 main 的 docker 鏡像。

需要注意的是，在某些項目的架構設計中， 靜態文件 和 配置文件 可能不會隨著鏡像進行編譯發布，而是分開進行管理和發布。

例如，使用 MVVM 模式的項目中(例如使用 vue 框架)，往往是前後端非常獨立的，因此在鏡像中往往並不會包含 public 目錄。而使用了 配置管理中心 (例如使用 consul / etcd / zookeeper )的項目中，也往往並不需要 config 目錄。

因此對於以上示例的 Dockerfile 的使用，僅作參考，根據實際情況請進行必要的調整。

使用以下指令可直接運行剛才編譯成的鏡像：

容器的分發可以使用 docker 官方的平台： ，國內也可以考慮使用阿里云： 。

在企業級生產環境中， docker 容器往往需要結合 kubernetes 或者 docker swarm 容器編排工具一起使用。

容器編排涉及到的內容比較多，感興趣的同學可以參考以下資料：