欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

Go單體服務開發(fā)最佳實踐總結(jié)

 更新時間:2022年04月26日 10:14:00   作者:萬俊峰Kevin  
這篇文章主要介紹了Go單體服務開發(fā)最佳實踐,通過本文詳細跟大家分享一下如何使用?go-zero?快速開發(fā)一個有多個模塊的單體服務,需要的朋友可以參考下

單體最佳實踐的由來

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

go-zero作為一個被廣泛使用的漸進式微服務框架來說,也是我在多個大型項目完整發(fā)展過程中沉淀出來的,自然我們也充分考慮了單體服務開發(fā)的場景。

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

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

單體示例

我們用一個上傳下載的單體服務來講解go-zero單體服務開發(fā)的最佳實踐,為啥用這么個示例呢?

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

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

僅以此為示例,無需深入探討上傳下載是否應該通過Go來實現(xiàn)。那么接下來我們就看看我們怎么通過go-zero來解決這么一個單體服務,我們稱之為文件(file)服務。架構(gòu)如下圖:

單體實現(xiàn)

API定義

使用過go-zero的同學都知道,我們提供了一個API格式的文件來描述RESTful API,然后可以通過goctl一鍵生成對應的代碼,我們只需要在logic文件里填寫對應的業(yè)務邏輯即可。我們就來看看downloadupload服務怎么定義API.

Download服務定義

示例需求如下:

  • 通過/static/<filename>路徑下載名為<filename>的文件
  • 直接返回文件內(nèi)容即可

我們在api目錄下創(chuàng)建一個名為download.api的文件,內(nèi)容如下:

