用Go造轮子-管理集群中的配置文件
写在前面
最近一年来，我都在做公司的RTB广告系统，包括SSP曝光服务，ADX服务和DSP系统。因为是第一次在公司用Go语言实现这么一个大的系统，中间因为各种原因造了很多轮子。现在稍微有点时间，觉着有必要总结这一年来用Go造轮子的经验和不足。
集群中遇到的配置文件管理问题
RTB广告系统中涉及到的服务程序并不算很多，但是因为RTB系统会面临很多的流量，而且为了确保可用性，最基本的就是多实例组成集群，同时考虑到后续业务增长，集群的扩缩容也是要做的。我们在设计的时候，基于ZoooKeeper做了服务发现，而我们的服务接入依靠Nginx集群，然后通过反向代理把请求负载均衡到不同的服务实例中。这里就存在以下问题：
- 当我们升级某个服务时，如何通知Nginx集群自动的摘除或者添加该服务实例，保证我们的升级不会影响到业务和用户体验
- 进一步，任意一个服务集群内的配置数据该如何自动更新和应用?
业界方案
业界其实有很多成熟的方案解决这类问题：
- 比如开源项目consul-template，但是这个工具只支持后端consul，而我们用的是ZooKeeper
- 再比如confd，可以支持多种后端，比如etcd或者zookeeper，但是它用的ZooKeeper客户端不支持在故障时对业务请求进行重试，比如发起了一个GetW请求，而Session变成超时状态，这个时候GetW返回的Channel就不可用了，只能重新发起请求，但是重试多少次请求其实是不知道的，针对这个情况，我还在项目一开始的时候实现了新的包，加入了对业务层透明的重试机制。
整体工作流程
- 解析模版，获取要动态查询的节点
- 向指定的服务器，比如ZooKeeper发起查询请求，并观察指定节点的变化
- 当第一次或者节点发生变更后，查询最新数据
- 把最新数据应用到模版中生成新的配置文件数据
- 保存最新的配置文件数据到目标路径，并调用指定的命令应用最新的配置文件
实现
模版机制
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中查询相应的节点的所有子节点的数据，然后返回相应的数据。
- 当我们程序第一次运行时，实际上我们还没准备好指定服务的数据，但是我们至少在这一次知道了它要查询哪个服务的数据，并且我们这时可以启动goroutine去后台轮询查询数据，并把这些数据放入到缓存中
- 那么当我们之后再渲染时，就可以直接缓存中查询指定服务的所有实例（也就是子节点）的数据，然后就可以渲染出最终想要的配置文件数据。之后就可以保存了。
整个代码实现中略微复杂，其中的核心既不是如何缓存，也不是后台如何查询，而是要记录下未知的服务名，以及假如已经知道了服务名并且缓存了数据，如何从缓存中查询数据，这个过程还是拿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容器动态流量管理方案
但是我们没有采用这个方案，考虑到的是基于模版的更新机制更为简单，支持更多的服务，普适性更强，整体也更容易维护。
