单体服务开发最佳实践

简介: 单体服务开发最佳实践

单体最佳实践的由来

  • 对于很多初创公司来说,业务的早期我们更应该关注于业务价值的交付,并且此时用户体量也很小,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 文件里填写对应的业务逻辑即可。我们就来看看 downloadupload 服务怎么定义 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-apiv1 语法
  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-apiv1 语法
  2. type UploadResponse 定义了 Upload 的返回格式
  3. service file-api 定义了 Upload 的请求路由

问题来了

DownloadUpload 服务我们都定义好了,那怎么才能放到一个服务里给用户提供服务呢?

不知道细心的你有没注意到一些细节:

  1. 不管是 Download 还是 Upload 我们在 requestresponse 数据定义的时候都加了前缀,并没有直接使用诸如 RequestResponse 这样的
  2. 我们在 download.apiupload.api 里面定义 service 的时候都是用的 file-api 这个 service name,并没有分别用 download-apiupload-api

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

定义单体服务接口

出于简单考虑,goctl 只支持接受单一 API 文件作为参数,同时接受多个 API 文件的问题不在此讨论,如有简单高效的方案,后续可能支持。

我们在 api 目录下创建一个新的 file.api 的文件,内容如下:

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

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

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

最外层的 API 文件也可以包含同一个 service 的部分定义,但我们推荐保持对称,除非这些 API 确实属于父层级,比如跟 DownloadUpload 属于同一个逻辑层次,那么就不应该放到 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.gomain 函数所在文件,文件名跟 service 同名,去掉了后缀 -api
  • internal/config 目录:服务的配置定义
  • internal/handler 目录:API 文件里定义的路由对应的 handler 实现
  • internal/logic 目录:用来放每个路由对应的业务处理逻辑,之所以区分 handlerlogic 是为了让业务处理部分尽可能减少依赖,把 HTTP requests 和逻辑处理代码隔离开,便于后续按需拆分成 RPC service
  • internal/svc 目录:用来定义业务逻辑处理的依赖,我们可以在 main 里面创建依赖的资源,然后通过 ServiceContext 传递给 handlerlogic
  • 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.apiupload.api
  2. 定义总的 API 文件,比如:file.api。用来 import 步骤一定义的各个子模块的 API 文件
  3. 通过 goctl api go 命令生成单体服务框架代码
  4. 增加和调整配置,实现对应的子模块的业务逻辑

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

项目地址

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

