下一代 Sniper 框架

2021-08-01

两年前我写了Sniper 轻量级 go 业务框架的思考,一年前写了Sniper 框架两周年回顾。又一年过去了,我对 Sniper 框架有了新的认识。今年考虑发布一个新的版本,现在介绍一下未来可能引入的改动。

微调目录结构

原来的 util 工具包会改成 pkg,跟社区保持一致。util 改成 pkg 后就只有 service 不是三字母文件夹了。索性改成 svc,全用三个字母的名字,整齐划一。

原来的 cmd/server 改成 cmd/http,原来的cmd/job 改成 cmd/cron,这样大家一看就明白每个子命令的作用。再就是将 cmd/http/main.go 和 cmd/http/cmd.go 合并,这样在 cmd/http 和 cmd/cron 下各有一个 cmd.go 文件来定义启动逻辑,另外各有一个「路由」文件(http.go 和 cron.go)来注册业务逻辑。如此调整,来实现一种内在的统一。

最开始我是想把 cmd/http/hooks/ 挪到 pkg 包的,因为新版本支持指定服务和接口级的 hook 了(下面会讲)。在 rpc 目录引用 cmd/http/hooks 包感觉不太科学。但是,移到 pkg 目录也会带来项目引用层级的混乱。因为有些业务上的 hook(比如登录)需要调用 dao 层。一般来说只应该在 dao 层引用 pkg,而不该在 pkg 引用 dao。考虑再三,还是把 hooks 放在 cmd/http 目录吧。如果有业务需要开发自己的 hook,可以放到 svc/hooks 目录。这样引用层级则变成 cmd -> rpc -> svc -> dao -> pkg,没毛病。

清理遗留业务逻辑

Sniper 项目的代码一直是从公司业务代码自动生成的。也就是说,我们有一个脚本,会自动将业务无关的逻辑同步到 Sniper 开源项目。这样做的优点是方便同步开源代码。但缺点也很明显,一方面要维护一个比较复杂的同步脚本;另一方面开源项目里难免会夹杂一些业务上遗留的代码。

随着业务的发展,在我们内部已经用多个项目在使用 Sniper 框架。为了方便维护,我们把公共的部分抽了出来,形成一个单独的工具包。这样我们内部使用的框架跟开源版就无法保持代码同步了。这样也好,可以抛弃历史包袱,做到更快速地迭代。

在我们内部没法合并 rpc 和 server 层的代码,所以有两套生成和注册的代码逻辑,现在可以清除了。框架会真对 v0 版本的接口作特殊处理,只有添加 --internal 参数启动才能注册对应接口。这也是我们内部的逻辑,现在也可以清理了。

脱离了业务的羁绊,Sniper 框架会朝着更加纯粹的方向演进。

支持服务和接口级的 hook

之前 Sniper 框架只支持全局 hook,不能针对服务或者接口指定。这在使用上非常麻烦。为

为了绕过这个问题,最早是定义两组 hooks,一组不校验登录态,另一组校验。然后在生成代码的时候通过 --need-login 参数指定使用哪组 hooks。是不是很傻。

后来我还想了一个办法。就是在 rpc 的声明中加入 //sniper:foo这样的行尾注释。框架在生成代码的时候会把 foo 注入到请求的 ctx 中。hook 在处理请求的时候可以读到(通过 twirp.MethodOption 方法)这个 foo 然后做不同的处理。这个方案稍微好那么一点,但依然很二。

现在是时候支持服务和接口级的 hook 了。用法也非常简单。每个服务在生成的时候会自动插入下面的方法:

func (s *FooServer) Hooks() map[string]*twirp.ServerHooks {
  return map[string]*twirp.ServerHooks{
    // "": nil, // Server 一级 hooks
    // "Echo": nil, // Echo 方法的 hooks
  }
}

这个 Hooks 一个特殊的方法,返回一个 map,key 是接口函数名,值是对应的 hook。如果你想给所有接口设定 hook,则可以使用空字符串""作为 key 指定 hook。框架在运行的时候会先执行全局 hook。然后尝试执行接口的 hook。如果接口定义了 hook,则只会执行接口 hook;如果接口没有定义 hook,则尝试执行服务的 hook(也就是 key 为 "" 的 hook)。

