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

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

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 会先查询缓存层,减小数据库的查询压力。mysql

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

咱们为何说 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 在又拍云日志批处理中的实践

相关文章
相关标签/搜索