syntax = "v1"
type DownloadRequest {
  File string `path:"file"`
}
service file-api {
  @handler DownloadHandler
  get /static/:file(DownloadRequest)

zero-api的語法還是比較能自解釋的,含義如下:

  • syntax = “v1”表示這是zero-apiv1語法
  • type DownloadRequest定義了Download的請求格式
  • service file-api定義了Download的請求路由

Upload服務定義

示例需求如下:

  • 通過/upload路徑上傳文件
  • 通過json返回上傳狀態(tài),其中的code可用于表達比HTTP code更豐富的場景

我們在api目錄下創(chuàng)建一個名為upload.api的文件,內(nèi)容如下:

syntax = "v1"
type UploadResponse {
  Code int `json:"code"`
}
service file-api {
  @handler UploadHandler
  post /upload returns (UploadResponse)
}

解釋如下:

  • syntax = “v1”表示這是zero-apiv1語法
  • type UploadResponse定義了Upload的返回格式
  • service file-api定義了Upload的請求路由

問題來了

DownloadUpload服務我們都定義好了,那怎么才能放到一個服務里給用戶提供服務呢?

不知道細心的你有沒注意到一些細節(jié):

  • 不管是Download還是Upload我們在requestresponse數(shù)據(jù)定義的時候都加了前綴,并沒有直接使用諸如RequestResponse這樣的
  • 我們在download.apiupload.api里面定義service的時候都是用的file-api這個service name,并沒有分別用download-apiupload-api

這么做的目的其實就是為了我們接下來把這兩個服務放到同一個單體里自動生成對應的Go代碼。讓我們來看看怎么把DownloadUpload合并起來~

定義單體服務接口

出于簡單考慮,goctl只支持接受單一API文件作為參數(shù),同時接受多個API文件的問題不在此討論,如有簡單高效的方案,后續(xù)可能支持。

我們在api目錄下創(chuàng)建一個新的file.api的文件,內(nèi)容如下:

syntax = "v1"
import "download.api"
import "upload.api"

這樣我們就像C/C++#include一樣把DownloadUpload服務都導入進來了。但其中有幾點需要注意的:

  • 定義的結(jié)構(gòu)體不能重名
  • 所有文件里包含的service name必須是同一個

最外層的API文件也可以包含同一個service的部分定義,但我們推薦保持對稱,除非這些API確實屬于父層級,比如跟DownloadUpload屬于同一個邏輯層次,那么就不應該放到file.api里面定義。

至此,我們的文件結(jié)構(gòu)如下:

.
└── api
    ├── download.api
    ├── file.api
    └── upload.api

生成單體服務

既然已經(jīng)有了API接口定義,那么對于go-zero來說,接下來的事情就很簡單直接了(當然,定義API也挺簡單的,不是嗎?),讓我們來使用goctl生成單體服務代碼。

$ 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

我們來按目錄解釋一下項目代碼的構(gòu)成:

  • api目錄:我們前面定義的API接口描述文件,無需多言
  • etc目錄:這個是用來放置yaml配置文件的,所有的配置項都可以寫在file-api.yaml文件里
  • file.gomain函數(shù)所在文件,文件名跟service同名,去掉了后綴-api
  • internal/config目錄:服務的配置定義
  • internal/handler目錄:API文件里定義的路由對應的handler實現(xiàn)
  • internal/logic目錄:用來放每個路由對應的業(yè)務處理邏輯,之所以區(qū)分handlerlogic是為了讓業(yè)務處理部分盡可能減少依賴,把HTTP requests和邏輯處理代碼隔離開,便于后續(xù)按需拆分成RPC service
  • internal/svc目錄:用來定義業(yè)務邏輯處理的依賴,我們可以在main里面創(chuàng)建依賴的資源,然后通過ServiceContext傳遞給handlerlogic
  • internal/types目錄:定義了API請求和返回數(shù)據(jù)結(jié)構(gòu)

咱們什么也不改,先來跑一下看看效果。

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

實現(xiàn)業(yè)務邏輯

接下來我們需要實現(xiàn)相關(guān)的業(yè)務邏輯,但是這里的邏輯其實只是一個演示用途,無需過于關(guān)注實現(xiàn)細節(jié),只需要理解我們應該把業(yè)務邏輯寫在logic層即可。

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

增加配置項里的Path設(shè)置,用來放置上傳文件,默認值我寫了當前目錄,因為是示例,如下:

type Config struct {
  rest.RestConf
  // 新增
  Path string `json:",default=."`
}

調(diào)整了請求體的大小限制,如下:

Name: file-api
Host: localhost
Port: 8888
# 新增
MaxBytes: 1073741824

由于Download需要寫文件給客戶端,所以我們把ResponseWriter當成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

我們可以通過啟動file單體服務:

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

可以通過curl來驗證Download服務:

$ 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
...

示例倉庫里包含了upload.html,瀏覽器打開這個文件就可以嘗試Upload服務了。

單體開發(fā)的總結(jié)

我把用go-zero開發(fā)單體服務的完整流程歸納如下:

  • 定義各個子模塊的API文件,比如:download.apiupload.api
  • 定義總的API文件,比如:file.api。用來import步驟一定義的各個子模塊的API文件
  • 通過goctl api go命令生成單體服務框架代碼
  • 增加和調(diào)整配置,實現(xiàn)對應的子模塊的業(yè)務邏輯

另外,goctl可以根據(jù)SQL一鍵生成CRUD以及cache代碼,可以幫助大家更快速的開發(fā)單體服務。

項目地址

https://github.com/zeromicro/go-zero

到此這篇關(guān)于Go單體服務開發(fā)最佳實踐的文章就介紹到這了,更多相關(guān)go單體服務內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • Golang切片Slice功能操作詳情

    Golang切片Slice功能操作詳情

    這篇文章主要介紹了Golang切片功能操作詳情,切片是一個擁有相同類型元素的可變長度的序列。它是基于數(shù)組類型做的一層封,切片是一個引用類型,它的內(nèi)部結(jié)構(gòu)包含地址、長度和容量
    2022-09-09
  • 解決golang http.FileServer 遇到的坑

    解決golang http.FileServer 遇到的坑

    這篇文章主要介紹了解決golang http.FileServer 遇到的坑,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2020-12-12
  • go原子級內(nèi)存操作實現(xiàn)

    go原子級內(nèi)存操作實現(xiàn)

    原子級內(nèi)存操作是在多線程并發(fā)執(zhí)行時,能夠確保某個內(nèi)存操作是不可中斷的操作,本文主要介紹了go原子級內(nèi)存操作實現(xiàn),具有一定的參考價值,感興趣的可以了解一下
    2024-02-02
  • Golang Gob編碼(gob包的使用詳解)

    Golang Gob編碼(gob包的使用詳解)

    這篇文章主要介紹了Golang Gob編碼(gob包的使用詳解),具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2021-05-05
  • 構(gòu)建Golang應用最小Docker鏡像的實現(xiàn)

    構(gòu)建Golang應用最小Docker鏡像的實現(xiàn)

    這篇文章主要介紹了構(gòu)建Golang應用最小Docker鏡像的實現(xiàn),文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-05-05
  • Golang 定時器(Timer 和 Ticker),這篇文章就夠了

    Golang 定時器(Timer 和 Ticker),這篇文章就夠了

    這篇文章主要介紹了Golang 定時器(Timer 和 Ticker),這篇文章就夠了,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2020-10-10
  • Golang 刪除文件并遞歸刪除空目錄的操作

    Golang 刪除文件并遞歸刪除空目錄的操作

    這篇文章主要介紹了Golang 刪除文件并遞歸刪除空目錄的操作,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2021-04-04
  • Go語言中g(shù)oroutine的使用

    Go語言中g(shù)oroutine的使用

    本文主要介紹了Go語言中g(shù)oroutine的使用,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2023-06-06
  • Golang服務的請求調(diào)度的實現(xiàn)

    Golang服務的請求調(diào)度的實現(xiàn)

    Golang服務請求調(diào)度是一種使用Go語言實現(xiàn)的服務請求管理方法,本文主要介紹了Golang服務的請求調(diào)度的實現(xiàn),具有一定的參考價值,感興趣的可以了解一下
    2023-08-08
  • Go語言中樂觀鎖與悲觀鎖的具體使用

    Go語言中樂觀鎖與悲觀鎖的具體使用

    樂觀鎖和悲觀鎖是兩種思想,用于解決并發(fā)場景下的數(shù)據(jù)競爭問題,本文主要介紹了Go語言中樂觀鎖與悲觀鎖的具體使用,具有一定的參考價值,感興趣的可以了解一下
    2024-01-01

最新評論