go-zero：开箱即可使用的微服务框架

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

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

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 可明显提升开发效率，让开发人员将时间重点放在业务开发上。

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

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

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

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

• plugin 命令，支持针对 API 自己设置插件

• 其余命令，目前是发布相关

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

使用 goctl 的基本流程

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

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

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

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

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

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

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

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

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

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

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

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

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