單體最佳實(shí)踐的由來(lái)

• 對(duì)于很多初創(chuàng)公司來(lái)說(shuō)，業(yè)務(wù)的早期我們更應(yīng)該關(guān)注于業(yè)務(wù)價(jià)值的交付，并且此時(shí)用戶體量也很小，QPS也非常低，我們應(yīng)該使用更簡(jiǎn)單的技術(shù)架構(gòu)來(lái)加速業(yè)務(wù)價(jià)值的交付，此時(shí)單體的優(yōu)勢(shì)就體現(xiàn)出來(lái)了。
• 正如我直播分享時(shí)經(jīng)常提到，我們?cè)谑褂脝误w快速交付業(yè)務(wù)價(jià)值的同時(shí)，也需要為業(yè)務(wù)的發(fā)展預(yù)留可能性，我們可以在單體里面清晰的拆分業(yè)務(wù)模塊。
• go-zero社區(qū)里也有很多小伙伴在問(wèn)，咱們單體開發(fā)的最佳實(shí)踐應(yīng)該是怎樣的。

而go-zero作為一個(gè)被廣泛使用的漸進(jìn)式微服務(wù)框架來(lái)說(shuō)，也是我在多個(gè)大型項(xiàng)目完整發(fā)展過(guò)程中沉淀出來(lái)的，自然我們也充分考慮了單體服務(wù)開發(fā)的場(chǎng)景。

如圖所示的使用go-zero的單體架構(gòu)，也可以支撐很大體量的業(yè)務(wù)規(guī)模，其中Service是單體服務(wù)的多個(gè)Pod。

我就通過(guò)本文詳細(xì)跟大家分享一下如何使用go-zero快速開發(fā)一個(gè)有多個(gè)模塊的單體服務(wù)。

單體示例

我們用一個(gè)上傳下載的單體服務(wù)來(lái)講解go-zero單體服務(wù)開發(fā)的最佳實(shí)踐，為啥用這么個(gè)示例呢？

• go-zero社區(qū)里經(jīng)常有同學(xué)會(huì)問(wèn)上傳文件怎么定義API文件，然后用goctl自動(dòng)生成。初見此類問(wèn)題會(huì)覺得比較奇怪，為啥不用OSS之類的服務(wù)呢？發(fā)現(xiàn)很多場(chǎng)景是用戶需要上傳一個(gè)excel，然后服務(wù)端解析完也就丟棄此文件了。一是文件較小，二是用戶量也不大，就不用那么復(fù)雜的通過(guò)OSS來(lái)繞一圈了，我覺得也挺合理的。

• go-zero社區(qū)也有同學(xué)問(wèn)下載文件怎么通過(guò)定義一個(gè)API文件然后goctl自動(dòng)生成。此類問(wèn)題之所以通過(guò) Go 來(lái)做，問(wèn)下來(lái)一般兩個(gè)原因，一是業(yè)務(wù)剛開始，能簡(jiǎn)單點(diǎn)布一個(gè)服務(wù)搞定就一個(gè)吧；二是希望能吃上go-zero的內(nèi)置JWT自動(dòng)鑒權(quán)。

僅以此為示例，無(wú)需深入探討上傳下載是否應(yīng)該通過(guò)Go來(lái)實(shí)現(xiàn)。那么接下來(lái)我們就看看我們?cè)趺赐ㄟ^(guò)go-zero來(lái)解決這么一個(gè)單體服務(wù)，我們稱之為文件（file）服務(wù)。架構(gòu)如下圖：

單體實(shí)現(xiàn)

API定義

使用過(guò)go-zero的同學(xué)都知道，我們提供了一個(gè)API格式的文件來(lái)描述RESTful API，然后可以通過(guò)goctl一鍵生成對(duì)應(yīng)的代碼，我們只需要在logic文件里填寫對(duì)應(yīng)的業(yè)務(wù)邏輯即可。我們就來(lái)看看download和upload服務(wù)怎么定義API.

Download服務(wù)定義

示例需求如下：

• 通過(guò)/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ù)定義

示例需求如下：

• 通過(guò)/upload路徑上傳文件
• 通過(guò)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)求路由

問(wèn)題來(lái)了

Download和Upload服務(wù)我們都定義好了，那怎么才能放到一個(gè)服務(wù)里給用戶提供服務(wù)呢？

不知道細(xì)心的你有沒(méi)注意到一些細(xì)節(jié)：

• 不管是Download還是Upload我們?cè)?code>request和response數(shù)據(jù)定義的時(shí)候都加了前綴，并沒(méi)有直接使用諸如Request或Response這樣的
• 我們?cè)?code>download.api和upload.api里面定義service的時(shí)候都是用的file-api這個(gè)service name，并沒(méi)有分別用download-api和upload-api

這么做的目的其實(shí)就是為了我們接下來(lái)把這兩個(gè)服務(wù)放到同一個(gè)單體里自動(dòng)生成對(duì)應(yīng)的Go代碼。讓我們來(lái)看看怎么把Download和Upload合并起來(lái)~

定義單體服務(wù)接口

出于簡(jiǎn)單考慮，goctl只支持接受單一API文件作為參數(shù)，同時(shí)接受多個(gè)API文件的問(wèn)題不在此討論，如有簡(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)來(lái)了。但其中有幾點(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來(lái)說(shuō)，接下來(lái)的事情就很簡(jiǎn)單直接了（當(dāng)然，定義API也挺簡(jiǎn)單的，不是嗎？），讓我們來(lái)使用goctl生成單體服務(wù)代碼。

$ goctl api go -api api/file.api -dir .

我們來(lái)看看生成后的文件結(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

我們來(lái)按目錄解釋一下項(xiàng)目代碼的構(gòu)成：

• api目錄：我們前面定義的API接口描述文件，無(wú)需多言
• etc目錄：這個(gè)是用來(lái)放置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目錄：用來(lái)放每個(gè)路由對(duì)應(yīng)的業(yè)務(wù)處理邏輯，之所以區(qū)分handler和logic是為了讓業(yè)務(wù)處理部分盡可能減少依賴，把HTTP requests和邏輯處理代碼隔離開，便于后續(xù)按需拆分成RPC service
• internal/svc目錄：用來(lái)定義業(yè)務(wù)邏輯處理的依賴，我們可以在main里面創(chuàng)建依賴的資源，然后通過(guò)ServiceContext傳遞給handler和logic
• internal/types目錄：定義了API請(qǐng)求和返回?cái)?shù)據(jù)結(jié)構(gòu)

咱們什么也不改，先來(lái)跑一下看看效果。

$ go run file.go -f etc/file-api.yaml
Starting server at 0.0.0.0:8888...

實(shí)現(xiàn)業(yè)務(wù)邏輯

接下來(lái)我們需要實(shí)現(xiàn)相關(guān)的業(yè)務(wù)邏輯，但是這里的邏輯其實(shí)只是一個(gè)演示用途，無(wú)需過(guò)于關(guān)注實(shí)現(xiàn)細(xì)節(jié)，只需要理解我們應(yīng)該把業(yè)務(wù)邏輯寫在logic層即可。

這里一共做了以下幾件事：

增加配置項(xiàng)里的Path設(shè)置，用來(lái)放置上傳文件，默認(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

我們可以通過(guò)啟動(dòng)file單體服務(wù)：

$ go run file.go -f etc/file-api.yaml

可以通過(guò)curl來(lái)驗(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。用來(lái)import步驟一定義的各個(gè)子模塊的API文件
• 通過(guò)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)文章希望大家以后多多支持腳本之家！

最新評(píng)論