Go單體服務(wù)開發(fā)最佳實(shí)踐總結(jié)
單體最佳實(shí)踐的由來
- 對(duì)于很多初創(chuàng)公司來說,業(yè)務(wù)的早期我們更應(yīng)該關(guān)注于業(yè)務(wù)價(jià)值的交付,并且此時(shí)用戶體量也很小,
QPS
也非常低,我們應(yīng)該使用更簡(jiǎn)單的技術(shù)架構(gòu)來加速業(yè)務(wù)價(jià)值的交付,此時(shí)單體的優(yōu)勢(shì)就體現(xiàn)出來了。 - 正如我直播分享時(shí)經(jīng)常提到,我們?cè)谑褂脝误w快速交付業(yè)務(wù)價(jià)值的同時(shí),也需要為業(yè)務(wù)的發(fā)展預(yù)留可能性,我們可以在單體里面清晰的拆分業(yè)務(wù)模塊。
go-zero
社區(qū)里也有很多小伙伴在問,咱們單體開發(fā)的最佳實(shí)踐應(yīng)該是怎樣的。
而go-zero
作為一個(gè)被廣泛使用的漸進(jìn)式微服務(wù)框架來說,也是我在多個(gè)大型項(xiàng)目完整發(fā)展過程中沉淀出來的,自然我們也充分考慮了單體服務(wù)開發(fā)的場(chǎng)景。
如圖所示的使用go-zero
的單體架構(gòu),也可以支撐很大體量的業(yè)務(wù)規(guī)模,其中Service
是單體服務(wù)的多個(gè)Pod
。
我就通過本文詳細(xì)跟大家分享一下如何使用go-zero
快速開發(fā)一個(gè)有多個(gè)模塊的單體服務(wù)。
單體示例
我們用一個(gè)上傳下載的單體服務(wù)來講解go-zero
單體服務(wù)開發(fā)的最佳實(shí)踐,為啥用這么個(gè)示例呢?
go-zero
社區(qū)里經(jīng)常有同學(xué)會(huì)問上傳文件怎么定義API
文件,然后用goctl
自動(dòng)生成。初見此類問題會(huì)覺得比較奇怪,為啥不用OSS
之類的服務(wù)呢?發(fā)現(xiàn)很多場(chǎng)景是用戶需要上傳一個(gè)excel,然后服務(wù)端解析完也就丟棄此文件了。一是文件較小,二是用戶量也不大,就不用那么復(fù)雜的通過OSS
來繞一圈了,我覺得也挺合理的。go-zero
社區(qū)也有同學(xué)問下載文件怎么通過定義一個(gè)API
文件然后goctl
自動(dòng)生成。此類問題之所以通過 Go 來做,問下來一般兩個(gè)原因,一是業(yè)務(wù)剛開始,能簡(jiǎn)單點(diǎn)布一個(gè)服務(wù)搞定就一個(gè)吧;二是希望能吃上go-zero
的內(nèi)置JWT
自動(dòng)鑒權(quán)。
僅以此為示例,無需深入探討上傳下載是否應(yīng)該通過Go
來實(shí)現(xiàn)。那么接下來我們就看看我們?cè)趺赐ㄟ^go-zero
來解決這么一個(gè)單體服務(wù),我們稱之為文件(file)服務(wù)。架構(gòu)如下圖:
單體實(shí)現(xiàn)
API
定義
使用過go-zero
的同學(xué)都知道,我們提供了一個(gè)API
格式的文件來描述RESTful API
,然后可以通過goctl
一鍵生成對(duì)應(yīng)的代碼,我們只需要在logic
文件里填寫對(duì)應(yīng)的業(yè)務(wù)邏輯即可。我們就來看看download
和upload
服務(wù)怎么定義API
.
Download
服務(wù)定義
示例需求如下:
- 通過
/static/<filename>
路徑下載名為<filename>
的文件 - 直接返回文件內(nèi)容即可
我們?cè)?code>api目錄下創(chuàng)建一個(gè)名為download.api
的文件,內(nèi)容如下:
syntax = "v1" type DownloadRequest { File string `path:"file"` } service file-api { @handler DownloadHandler get /static/:file(DownloadRequest)
zero-api
的語(yǔ)法還是比較能自解釋的,含義如下:
syntax = “v1”
表示這是zero-api
的v1
語(yǔ)法type DownloadRequest
定義了Download
的請(qǐng)求格式service file-api
定義了Download
的請(qǐng)求路由
Upload
服務(wù)定義
示例需求如下:
- 通過
/upload
路徑上傳文件 - 通過
json
返回上傳狀態(tài),其中的code
可用于表達(dá)比HTTP code
更豐富的場(chǎng)景
我們?cè)?code>api目錄下創(chuàng)建一個(gè)名為upload.api
的文件,內(nèi)容如下:
syntax = "v1" type UploadResponse { Code int `json:"code"` } service file-api { @handler UploadHandler post /upload returns (UploadResponse) }
解釋如下:
syntax = “v1”
表示這是zero-api
的v1
語(yǔ)法type UploadResponse
定義了Upload
的返回格式service file-api
定義了Upload
的請(qǐng)求路由
問題來了
Download
和Upload
服務(wù)我們都定義好了,那怎么才能放到一個(gè)服務(wù)里給用戶提供服務(wù)呢?
不知道細(xì)心的你有沒注意到一些細(xì)節(jié):
- 不管是
Download
還是Upload
我們?cè)?code>request和response
數(shù)據(jù)定義的時(shí)候都加了前綴,并沒有直接使用諸如Request
或Response
這樣的 - 我們?cè)?code>download.api和
upload.api
里面定義service
的時(shí)候都是用的file-api
這個(gè)service name
,并沒有分別用download-api
和upload-api
這么做的目的其實(shí)就是為了我們接下來把這兩個(gè)服務(wù)放到同一個(gè)單體里自動(dòng)生成對(duì)應(yīng)的Go
代碼。讓我們來看看怎么把Download
和Upload
合并起來~
定義單體服務(wù)接口
出于簡(jiǎn)單考慮,goctl
只支持接受單一API
文件作為參數(shù),同時(shí)接受多個(gè)API
文件的問題不在此討論,如有簡(jiǎn)單高效的方案,后續(xù)可能支持。
我們?cè)?code>api目錄下創(chuàng)建一個(gè)新的file.api
的文件,內(nèi)容如下:
syntax = "v1" import "download.api" import "upload.api"
這樣我們就像C/C++
的#include
一樣把Download
和Upload
服務(wù)都導(dǎo)入進(jìn)來了。但其中有幾點(diǎn)需要注意的:
- 定義的結(jié)構(gòu)體不能重名
- 所有文件里包含的
service name
必須是同一個(gè)
最外層的
API
文件也可以包含同一個(gè)service
的部分定義,但我們推薦保持對(duì)稱,除非這些API
確實(shí)屬于父層級(jí),比如跟Download
和Upload
屬于同一個(gè)邏輯層次,那么就不應(yīng)該放到file.api
里面定義。
至此,我們的文件結(jié)構(gòu)如下:
. └── api ├── download.api ├── file.api └── upload.api
生成單體服務(wù)
既然已經(jīng)有了API
接口定義,那么對(duì)于go-zero
來說,接下來的事情就很簡(jiǎn)單直接了(當(dāng)然,定義API
也挺簡(jiǎn)單的,不是嗎?),讓我們來使用goctl
生成單體服務(wù)代碼。
$ goctl api go -api api/file.api -dir .
我們來看看生成后的文件結(jié)構(gòu):
. ├── api │?? ├── download.api │?? ├── file.api │?? └── upload.api ├── etc │?? └── file-api.yaml ├── file.go ├── go.mod ├── go.sum └── internal ├── config │?? └── config.go ├── handler │?? ├── downloadhandler.go │?? ├── routes.go │?? └── uploadhandler.go ├── logic │?? ├── downloadlogic.go │?? └── uploadlogic.go ├── svc │?? └── servicecontext.go └── types └── types.go
我們來按目錄解釋一下項(xiàng)目代碼的構(gòu)成:
api
目錄:我們前面定義的API
接口描述文件,無需多言etc
目錄:這個(gè)是用來放置yaml
配置文件的,所有的配置項(xiàng)都可以寫在file-api.yaml
文件里file.go
:main
函數(shù)所在文件,文件名跟service
同名,去掉了后綴-api
internal/config
目錄:服務(wù)的配置定義internal/handler
目錄:API
文件里定義的路由對(duì)應(yīng)的handler
實(shí)現(xiàn)internal/logic
目錄:用來放每個(gè)路由對(duì)應(yīng)的業(yè)務(wù)處理邏輯,之所以區(qū)分handler
和logic
是為了讓業(yè)務(wù)處理部分盡可能減少依賴,把HTTP requests
和邏輯處理代碼隔離開,便于后續(xù)按需拆分成RPC service
internal/svc
目錄:用來定義業(yè)務(wù)邏輯處理的依賴,我們可以在main
里面創(chuàng)建依賴的資源,然后通過ServiceContext
傳遞給handler
和logic
internal/types
目錄:定義了API
請(qǐng)求和返回?cái)?shù)據(jù)結(jié)構(gòu)
咱們什么也不改,先來跑一下看看效果。
$ go run file.go -f etc/file-api.yaml Starting server at 0.0.0.0:8888...
實(shí)現(xiàn)業(yè)務(wù)邏輯
接下來我們需要實(shí)現(xiàn)相關(guān)的業(yè)務(wù)邏輯,但是這里的邏輯其實(shí)只是一個(gè)演示用途,無需過于關(guān)注實(shí)現(xiàn)細(xì)節(jié),只需要理解我們應(yīng)該把業(yè)務(wù)邏輯寫在logic
層即可。
這里一共做了以下幾件事:
增加配置項(xiàng)里的Path
設(shè)置,用來放置上傳文件,默認(rèn)值我寫了當(dāng)前目錄,因?yàn)槭鞘纠?,如下?/p>
type Config struct { rest.RestConf // 新增 Path string `json:",default=."` }
調(diào)整了請(qǐng)求體的大小限制,如下:
Name: file-api Host: localhost Port: 8888 # 新增 MaxBytes: 1073741824
由于Download
需要寫文件給客戶端,所以我們把ResponseWriter
當(dāng)成io.Writer
傳遞給了logic
層,修改后的代碼如下:
func (l *DownloadLogic) Download(req *types.DownloadRequest) error { logx.Infof("download %s", req.File) body, err := ioutil.ReadFile(req.File) if err != nil { return err } n, err := l.writer.Write(body) if err != nil { return err } if n < len(body) { return io.ErrClosedPipe } return nil }
由于Upload
需要讀取用戶上傳的文件,所以我們把http.Request
傳遞給了logic
層,修改后的代碼如下:
func (l *UploadLogic) Upload() (resp *types.UploadResponse, err error) { l.r.ParseMultipartForm(maxFileSize) file, handler, err := l.r.FormFile("myFile") if err != nil { return nil, err } defer file.Close() logx.Infof("upload file: %+v, file size: %d, MIME header: %+v", handler.Filename, handler.Size, handler.Header) tempFile, err := os.Create(path.Join(l.svcCtx.Config.Path, handler.Filename)) if err != nil { return nil, err } defer tempFile.Close() io.Copy(tempFile, file) return &types.UploadResponse{ Code: 0, }, nil }
完整代碼:https://github.com/zeromicro/zero-examples/tree/main/monolithic
我們可以通過啟動(dòng)file
單體服務(wù):
$ go run file.go -f etc/file-api.yaml
可以通過curl
來驗(yàn)證Download
服務(wù):
$ curl -i "http://localhost:8888/static/file.go" HTTP/1.1 200 OK Traceparent: 00-831431c47d162b4decfb6b30fb232556-dd3b383feb1f13a9-00 Date: Mon, 25 Apr 2022 01:50:58 GMT Content-Length: 584 Content-Type: text/plain; charset=utf-8 ...
示例倉(cāng)庫(kù)里包含了upload.html
,瀏覽器打開這個(gè)文件就可以嘗試Upload
服務(wù)了。
單體開發(fā)的總結(jié)
我把用go-zero
開發(fā)單體服務(wù)的完整流程歸納如下:
- 定義各個(gè)子模塊的
API
文件,比如:download.api
和upload.api
- 定義總的
API
文件,比如:file.api
。用來import
步驟一定義的各個(gè)子模塊的API
文件 - 通過
goctl api go
命令生成單體服務(wù)框架代碼 - 增加和調(diào)整配置,實(shí)現(xiàn)對(duì)應(yīng)的子模塊的業(yè)務(wù)邏輯
另外,goctl
可以根據(jù)SQL
一鍵生成CRUD
以及cache
代碼,可以幫助大家更快速的開發(fā)單體服務(wù)。
項(xiàng)目地址
https://github.com/zeromicro/go-zero
到此這篇關(guān)于Go單體服務(wù)開發(fā)最佳實(shí)踐的文章就介紹到這了,更多相關(guān)go單體服務(wù)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
go原子級(jí)內(nèi)存操作實(shí)現(xiàn)
原子級(jí)內(nèi)存操作是在多線程并發(fā)執(zhí)行時(shí),能夠確保某個(gè)內(nèi)存操作是不可中斷的操作,本文主要介紹了go原子級(jí)內(nèi)存操作實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下2024-02-02構(gòu)建Golang應(yīng)用最小Docker鏡像的實(shí)現(xiàn)
這篇文章主要介紹了構(gòu)建Golang應(yīng)用最小Docker鏡像的實(shí)現(xiàn),文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-05-05Golang 定時(shí)器(Timer 和 Ticker),這篇文章就夠了
這篇文章主要介紹了Golang 定時(shí)器(Timer 和 Ticker),這篇文章就夠了,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2020-10-10Golang服務(wù)的請(qǐng)求調(diào)度的實(shí)現(xiàn)
Golang服務(wù)請(qǐng)求調(diào)度是一種使用Go語(yǔ)言實(shí)現(xiàn)的服務(wù)請(qǐng)求管理方法,本文主要介紹了Golang服務(wù)的請(qǐng)求調(diào)度的實(shí)現(xiàn),具有一定的參考價(jià)值,感興趣的可以了解一下2023-08-08