[Singo 诞生记] Gin+Gorm Golang API 快速开发脚手架搭建心路历程

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 1899 天前的主题，其中的信息可能已经有所发展或是发生改变。

大家好，我是橙卡。在这里向大家自荐一下我搭建的 Gin+Gorm Golang API 快速开发脚手架

Singo: https://github.com/bydmm/singo

在描述框架之前，请允许我介绍一下项目的选型历程。

因为看好 Golang 我一年前找了一份全职写 Go 后台的工作。入职之后，因为是比较独立的项目，老大要求我自己找一个 Golang 写 Web API 的方案，于是我就开始了各种方案考察。另外这个项目是比较独立的项目，后端资源有限（其实就我一个人），于是也不考虑微服务这种方向。

稍作搜索后就能发现，Beego 可以说是比较流行的 Go 服务开发框架了，然后就开始了研究。在观察了一小段时间之后，我就发现 Beego 是那种相对比较传统的 MVC 架构。对于我这种从 Rails 到 Django 一路写过来的 MVC 老油条来说，这种大而全的 MVC 框架的短板比较明显，而且在 9012 年也确实也显得的老土。

传统 MVC 架构，过于着墨于渲染 HTML 网页，但是现在新开发的应用，稍微有点能力的公司都是完全前后端分离的，我马上需要开发的项目也是这样。当你不使用 MVC 的渲染模板功能之后，你就会感觉那些多余的功能单纯在浪费内存的空间以及消耗毫无必要的性能。可以说，Ruby On Rails 就是在这样的潮流下迅速没落的。

于是我很快就放弃 Beego，然后去寻找下一个方案，那就是 Routing + ORM 这种模式。

在我写 Go 之前，其实已经有很长一段时间使用 Strina/Express/Flask + ORM 的开发模式。由于我之前有过上述三个框架的实际工作经验，所以总的来说还是即使是对 Go 还没有那么熟悉，但是总的套路我还是比较有把握的。很快 Gin + ORM 就进入到我的视线中。

首先聊聊 Gin。

其实 Gin 在 Golang 众多的 Routing 框架里面，并不算特别突出。不过他还算详尽的文档，不少人使用过的历史经验积累（也就是可以 google), 以及更为重要的是他的各种中间件阵容确实比其他一些框架来的丰富( https://github.com/gin-gonic/contrib)。比如 Gin 的 Session，jwt，限流，还有和 sentry 的整合，或者日志中间件都比较不错。虽然有一些 star 不算多，但是因为都挺简单，拿来抄抄改改都不算难。而且这些中间件你可以很方便的自行选择拼装到你得框架中，也不会很浪费资源。

至于 Gorm，对于一个用过 Rails ORM 的人来说，显然只能给个及格。不过考虑到 Go 语言极简设计的实际情况，你根本不可能找到一个能和 Rails 的 ActiveRecord 对抗的 ORM 框架，所以也就没必要太纠结了。

经过一段时间的折腾后，于是就诞生了这个 Singo 框架: https://github.com/bydmm/singo。这个框架已经在我实际工作中被使用，然后已经上线生产了两个项目。

一个项目是为某知名项目每天下发数百万到数千万次配置，这个项目的压力端功能确实相当简单，但是其μ秒级的响应也是非常惊艳的。这个项目还有运营和产品使用的后台服务，用来配置这些配置，那个项目也是 Singo 提供的后端服务，虽然压力很小，但是项目的业务也复杂的多，在这里我坚定了 Gin+GORM 无论在性能上，还是开发效率上都是没有问题的。

另一个项目相对流量较小，峰值日活也才刚超过百万，不过整体业务的压力分布则均衡的多，不会和配置下发一样旱的旱死涝的涝的死。这个项目就一个比较标准的 CRUD 项目，没什么特别可以说的。不过某日仅用 6 个虚拟核就抗住了近 10 万 /分钟的请求洪峰（那天真的是见鬼了），也让我见识了一下 Golang 的真实威力。不过这个业务也没非常长的交易流程这样的场景，都是比较简单和单纯的 CRUD 流程。

那么现在看来，至少 Singo 在平时大家最常见的 CRUD 场景，比如论坛，小说站，新闻站，视频站，或者类似的资讯发布站点，基本上是可以发挥出 Golang 的真实威力的。

最后提一下 Singo 的基本要素: