共计 1948 个字符，预计需要花费 5 分钟才能阅读完成。
go-zero 是一个集成了各种工程实际的 Web 和 rpc 框架，它的弹性设计保障了大并发服务端的稳定性，并且曾经通过了充沛的实战测验。
go-zero 在设计时遵循了“工具大于约定和文档”的理念，所以 go-zero 蕴含极简的 API 定义和生成工具 goctl，能够依据定义的 API 文件一键生成 Go、iOS、Android、Kotlin、Dart、TypeScript、JavaScript 代码，并可间接运行。
如上图所示，不同客户端的申请都会先进入 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 那样一个“全家桶”改变起来要省力省心。
举荐浏览
为 NSQ 配置监控服务的心路历程
Flink 在又拍云日志批处理中的实际
