go-zero:微服務框架

go-zero 是一個集成了各種工程實踐的 Web 和 rpc 框架,它的彈性設計保障了大併發服務端的穩定性,並且已經經過了充分的實戰檢驗。

go-zero 在設計時遵循了 “工具大於約定和文檔” 的理念,所以 go-zero 包含極簡的 API 定義和生成工具 goctl,可以根據定義的 API 文件一鍵生成 Go、iOS、Android、Kotlin、Dart、TypeScript、JavaScript 代碼,並可直接運行。

go-zero 的架構圖

如上圖所示,不同客戶端的請求都會先進入 go-zero 的 API 端。API 端最主要的作用是通過 ETCD 將對應的請求通過 gRPC 協議轉發到 Service 端。根據請求的具體內容,Service 端負責對數據進行查詢或存儲。如果是查詢請求,go-zero 有內置的 API 會先查詢緩存層,減少數據庫的查詢壓力。

由圖可見,API 端和 Service 端中框架已經內置了非常豐富的功能,在開發過程中只需要我們填充對應的業務邏輯,即可輕鬆實現 CRDU 級的需求。

我們爲什麼說 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 那樣一個“全家桶” 改動起來要省力省心。

推薦閱讀

MySQL 中存儲時間的最佳實踐

Ansible 快速入門

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章