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>