关于go:Go-单体服务开发最佳实践

单体最佳实际的由来

• 对于很多初创公司来说，业务的晚期咱们更应该关注于业务价值的交付，并且此时用户体量也很小，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）服务。架构如下图：

单体实现

API 定义

应用过 go-zero 的同学都晓得，咱们提供了一个 API 格局的文件来形容 RESTful API，而后能够通过 goctl 一键生成对应的代码，咱们只须要在 logic 文件里填写对应的业务逻辑即可。咱们就来看看 download 和 upload 服务怎么定义 API.

Download 服务定义

示例需要如下：

• 通过 /static/<filename> 门路下载名为 <filename> 的文件
• 间接返回文件内容即可

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

syntax = "v1"

type DownloadRequest {File string `path:"file"`}

service file-api {
  @handler DownloadHandler
  get /static/:file(DownloadRequest)
}

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

1. syntax =“v1” 示意这是 zero-api 的 v1 语法
2. type DownloadRequest 定义了 Download 的申请格局
3. 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 UploadHandler
  post /upload returns (UploadResponse)
}

解释如下：

1. syntax =“v1” 示意这是 zero-api 的 v1 语法
2. type UploadResponse 定义了 Upload 的返回格局
3. service file-api 定义了 Upload 的申请路由

问题来了

Download 和 Upload 服务咱们都定义好了，那怎么能力放到一个服务里给用户提供服务呢？

不晓得仔细的你有没留神到一些细节：

1. 不论是 Download 还是 Upload 咱们在 request 和 response 数据定义的时候都加了前缀，并没有间接应用诸如 Request 或 Response 这样的
2. 咱们在 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 服务都导入进来了。但其中有几点须要留神的：

1. 定义的构造体不能重名
2. 所有文件里蕴含的 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.yaml
Starting server at 0.0.0.0:8888...

实现业务逻辑

接下来咱们须要实现相干的业务逻辑，然而这里的逻辑其实只是一个演示用处，无需过于关注实现细节，只须要了解咱们应该把业务逻辑写在 logic 层即可。

这里一共做了以下几件事：

• 减少配置项里的 Path 设置，用来搁置上传文件，默认值我写了当前目录，因为是示例，如下：

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

• 调整了申请体的大小限度，如下：

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 服务了。

单体开发的总结

我把用 go-zero 开发单体服务的残缺流程归纳如下：

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

另外，goctl 能够依据 SQL 一键生成 CRUD 以及 cache 代码，能够帮忙大家更疾速的开发单体服务。

我的项目地址

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

欢送应用 go-zero 并 star 反对咱们！

微信交换群

关注『微服务实际 』公众号并点击 交换群 获取社区群二维码。

如果你有 go-zero 的应用心得文章，或者源码学习笔记，欢送通过公众号分割投稿！