go-zero：開箱即用的微服務框架
go-zero 是一個集成了各類工程實踐的 Web 和 rpc 框架，它的彈性設計保障了大併發服務端的穩定性，而且已經通過了充分的實戰檢驗。html
go-zero 在設計時遵循了 「工具大於約定和文檔」 的理念，因此 go-zero 包含極簡的 API 定義和生成工具 goctl，能夠根據定義的 API 文件一鍵生成 Go、iOS、Android、Kotlin、Dart、TypeScript、JavaScript 代碼，並可直接運行。前端
如上圖所示，不一樣客戶端的請求都會先進入 go-zero 的 API 端。API 端最主要的做用是經過 ETCD 將對應的請求經過 gRPC 協議轉發到 Service 端。根據請求的具體內容，Service 端負責對數據進行查詢或存儲。若是是查詢請求，go-zero 有內置的 API 會先查詢緩存層，減小數據庫的查詢壓力。mysql
由圖可見，API 端和 Service 端中框架已經內置了很是豐富的功能，在開發過程當中只須要咱們填充對應的業務邏輯，便可輕鬆實現 CRDU 級的需求。sql
咱們爲何說 go-zero 是開箱即用的微服務架構呢？不急，咱們來盤點下 go-zero 中有哪些強大的特性。數據庫
go-zero 適合作微服務快速開發的特性
Go-zero 擁有強大的項目腳手架工具 goctl。 goctl 和前端中的 Vue-cli、React-cli 同樣方便。goctl 經過配置文件能夠生成 API、rpc 和 model 等相關代碼。 同時，go-zero 擁有較完備的項目框架。腳手架生成的項目框架足以應對常見的需求。CRDU 等需求只須要作 「填空題」，在已生成的代碼上填充必要的業務邏輯。 其餘緩存鑑權等需求，框架中也早已內置。緩存
另外，go-zero 擁有獨特的「漸進式」框架。「漸進式」是前端 Vue 框架的一大特性，大意是「易於上手，還便於與第三方庫或既有項目整合」。本文借用這個概念是想代表 go-zero 對項目的入侵性較少，go-zero 生成的代碼能夠拆開使用，逐步對老項目進行改造。架構
低耦合的模塊設計，豐富的中間件，插件和工具：併發
- go-zero 中各模塊耦合程度低，咱們能夠經過文檔中的組件中心尋找合適的中間件或自研中間件。
- 若是以爲 goctl 不能知足需求，goctl 還支持 plugin 命令對 goctl 進行擴展。
- go-zero 的不少配置文件是自定義語法。 go-zero 還提供了 intellij 和 vscode 插件，提供了語法高亮錯誤檢查等編輯加強功能。
goctl 介紹
goctl 是 go-zero 微服務框架下的代碼生成工具。使用 goctl 可顯著提高開發效率，讓開發人員將時間重點放在業務開發上。框架
goctl 的命令可概括爲以下幾類：微服務
- API 命令，快速生成一個 API 服務
- rpc 命令，支持 proto 模板生成和 rpc 服務代碼生成
- model 命令，目前支持識別 mysql ddl 進行 model 層代碼生成
- plugin 命令，支持針對 API 自定義插件
- 其餘命令，目前是發佈相關
goctl 的命令衆多，本次涉及到的只是其中 API、rpc 和 model 相關的基礎命令。
使用 goctl 的基本流程
使用 goctl 生成代碼的流程大體能夠分爲 4 步：
- 使用命令 a 生成默認的配置文件；
- 按照業務需求編輯該配置文件；
- 使用命令 b 按照配置文件生成默認的代碼文件；
- 按照業務邏輯填充對應的代碼文件。
什麼狀況不適宜使用 go-zero 作微服務快速開發？
看完上面的介紹，想必你們對於 go-zero 開發微服務已經有點躍躍欲試了吧。不過通過一番實踐，我認爲當出現如下狀況時，不適宜採用 go-zero 做爲開發微服務的框架。
當前需求與 goctl 的理念相沖突
go-zero 的一大賣點是腳手架工具 goctl，若是定製需求過多可能與 goctl 生成的代碼相沖突。可是若是放棄 goctl 手動編寫代碼的話，開發效率會大大下降。
舉個例子，如上圖所示，go-zero 在 Service 端目前只支持 gRPC，在數據庫層只支持 Mysql、MongoDB 和 ClickHouse，服務發現只支持 ETCD。在這種狀況下若是想實現 PostgreSQL 替換 Mysql、Consul 替換 ETCD 等定製操做，goctl 生成的代碼執行時極可能會出現異常。
但願框架提供的功能很是完善
go-zero 大部分組件是自研，好比 sqlx，httpx 等。這些自研組件知足 CRDU 的操做綽綽有餘，可是與 gorm、gin 等專攻某一方向的開源項目相比仍是有很是大的差距的。
因此隨着公司業務發展需求愈來愈五花八門，當前的主要矛盾從「快速開發」變成「精細化開發」時，會發現該框架有這樣或那樣的不足。這種狀況下就須要提 RP 或本身 fork 一份魔改了。我的以爲這種狀況比 Spring 或 Django 那樣一個「全家桶」 改動起來要省力省心。