go-zero 是一个集成了各种工程实践的 Web 和 rpc 框架,它的弹性设计保障了大并发服务端的稳定性,并且已经经过了充分的实战检验。

go-zero 在设计时遵循了 “工具大于约定和文档” 的理念,所以 go-zero 包含极简的 API 定义和生成工具 goctl,可以根据定义的 API 文件一键生成 Go、iOS、Android、Kotlin、Dart、TypeScript、JavaScript 代码,并可直接运行。

1.png

△ go-zero 的架构图

如上图所示,不同客户端的请求都会先进入 go-zero 的 API 端。API 端最主要的作用是通过 ETCD 将对应的请求通过 gRPC 协议转发到 Service 端。根据请求的具体内容,Service 端负责对数据进行查询或存储。如果是查询请求,go-zero 有内置的 API 会先查询缓存层,减少数据库的查询压力。

由图可见,API 端和 Service 端中框架已经内置了非常丰富的功能,在开发过程中只需要我们填充对应的业务逻辑,即可轻松实现 CRDU 级的需求。

我们为什么说 go-zero 是开箱即用的微服务架构呢?不急,我们来盘点下 go-zero 中有哪些强大的特性。


go-zero 适合做微服务快速开发的特性

Go-zero 拥有强大的项目脚手架工具 goctl。 goctl 和前端中的 Vue-cli、React-cli 一样方便。goctl 通过配置文件可以生成 API、rpc 和 model 等相关代码。 同时,go-zero 拥有较完备的项目框架。脚手架生成的项目框架足以应对常见的需求。CRDU 等需求只需要做 “填空题”,在已生成的代码上填充必要的业务逻辑。 其他缓存鉴权等需求,框架中也早已内置。

另外,go-zero 拥有独特的“渐进式”框架。“渐进式”是前端 Vue 框架的一大特性,大意是“易于上手,还便于与第三方库或既有项目整合”。本文借用这个概念是想表明 go-zero 对项目的入侵性较少,go-zero 生成的代码可以拆开使用,逐步对老项目进行改造。

低耦合的模块设计,丰富的中间件,插件和工具:

  • go-zero 中各模块耦合程度低,我们可以通过文档中的组件中心寻找合适的中间件或自研中间件。

  • 如果觉得 goctl 不能满足需求,goctl 还支持 plugin 命令对 goctl 进行扩展。

  • go-zero 的很多配置文件是自定义语法。 go-zero 还提供了 intellij 和 vscode 插件,提供了语法高亮错误检查等编辑增强功能。


goctl 介绍

goctl 是 go-zero 微服务框架下的代码生成工具。使用 goctl 可显著提升开发效率,让开发人员将时间重点放在业务开发上。

2.png

goctl 的命令可归纳为如下几类:

  • API 命令,快速生成一个 API 服务

  • rpc 命令,支持 proto 模板生成和 rpc 服务代码生成

  • model 命令,目前支持识别 mysql ddl 进行 model 层代码生成

  • plugin 命令,支持针对 API 自定义插件

  • 他命令,目前是发布相关

goctl 的命令众多,本次涉及到的只是其中 API、rpc 和 model 相关的基础命令。

使用 goctl 的基本流程

3.png

使用 goctl 生成代码的流程大致可以分为 4 步:

  • 使用命令 a 生成默认的配置文件;

  • 按照业务需求编辑该配置文件;

  • 使用命令 b 按照配置文件生成默认的代码文件;

  • 按照业务逻辑填充对应的代码文件。


什么情况不适宜使用 go-zero 做微服务快速开发?

看完上面的介绍,想必大家对于 go-zero 开发微服务已经有点跃跃欲试了吧。不过经过一番实践,我认为当出现以下情况时,不适宜采用 go-zero 作为开发微服务的框架。

当前需求与 goctl 的理念相冲突

go-zero 的一大卖点是脚手架工具 goctl,如果定制需求过多可能与 goctl 生成的代码相冲突。但是如果放弃 goctl 手动编写代码的话,开发效率会大大降低。

4.png

举个例子,如上图所示,go-zero 在 Service 端目前只支持 gRPC,在数据库层只支持 Mysql、MongoDB 和 ClickHouse,服务发现只支持 ETCD。在这种情况下如果想实现 PostgreSQL 替换 Mysql、Consul 替换 ETCD 等定制操作,goctl 生成的代码执行时很可能会出现异常。

希望框架提供的功能非常完善

go-zero 大部分组件是自研,比如 sqlx,httpx 等。这些自研组件满足 CRDU 的操作绰绰有余,但是与 gorm、gin 等专攻某一方向的开源项目相比还是有非常大的差距的。

所以随着公司业务发展需求越来越五花八门,当前的主要矛盾从“快速开发”变成“精细化开发”时,会发现该框架有这样或那样的不足。这种情况下就需要提 RP 或自己 fork 一份魔改了。个人觉得这种情况比 Spring 或 Django 那样一个“全家桶” 改动起来要省力省心。