Go单体服务开发最佳实践总结 Go单体服务开发最佳实践总结

单体最佳实践的由来
单体示例
单体实现

API 定义
Download 服务定义
Upload 服务定义
问题来了
定义单体服务接口
生成单体服务
实现业务逻辑

单体开发的总结

项目地址

单体最佳实践的由来

对于很多初创公司来说，业务的早期我们更应该关注于业务价值的交付，并且此时用户体量也很小，QPS 也非常低，我们应该使用更简单的技术架构来加速业务价值的交付，此时单体的优势就体现出来了。
正如我直播分享时经常提到，我们在使用单体快速交付业务价值的同时，也需要为业务的发展预留可能性，我们可以在单体里面清晰的拆分业务模块。
go-zero 社区里也有很多小伙伴在问，咱们单体开发的最佳实践应该是怎样的。

而 go-zero 作为一个被广泛使用的渐进式微服务框架来说，也是我在多个大型项目完整发展过程中沉淀出来的，自然我们也充分考虑了单体服务开发的场景。
如图所示的使用 go-zero 的单体架构，也可以支撑很大体量的业务规模，其中 Service 是单体服务的多个 Pod。

文章图片

我就通过本文详细跟大家分享一下如何使用 go-zero 快速开发一个有多个模块的单体服务。

单体示例我们用一个上传下载的单体服务来讲解 go-zero 单体服务开发的最佳实践，为啥用这么个示例呢？

go-zero 社区里经常有同学会问上传文件怎么定义 API 文件，然后用 goctl 自动生成。初见此类问题会觉得比较奇怪，为啥不用 OSS 之类的服务呢？发现很多场景是用户需要上传一个excel，然后服务端解析完也就丢弃此文件了。一是文件较小，二是用户量也不大，就不用那么复杂的通过 OSS 来绕一圈了，我觉得也挺合理的。
go-zero 社区也有同学问下载文件怎么通过定义一个 API 文件然后 goctl 自动生成。此类问题之所以通过 Go 来做，问下来一般两个原因，一是业务刚开始，能简单点布一个服务搞定就一个吧；二是希望能吃上 go-zero 的内置 JWT 自动鉴权。

仅以此为示例，无需深入探讨上传下载是否应该通过 Go 来实现。那么接下来我们就看看我们怎么通过 go-zero 来解决这么一个单体服务，我们称之为文件（file）服务。架构如下图：
【Go单体服务开发最佳实践总结】

文章图片

单体实现
API 定义
使用过 go-zero 的同学都知道，我们提供了一个 API 格式的文件来描述 RESTful API，然后可以通过 goctl 一键生成对应的代码，我们只需要在 logic 文件里填写对应的业务逻辑即可。我们就来看看 download 和 upload 服务怎么定义 API.

Download 服务定义
示例需求如下：

通过 /static/ 路径下载名为的文件
直接返回文件内容即可

我们在 api 目录下创建一个名为 download.api 的文件，内容如下：

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

zero-api 的语法还是比较能自解释的，含义如下：

syntax = “v1” 表示这是 zero-api 的 v1 语法
type DownloadRequest 定义了 Download 的请求格式
service file-api 定义了 Download 的请求路由

Upload 服务定义
示例需求如下：

通过 /upload 路径上传文件
通过 json 返回上传状态，其中的 code 可用于表达比 HTTP code 更丰富的场景

我们在 api 目录下创建一个名为 upload.api 的文件，内容如下：

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

解释如下：

syntax = “v1” 表示这是 zero-api 的 v1 语法
type UploadResponse 定义了 Upload 的返回格式
service file-api 定义了 Upload 的请求路由

问题来了
Download 和 Upload 服务我们都定义好了，那怎么才能放到一个服务里给用户提供服务呢？
不知道细心的你有没注意到一些细节：

