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

grafana 是非常强大的可视化项目，它最早从 kibana 生成出来，渐渐也已经形成了自己的生态了。研究完 grafana 生态之后，只有一句话：可视化，grafana 就够了。

这篇就想了解下它的主体架构是如何设计的。如果你对 grafana 有兴趣，不妨让这篇成为入门读物。

grafana 的最外层就是一个 build.go，它并不是真正的入口，它只是用来编译生成 grafana-server 工具的。

grafana 会生成两个工具，grafana-cli 和 grafana-server。

go run build.go build-server 其实就是运行

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 外层包了一个结构，包含了服务的名字和服务的优先级。

type Descriptor struct {
    Name         string
    Instance     Service
    InitPriority Priority
}

这个包提供的三个注册方法：

RegisterServiceWithPriority
RegisetrService
Register

这三个注册方法都是把 Descriptior（本质也就是 Service）注册到一个全局的数组中。

取的时候也很简单，就是把这个全局数组按照优先级排列就行。

那么什么时候执行注册操作呢？答案就是在每个 Service 的 init() 函数中进行注册操作。所以我们可以看到代码中有很多诸如：

_ "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() 方法：

type Service interface {
    Init() error
}

而定义了其他不同的接口，比如需要后端启动的服务：

type BackgroundService interface {
    Run(ctx context.Context) error
}

需要数据库注册的服务：

type DatabaseMigrator interface {
    AddMigration(mg *migrator.Migrator)
}

需要根据配置决定是否启动的服务：

type CanBeDisabled interface {
    IsDisabled() bool
}

在具体使用的时候，根据判断这个 Service 是否符合某个接口进行判断。

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 中的：

type UserAuthTokenService struct {
    SQLStore          *sqlstore.SQLStore            `inject:""`
    ServerLockService *serverlock.ServerLockService `inject:""`
    Cfg               *setting.Cfg                  `inject:""`
    log               log.Logger
}

这里可以看到 SQLStore 中有额外的注入 tag。那么在 pkg/server/server.go 中的

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 的时候返回。

大体代码如下：

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 的具体实现还有待研究。

有疑问加站长微信联系（非本文作者））