用Go造*-管理集群中的配置文件

写在前面

最近一年来，我都在做公司的RTB广告系统，包括SSP曝光服务，ADX服务和DSP系统。因为是第一次在公司用Go语言实现这么一个大的系统，中间因为各种原因造了很多*。现在稍微有点时间，觉着有必要总结这一年来用Go造*的经验和不足。

集群中遇到的配置文件管理问题

RTB广告系统中涉及到的服务程序并不算很多，但是因为RTB系统会面临很多的流量，而且为了确保可用性，最基本的就是多实例组成集群，同时考虑到后续业务增长，集群的扩缩容也是要做的。我们在设计的时候，基于ZoooKeeper做了服务发现，而我们的服务接入依靠Nginx集群，然后通过反向代理把请求负载均衡到不同的服务实例中。这里就存在以下问题：

• 当我们升级某个服务时，如何通知Nginx集群自动的摘除或者添加该服务实例，保证我们的升级不会影响到业务和用户体验
• 进一步，任意一个服务集群内的配置数据该如何自动更新和应用?

业界方案

业界其实有很多成熟的方案解决这类问题：

• 比如开源项目consul-template，但是这个工具只支持后端consul，而我们用的是ZooKeeper
• 再比如confd，可以支持多种后端，比如etcd或者zookeeper，但是它用的ZooKeeper客户端不支持在故障时对业务请求进行重试，比如发起了一个GetW请求，而Session变成超时状态，这个时候GetW返回的Channel就不可用了，只能重新发起请求，但是重试多少次请求其实是不知道的，针对这个情况，我还在项目一开始的时候实现了新的包，加入了对业务层透明的重试机制。

整体工作流程

1. 解析模版，获取要动态查询的节点
2. 向指定的服务器，比如ZooKeeper发起查询请求，并观察指定节点的变化
3. 当第一次或者节点发生变更后，查询最新数据
4. 把最新数据应用到模版中生成新的配置文件数据
5. 保存最新的配置文件数据到目标路径，并调用指定的命令应用最新的配置文件

实现

模版机制

Go官方标准库提供了Template包，支持if, range等控制语句，也支持用户自定义方法。模版机制的方便之处在于，它本身是一种DSL,也算是一种支持计算的超级printf。举例如下：

package main

import (
	"os"
	"text/template"
)

var tplContent = `
    {{range service "apiGateWay" }}
        server {{.Name}} {{.ID}} {{.Address}}
    {{end}}`

type ApiGateWayService struct {
	Name    string
	ID      string
	Address string
}

func main() {
	tmpl, err := template.New("test.template").Funcs(template.FuncMap{
		"service": func(serviceName string) []ApiGateWayService {
			return []ApiGateWayService{
				{
					Name:    "test",
					ID:      "1",
					Address: "192.168.1.100:9200",
				},
			}
		},
	}).Parse(tplContent)
	if err != nil {
		panic(err)
	}

	tmpl.Execute(os.Stdout, nil)、
}

上面的代码实际上是做了类似这样的过程，为了简单描述，我还是直接写一段GO代码

package main

import (
	"fmt"
	"os"
)

type ApiGateWayService struct {
	Name    string
	ID      string
	Address string
}

func service(serviceName string) []ApiGateWayService {
	return []ApiGateWayService{
		{
			Name:    "test",
			ID:      "1",
			Address: "192.168.1.100:9200",
		},
	}
}

func main() {
	for _, v := range service("apiGateWay") {
		fmt.Fprintf(os.Stdout, "server %s %s %s", v.Name, v.ID, v.Address)
	}
}

解析和渲染模版

上面的代码中，模版内容如下：

var tplContent = `
    {{range service "apiGateWay" }}
        server {{.Name}} {{.ID}} {{.Address}}
    {{end}}`

• 当我们拿到这么一个模板时，我们是不知道它是不是合法的，也许有语法错误，所以得先需要校验。这个我们可以调用template.Parse方法进行解析、校验语法。
• 当语法没有问题时，我们就开始进行渲染。在我们这个示例中，模版引擎会在渲染时调用service方法并对其返回结果进行循环处理，然后输出相应的数据到一个io.Writer中。service方法主要功能是根据传入的服务名，去ZK中查询相应的节点的所有子节点的数据，然后返回相应的数据。
  1. 当我们程序第一次运行时，实际上我们还没准备好指定服务的数据，但是我们至少在这一次知道了它要查询哪个服务的数据，并且我们这时可以启动goroutine去后台轮询查询数据，并把这些数据放入到缓存中
  2. 那么当我们之后再渲染时，就可以直接缓存中查询指定服务的所有实例（也就是子节点）的数据，然后就可以渲染出最终想要的配置文件数据。之后就可以保存了。

整个代码实现中略微复杂，其中的核心既不是如何缓存，也不是后台如何查询，而是要记录下未知的服务名，以及假如已经知道了服务名并且缓存了数据，如何从缓存中查询数据，这个过程还是拿service方法举例，代码如下：