不管是 Download 还是 Upload 我们在 request 和 response 数据定义的时候都加了前缀，并没有直接使用诸如 Request 或 Response 这样的
我们在 download.api 和 upload.api 里面定义 service 的时候都是用的 file-api 这个 service name，并没有分别用 download-api 和 upload-api

这么做的目的其实就是为了我们接下来把这两个服务放到同一个单体里自动生成对应的 Go 代码。让我们来看看怎么把 Download 和 Upload 合并起来~

定义单体服务接口
出于简单考虑，goctl 只支持接受单一 API 文件作为参数，同时接受多个 API 文件的问题不在此讨论，如有简单高效的方案，后续可能支持。
我们在 api 目录下创建一个新的 file.api 的文件，内容如下：

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

这样我们就像 C/C++ 的 #include 一样把 Download 和 Upload 服务都导入进来了。但其中有几点需要注意的：

定义的结构体不能重名
所有文件里包含的 service name 必须是同一个

最外层的 API 文件也可以包含同一个 service 的部分定义，但我们推荐保持对称，除非这些 API 确实属于父层级，比如跟 Download 和 Upload 属于同一个逻辑层次，那么就不应该放到 file.api 里面定义。

至此，我们的文件结构如下：

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

生成单体服务
既然已经有了 API 接口定义，那么对于 go-zero 来说，接下来的事情就很简单直接了（当然，定义 API 也挺简单的，不是吗？），让我们来使用 goctl 生成单体服务代码。

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

我们来看看生成后的文件结构：

.├── 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

我们来按目录解释一下项目代码的构成：

api 目录：我们前面定义的 API 接口描述文件，无需多言
etc 目录：这个是用来放置 yaml 配置文件的，所有的配置项都可以写在 file-api.yaml 文件里
file.go：main 函数所在文件，文件名跟 service 同名，去掉了后缀 -api
internal/config 目录：服务的配置定义
internal/handler 目录：API 文件里定义的路由对应的 handler 实现
internal/logic 目录：用来放每个路由对应的业务处理逻辑，之所以区分 handler 和 logic 是为了让业务处理部分尽可能减少依赖，把 HTTP requests 和逻辑处理代码隔离开，便于后续按需拆分成 RPC service
internal/svc 目录：用来定义业务逻辑处理的依赖，我们可以在 main 里面创建依赖的资源，然后通过 ServiceContext 传递给 handler 和 logic
internal/types 目录：定义了 API 请求和返回数据结构

咱们什么也不改，先来跑一下看看效果。

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

实现业务逻辑
接下来我们需要实现相关的业务逻辑，但是这里的逻辑其实只是一个演示用途，无需过于关注实现细节，只需要理解我们应该把业务逻辑写在 logic 层即可。
这里一共做了以下几件事：
增加配置项里的 Path 设置，用来放置上传文件，默认值我写了当前目录，因为是示例，如下：

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

调整了请求体的大小限制，如下：

Name: file-apiHost: localhostPort: 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 OKTraceparent: 00-831431c47d162b4decfb6b30fb232556-dd3b383feb1f13a9-00Date: Mon, 25 Apr 2022 01:50:58 GMTContent-Length: 584Content-Type: text/plain; charset=utf-8...

示例仓库里包含了 upload.html，浏览器打开这个文件就可以尝试 Upload 服务了。

单体开发的总结我把用 go-zero 开发单体服务的完整流程归纳如下：

定义各个子模块的 API 文件，比如：download.api 和 upload.api
定义总的 API 文件，比如：file.api。用来 import 步骤一定义的各个子模块的 API 文件
通过 goctl api go 命令生成单体服务框架代码
增加和调整配置，实现对应的子模块的业务逻辑

另外，goctl 可以根据 SQL 一键生成 CRUD 以及 cache 代码，可以帮助大家更快速的开发单体服务。

项目地址 https://github.com/zeromicro/go-zero
到此这篇关于Go单体服务开发最佳实践的文章就介绍到这了,更多相关go单体服务内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！