通过这种方式,每个服务都会有自己的 hook,互不影响。用起来也比较方便。如果不需要指定服务或者接口一级的 hook,则可以返回 nil 甚至不需要声明 Hooks 方法。

这种设计可能不是最好的,但跟之前的方案要优雅不少。

集成 OpenTelemetry

分布式系统要想平稳运行,一定要支持所谓「可观测」特性。Sniper 项目虽然简单,但也集成了 OpenTracing, Prometheus 和日志组件。但是 Sniper 目前做的还不够好,也就刚刚达到通用的水平。

目前业界在可观测领域已经取得了长足的发展,最重要的就是诞生了 OpenTelemetry 项目。简单来说 OpenTelemetry 就是把 trace, metrics 和 log 三种观测手段合并,对上提供统一的 API 和 SDK,对下提供统一的 Agent 来适配不同的存储后端。

目前 OpenTelemetry 的 trace 特性已经稳定,而 metrics 和 log 估计在 2021 年年底也会正式发布。已经有很多项目(比如 go-redis)接入 OpenTelemetry。Sniper 框架会持续关注 OpenTelemtry 项目的进展。等 metrics 和 log 特性稳定之后会立马启动适配工作。

集成更多业务组件

Sniper 作为一个轻量级的框架,并没有集成太多的组件。之所以这样做,一方面是不同的业务对基础组件有不同的要求;另一方面,我们内部的封装功能并不完善(主要是可观测相关的支持)。所以框架把这些事情留给了业务开发者。

但这样做无疑增加了初学者的使用和学习成本。大家甚至认为 Sniper 太过简陋,不能称之为一个完整的框架。为此,我认为后面至少应该集成数据库和缓存两个组件。

但不论要集成哪个组件,首先就得解决「可观测」的问题。

先说缓存。现还可以用 go-redis 了。因为 go-redis v8 版本不但支持传入 ctx,还支持集成 OpenTelemetry(目前好像只支持 trace)。对于 metrics 和 log,可以考虑等等看或者直接给 go-redis 贡献代码。

再说数据库首先还是不引入 ORM,这个大家可以看我前面写的文章。但三年的实践表明,裸写 sql 确实很繁琐,尤其是写 select 语句和 scan 方法,字段一多简直爆炸。为此,我想引入 sqlx。sqlx 最吸引我的地方就是 StructScan 功能,可以实现下面的效果:

type Place struct {
  Country       string
  City          sql.NullString
  TelephoneCode int `db:"telcode"`
}

rows, err := db.Queryx("SELECT * FROM place")
for rows.Next() {
  var p Place
  err = rows.StructScan(&p)
}

用 20% 的代码解决 80% 的问题,非常优雅。我也看过它的实现,确实用了反射,但会缓存反射结果,性能损失可以忽略。

但有一个问题,目前无论是 sqlx 还是 database/sql 都不支持事件回调(估计以后也不会支持,参考这里),也就不能很好地集成 OpenTelemetry 等观测组件。我查了一下,目前最优雅的方案是写一个 driver wrapper,可以使用 sqlmw。后面会看一下如何集成。

目前的 http 组件也会重新改造以适配 OpenTelemetry。

最终,Sniper 框架会开箱提供数据库、Redis 和 HTTP 客户端三大组件,对于一般的项目基本也够用了。

完善文档&国际化

目前的文档都散落在不同的 README 文件中,不是很系统,有的还不完善。后面会统一整理放到单独的站点(使用 GitHub Page 实现)。项目的核心文档会翻译成英文,希望能吸引外国人使用和参与开发。

目前 Sniper 框架比较特色的地方就在于代码自动生成和注册。这一部分会涉及到 protobuf 插件开发和 go 语法树解析,有一定的难度。后面会将这部分的功能和设计都整理成文档,目标是让所有 go 程序员都能看懂,都能根据自己的需要完成定制。

总结

总得来说,Sniper 框架会一直朝着轻量化、标准化方向发展,在满足业务迭代的同时也时刻关注业界最新的技术进展并加以融合。Sniper 框架的初衷是为开发者提供一套借鉴的思路、提供一个修改的蓝本。这一点从未改变。

部分改动已经推送到 github ,有兴趣的朋友可以尝试一下。

「taoshu」微信公众号