func serviceFunc(tracker *DataTracker, used, missing map[string]dependency.Dependency) func(...string) ([]dependency.Service, error) {
	return func(s ...string) ([]dependency.Service, error) {
		var r []dependency.Service

		if len(s) == 0 || s[0] == "" {
			return r, nil
		}

		d, err := dependency.ParseService(s...)
		if err != nil {
			return nil, err
		}

		addDependency(used, d)

		data, ok := tracker.Get(d)
		if ok {
			return data.([]dependency.Service), nil
		}

		addDependency(missing, d)
		return r, nil
	}
}

其中tracker表示的是缓存对象，used和missing是一个map，其中value类型是dependency.Dependency, key为一个Dependency的HashCode，也就是一个唯一身份标识。

Dependency是一个接口，主要用于查询数据，是一个阻塞过程。serviceFunc返回一个lambda，内部主要主要的事情是记录哪个Dependency对象用到了，并且尝试从tracker中查询缓存数据，如果有就返回，没有更新missing，记录Dependency对象没有相应的缓存数据，然后返回空数据。

数据查询

当我们完成了解析和渲染过程后，我们要检查渲染过程中记录的missing是否不为空，如果不空，就需要发起后台查询进行处理，大体过程如下：

if len(missing) > 0 {
    for _, v := range missing {
        if !r.watcher.Watching(v) {
            r.watcher.Add(v)
            log.Debug("try to watch dependency", v.HashCode())
        }
    }

    continue
}

其中每个Dependency对象都有一个Fetch方法，当通过Watcher.Add方法时，就会启动一个独立的goroutine负责调用Dependency.Fetch方法，然后通过channel把Dependency.Fetch的结果转给DataTracker进行缓存。

渲染结果保存

• 当渲染模板成功后，就得到了一个新的配置文件数据。首先我们要检查生成的配置文件是否和原有的配置文件有差异，没有差异的就不需要保存了。
• 其次在保存时，有可能出现任何以外，为了确保出现以外时，能够恢复回来，我们需要对原有的配置文件进行备份。同时，我们为了确保新的配置文件能够落入到磁盘上，每次写入文件后都调用Sync方法强制刷新到磁盘上。主要实现如下：

func atomicWrite(path string, contents []byte, perms os.FileMode, backup bool) error {
	parent := filepath.Dir(path)
	if _, err := os.Stat(parent); os.IsNotExist(err) {
		if err := os.MkdirAll(parent, 0755); err != nil {
			return err
		}
	}

	f, err := ioutil.TempFile(parent, "")
	if err != nil {
		return err
	}
	defer os.Remove(f.Name())

	if _, err := f.Write(contents); err != nil {
		return err
	}

	if err := f.Sync(); err != nil {
		return err
	}

	if err := f.Close(); err != nil {
		return err
	}

	if err := os.Chmod(f.Name(), perms); err != nil {
		return err
	}

	if backup {
		if _, err := os.Stat(path); !os.IsNotExist(err) {
			if err := copyFile(path, path+".bak"); err != nil {
				return err
			}
		}
	}

	if err := os.Rename(f.Name(), path); err != nil {
		return err
	}

	return nil
}

命令执行

当保存好文件后，我们需要调用指定的命令，通知相应的程序加载最新的配置，主要代码如下：

func execute(command string, timeout time.Duration) error {
	var shell, flag string
	if runtime.GOOS == "windows" {
		shell, flag = "cmd", "/C"
	} else {
		shell, flag = "/bin/sh", "-c"
	}

	cmd := exec.Command(shell, flag, command)
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	if err := cmd.Start(); err != nil {
		return err
	}

	done := make(chan error, 1)
	go func() {
		done <- cmd.Wait()
	}()

	select {
	case <-time.After(timeout):
		if cmd.Process != nil {
			if err := cmd.Process.Kill(); err != nil {
				return fmt.Errorf("failed to kill %q in %s: %s", command, timeout, err)
			}
		}
		<-done // Allow the goroutine to finish
		return fmt.Errorf(
			"command %q\n"+
				"did not return for %s - if your command does not return, please\n"+
				"make sure to background it",
			command, timeout)
	case err := <-done:
		return err
	}
}

总结

这个程序目前已经有一年之久，现在回顾头来看，幸好还记得当初的决策原因。通过这个程序，对模版的使用倒是掌握了很多。目前这个*功能还较为简单，仅仅实现了一个service方法，但是dependency包是独立抽象的，可以支持任意的存储类型，比如Consul。目前线上运行稳定。

这个工具在Nginx配置管理中，较为方便，当然在一些流量较大的场景中，如果后端服务实例较多，扩缩容时会带来较大的波动，这点可以参考微博团队的Upsync：微博开源基于Nginx容器动态流量管理方案

但是我们没有采用这个方案，考虑到的是基于模版的更新机制更为简单，支持更多的服务，普适性更强，整体也更容易维护。