单体最佳实践的由来
-
对于很多初创公司来说,业务的早期我们更应该关注于业务价值的交付,并且此时用户体量也很小,
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&g

本文介绍了使用Go语言进行单体服务开发的最佳实践,包括如何利用go-zero框架定义和生成服务,以及实现上传下载的业务逻辑。通过一个具体的文件服务示例,展示了如何将多个服务集成到一个单体服务中,提供了从接口定义到业务逻辑实现的完整过程。
最低0.47元/天 解锁文章
1072

被折叠的 条评论
为什么被折叠?



