背景

做服务端开发快 3 年了，陆陆续续也写了很多项目，cli 的、http server 的、rpc server 的、job 的 等等，也用了很多工具、框架。稍微多用几套框架后，发现大家写的都差不多，虽然具体的实现方式总有些差异，但都无关紧要，因此也逐渐认为框架没那么重要，习惯一种就好。

最近有一个自己的小项目要开发，服务端一直在想用什么方案。没想到真正做框架选择时，反倒拿捏不准，就像下棋时握着棋子却始终拿不定主意。

于是，重新反思一下 golang 下的几个主流框架，弄清楚各自的特点。

几个重要的框架

在 golang 的 server 开发领域，有一些广泛使用的服务框架：

• gin: 一个轻量的 http server 框架
  • 主要有 router、midware (log、recover等)、params binding、validator、ctx (request,response) 封装
  • 提供了 http server 所需要的基本能力，不多不少
  • 其他非 http 领域的则不进入，例如 orm、rpc、auth、cli、config、ws、log 等等
  • 因此，在实际开发中，需要开发者自行组装其他工具，有较强的灵活性
• echo、mux、router: 非常轻量的 router 管理
  • 几乎只有路由管理能力，其他都在 golang http 原生的 request 和 reponse 基础上操作，相比 gin 更加精简
  • 只能说比原生 http 包好用些，但在熟悉 gin 的情况下，几乎没有什么优势
• rpcx： 一个 rpc 框架
  • 这是 鸟窝 开发的一个 rpc 框架，主要用于服务端通信，也支持 http gateway 把 http 转为 rpc 请求。
  • 比较有意思的是，它把一切网络请求都抽象成一个 rpc 请求，而下一层无论使用 ws、tcp、http 甚至 udp (QUIC、KCP) 都可以。
  • 脱离具体的协议来看服务框架，是一个不错的扩宽视野的项目。
• goframe: 一个大而全的一站式服务端开发框架
  • 和 gin 不同的是，goframe 拥有一个后端项目开发过程中几乎所有的能力封装，包括但不限于 http、grpc、ws、cli、config、log、errors、validator、data convert、cache、template、orm、redis、i18n 等
  • 各种实用工具: 常用数据结构(map、array、set、list、var、queue、tree等)、系统相关工具、加解密 等
  • 微服务相关模块: 脚手架cli、服务发现、链路跟踪、负载均衡
  • server 开发相关工具: session、swagger、分页、cors、static 等等
  • 整体来说，goframe 就是一个只要你愿意全套采用他的方案的话，你几乎可以找到所有你需要的东西。
  • 它是一个统一的框架，对于小团队而言，能够很好地保证组件的统一性。
• go-kratos: 一个优雅的微服务框架
  • 和 gin 不同，go-kratos 和 goframe 在 微服务开发 上类似，都是一个涵盖了微服务开发过程中常用的工具。提供了 http server、grpc server、auth、metrics、tracing、validator、脚手架 cli 等。
  • 和 goframe 不同的是，go-kratos 聚焦于 微服务开发，不提供 orm、redis 之类的库，也不提供 ws 、cli 之类的能力，不提供 cron、加解密等非 http/rpc 之外的工具。
  • go-kratos 在服务治理方面做的很好，有可插拔的 auth、熔断、限流、负载均衡、服务注册/发现。
  • 在工程方面，go-kratos 提供的 脚手架 cli 在 通过 proto 生成基础代码 ，非常值得一提的是，go-kratos 提倡完全基于 proto 去管理所有的能力，例如 通过 proto 管理 errors、validator、http service、rpc service、types、config 之类的。【这点尤其重要】
  • 在项目结构方面，go-kratos 提倡三层架构，各层之间通过接口定义，项目使用 wire 进行串联组装，可以参考这个 example
• go-zero: 一个强约束的微服务框架
  • go-zero 和 gin 不同，和 go-kratos、goframe 类似。go-zero 从功能上介于 goframe 和 go-kratos 之间。go-zero 是一个专注于微服务开发的框架，这点和 go-kratos 类似。但同时，go-zero 提供了更多的工具，例如 bloom、hash、color、orm、cache、jwt、set、ring 等等，这点和 goframe 类似。
  • go-zero 的工程结构上，有更多的约束，同时也减少了开发者的负担和项目的复杂度，这点比前几个框架都更加突出。使用 脚手架 cli 生成的项目结构，几乎完成了除业务逻辑之外的其他部分，包括 通过 proto/api 定义生成 controller、service，通过 sql 生成 model 等。
  • go-zero 的工程化做得很极致。

整体思考

整体来看，几个框架各有千秋，依然是较难抉择，或许，已经在用过 gin + 散装库 之后，会觉得都能接受，但同时也都不好接受吧……

其实，在目前 golang 的服务框架还没有形成明显的分化时，也就意味着大家各有所长，只要没有明显的短板，无论选用哪个框架，其结果差别都不大。

项目的开发，重点依然在 项目本身，框架没有明显差别时，选择一个更合自己心意的就行。

好烦啊啊啊啊，cli 我习惯用 cobra，orm 习惯用 gorm，通用工具库喜欢用 goframe 的，service 的开发又比较喜欢 go-kratos 的方案，go-zero 的结构约束又觉得对以后降低心智负担很有价值……

考虑到整体开发便利性，我决定先以 go-zero 为基础框架，辅之以 goframe 的工具库。

之后会以此进行一些项目的实践，并做一些使用的记录。

---

Gratitude is riches. Complaint is poverty.
— Doris Day