相关文章
|
27天前
|
消息中间件 监控 持续交付
后端开发中的微服务架构设计与实践####
在当今快速发展的软件开发领域,微服务架构已成为构建高效、可扩展和易于维护应用的关键策略。本文将深入探讨微服务架构的核心概念、设计原则与实战技巧,通过实例解析如何在后端开发中有效实施微服务,以应对复杂业务需求和技术挑战。我们将从微服务的拆分策略、通信机制、数据管理到持续集成/持续部署(CI/CD)流程,全面剖析其背后的技术细节与最佳实践,为读者提供一份详尽的微服务架构设计与实践指南。 ####
|
2月前
|
监控 API 开发者
后端开发中的微服务架构实践与优化
【10月更文挑战第17天】 本文深入探讨了微服务架构在后端开发中的应用及其优化策略。通过分析微服务的核心理念、设计原则及实际案例,揭示了如何构建高效、可扩展的微服务系统。文章强调了微服务架构对于提升系统灵活性、降低耦合度的重要性,并提供了实用的优化建议,帮助开发者更好地应对复杂业务场景下的挑战。
27 7
|
7月前
|
监控 数据管理 开发者
构建高效微服务架构:后端开发的现代实践
【5月更文挑战第30天】 在当今软件开发领域,微服务架构已成为提高系统可维护性、扩展性和开发效率的关键方案。本文深入探讨了构建高效微服务架构的策略,包括服务划分原则、通信机制、数据管理以及持续集成与部署的最佳实践。通过分析具体案例和最新技术趋势,文章旨在为后端开发者提供一套全面的指导,帮助他们在不断变化的技术环境中保持竞争力。
|
5月前
|
监控 Kubernetes 持续交付
后端开发中的微服务架构:原理、优势与实践
本文深入探讨了在现代后端开发中,微服务架构如何成为提升系统可维护性、扩展性和敏捷性的关键技术。文章首先定义了微服务并解释了其核心原理,随后通过数据和案例分析,展示了微服务架构如何优化开发流程和提高系统性能。最后,文中提供了实施微服务架构的实用建议,旨在帮助开发者更好地理解和应用这一架构模式。
|
7月前
|
监控 API 开发者
构建高效微服务架构:后端开发者的实用指南
【5月更文挑战第31天】 在当今快速迭代和部署的软件环境中,微服务架构已成为许多组织转型的首选模型。本文旨在为后端开发者提供构建和维护高效微服务系统的实用指南。通过深入探讨模块化设计原则、容器化技术、API网关以及持续集成/持续部署(CI/CD)的实践,我们阐述了如何优化系统性能并确保可扩展性和弹性。同时,本文还将讨论监控和日志管理策略,以确保系统的稳定性和可靠性。
|
7月前
|
消息中间件 API 数据库
构建高性能微服务架构:后端开发的终极指南
【5月更文挑战第27天】随着现代业务需求的不断演进,传统的单体应用架构逐渐显得笨重且难以维护。微服务架构以其灵活性、可扩展性和技术多样性成为企业转型的首选。本文将深入探讨如何构建一个高性能的微服务系统,涵盖关键设计原则、常用技术和实践案例,为后端开发人员提供一份全面的指南。
|
7月前
|
测试技术 持续交付 API
构建高效的微服务架构:后端开发的现代实践
【5月更文挑战第18天】在数字化转型的浪潮中,微服务架构已成为企业追求敏捷、可扩展和容错能力的关键解决方案。本文将深入探讨微服务的核心概念,包括其设计原则、技术栈选择以及实施过程中的挑战与对策。通过对微服务架构实践的详细剖析,旨在为后端开发人员提供一套构建和维护高效微服务系统的实用指南。
|
7月前
|
Java API 开发者
构建高效的微服务架构:后端开发者的实用指南
【5月更文挑战第17天】 随着现代软件开发的复杂性日益增加,传统的单体应用已难以满足快速迭代与灵活部署的需求。微服务架构作为解决这一问题的有效方案,已成为众多企业转型的首选架构模式。本文将深入探讨如何构建一个高效且可维护的微服务系统,涵盖关键设计原则、技术栈选择以及实践中的最佳实践。通过阅读本文,后端开发者将获得构建和优化微服务架构的核心知识,以支持业务的快速成长与创新。
|
6月前
|
负载均衡 搜索推荐 应用服务中间件
后端开发中的微服务架构设计与实践
传统的单一应用架构已经无法满足当今快速变化的业务需求,微服务架构因其灵活性和扩展性逐渐成为后端开发的主流选择。本文将探讨微服务架构设计与实践,包括微服务架构的概念、优势以及在后端开发中的应用。同时,将结合实际案例分析微服务架构的设计原则和最佳实践,以帮助开发者更好地理解和应用微服务架构。
|
7月前
|
监控 关系型数据库 持续交付
构建高效微服务架构:后端开发的最佳实践
【5月更文挑战第30天】随着现代应用的复杂性日益增加,微服务架构已成为众多企业和开发者的首选。本文将深入探讨如何构建一个高效的微服务系统,包括关键的设计原则、技术栈选择、以及确保系统稳定性和扩展性的实践方法。我们将通过实际案例分析,揭示后端开发中实现敏捷性和可维护性的策略,为追求卓越的软件工程师提供实用的指导。
下一篇
DataWorks