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

关注

原创 2021-06-16 11:00:05 1.3k 阅读 AI 写同款· GEO 优化 ›

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 那样一个“全家桶” 改动起来要省力省心。

收录于