​grafana 的主体架构是如何设计的?

jianfengye110 · · 695 次点击 · · 开始浏览    
这是一个创建于 的文章,其中的信息可能已经有所发展或是发生改变。

​grafana 的主体架构是如何设计的? grafana 是非常强大的可视化项目,它最早从 kibana 生成出来,渐渐也已经形成了自己的生态了。研究完 grafana 生态之后,只有一句话:可视化,grafana 就够了。 这篇就想了解下它的主体架构是如何设计的。如果你对 grafana 有兴趣,不妨让这篇成为入门读物。 # 入口代码 grafana 的最外层就是一个 build.go,它并不是真正的入口,它只是用来编译生成 grafana-server 工具的。 grafana 会生成两个工具,grafana-cli 和 grafana-server。 go run build.go build-server 其实就是运行 ```goalng go build ./pkg/cmd/grafana-server -o ./bin/xxx/grafana-server ``` 这里可以划重点学习一下: 如果你的项目要生成多个命令行工具,又或者有多个参数,又或者有多个操作,使用 makefile 已经很复杂了,我们是可以这样直接写个 build.go 或者 main.go 在最外层,来负责编译的事情。 所以真实的入口在 ./pkg/cmd/grafana-server/main.go 中。可以跟着这个入口进入。 # 设计结构 这篇不说细节,从宏观角度说下 grafana 的设计结构。带着这个架构再去看 granfana 才更能理解其中一些细节。 grafana 中最重要的结构就是 Service。 grafana 设计的时候希望所有的功能都是 Service。是的,所有,包括用户认证 UserAuthTokenService,日志 LogsService, 搜索 LoginService,报警轮训 Service。 所以,这里需要设计出一套灵活的 Service 执行机制。 理解这套 Service 机制就很重要了。这套机制有下列要处理的地方: ## 注册机制 首先,需要有一个 Service 的注册机制。 grafana 提供的是一种有优先级的,服务注册机制。grafana 提供了 pkg/registry 包。 在 Service 外层包了一个结构,包含了服务的名字和服务的优先级。 ```golang type Descriptor struct { Name string Instance Service InitPriority Priority } ``` 这个包提供的三个注册方法: ```golang RegisterServiceWithPriority RegisetrService Register ``` 这三个注册方法都是把 Descriptior(本质也就是 Service)注册到一个全局的数组中。 取的时候也很简单,就是把这个全局数组按照优先级排列就行。 那么什么时候执行注册操作呢?答案就是在每个 Service 的 init() 函数中进行注册操作。所以我们可以看到代码中有很多诸如: ```golang _ "github.com/grafana/grafana/pkg/services/ngalert" _ "github.com/grafana/grafana/pkg/services/notifications" _ "github.com/grafana/grafana/pkg/services/provisioning" ``` 的 import 操作,就是为了注册服务的。 ## Service 的类型 如果我们自己定义 Service,差不多定义一个 interface 就好了,但是实际这里是有问题的。我们有的服务需要的是后端启动,有的服务并不需要后端启动,而有的服务需要先创建一个数据表才能启动,而有的服务需要根据配置文件判断是否开启。要定义一个 Service 接口满足这些需求,其实也是可以的,只是比较丑陋,而 grafana 的写法就非常优雅了。 grafana 定义了基础的 Service 接口,仅仅需要实现一个 Init() 方法: ```golang type Service interface { Init() error } ``` 而定义了其他不同的接口,比如需要后端启动的服务: ```golang type BackgroundService interface { Run(ctx context.Context) error } ``` 需要数据库注册的服务: ```golang type DatabaseMigrator interface { AddMigration(mg *migrator.Migrator) } ``` 需要根据配置决定是否启动的服务: ```golang type CanBeDisabled interface { IsDisabled() bool } ``` 在具体使用的时候,根据判断这个 Service 是否符合某个接口进行判断。 ```golang service, ok := svc.Instance.(registry.BackgroundService) if !ok { continue } ``` 这样做的优雅之处就在于在具体定义 Service 的时候就灵活很多了。不会定义很多无用的方法实现。 这个也是 golang 鸭子类型的好处。 ## Service 的依赖 这里还有一个麻烦的地方,Service 之间是有互相依赖的。比如 sqlstore.SQLStore 这个服务,是负责数据存储的。它会在很多服务中用到,比如用户权限认证的时候,需要去数据存储中获取用户信息。那么这里如果在每个 Service 初始化的时候进行实例化,也是颇为痛苦的事情。 grafana 使用的是 facebook 的 inject.Graph 包处理这种依赖的问题的。https://github.com/facebookarchive/inject。 这个 inject 包使用的是依赖注入的解决方法,把一堆实例化的实例放进包里面,然后使用反射技术,对于一些结构中有指定 tag 标签的字段,就会把对应的实例注入进去。 比如 grafana 中的: ```golangß type UserAuthTokenService struct { SQLStore *sqlstore.SQLStore `inject:""` ServerLockService *serverlock.ServerLockService `inject:""` Cfg *setting.Cfg `inject:""` log log.Logger } ``` 这里可以看到 SQLStore 中有额外的注入 tag。那么在 pkg/server/server.go 中的 ```golang services := registry.GetServices() if err := s.buildServiceGraph(services); err != nil { return err } ``` 这里会把所有的 Service (包括这个 UserAuthTokenService) 中的 inject 标签标记的字段进行依赖注入。 这样就完美解决了 Service 的依赖问题。 ## Service 的运行 Service 的运行在 grafana 中使用的是 errgroup, 这个包是 “golang.org/x/sync/errgroup”。 使用这个包,不仅仅可以并行 go 执行 Service,也能获取每个 Service 返回的 error,在最后 Wait 的时候返回。 大体代码如下: ```golang s.childRoutines.Go(func() error { ... err := service.Run(s.context) ... }) } defer func() { if waitErr := s.childRoutines.Wait(); waitErr != nil && !errors.Is(waitErr, context.Canceled) { s.log.Error("A service failed", "err", waitErr) if err == nil { err = waitErr } } }() ``` # 总结 理解了 Service 机制之后,grafana 的主流程就很简单明了了。如图所示。当然,这个只是 grafana 的主体流程,它的每个 Service 的具体实现还有待研究。 ![222222222.png](https://static.studygolang.com/201221/be7be5b01da92168286140cadcd1ab73.png)

有疑问加站长微信联系(非本文作者))

入群交流(和以上内容无关):加入Go大咖交流群,或添加微信:liuxiaoyan-s 备注:入群;或加QQ群:692541889

695 次点击  
加入收藏 微博
暂无回复
添加一条新回复 (您需要 登录 后才能回复 没有账号 ?)
  • 请尽量让自己的回复能够对别人有帮助
  • 支持 Markdown 格式, **粗体**、~~删除线~~、`单行代码`
  • 支持 @ 本站用户;支持表情(输入 : 提示),见 Emoji cheat sheet
  • 图片支持拖拽、截图粘贴等方式上传