微博广告分布式配置中心的构建与实践（有彩蛋）

邸海峰 2019-06-13 09:39:04

本文根据dbaplus社群第 187 期线上分享整理而成，文末还有好书送哦~

讲师介绍

邸海峰

新浪微博

广告业务部高级运维工程师

主要负责微博广告业务部自动化运维平台设计与开发、微服务体系建设、资源成本优化等工作；
针对微博业务性质，春晚、明星热点事件导致流量突增情况，具有多年高并发、高可用运维经验；
在服务部署自动化运维平台方面有比较丰富的实践和积累。

随着程序的功能日益复杂，程序的配置日益增多，人们对程序配置的期望值也越来越高。在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求。

本期分享「微博广告配置中心的构建与实践」，让大家对企业配置中心建设及服务之间解耦有所借鉴。

大纲如下：

配置中心是什么？
配置中心能干什么？
我们是怎么实现的配置中心？

一、配置中心是什么

在谈配置中心之前，我们先看看什么是配置。配置这个概念大家肯定都不陌生，配置是程序在运行时的动态调整能力，无需重启服务，也无需重新编译。

随着时间推移，配置也慢慢进行演进，从开始的单机版配置需要修改配置重启应用，到多机器批量修改逐个重启。2010 年以后，业界出现了微服务，分布式的配置也逐渐被人熟知。

那什么是配置中心呢？

业界的叫法分好多种：统一配置管理、KV 存储、服务注册、配置发布。有人认为配置中心就是个服务中间件，我认为应该是这几个角色整合起来构成了配置中心。

配置中心应该具有集中统一配置管理的功能，也要具灰度、全量更新与回滚；KV 存储体现在配置文件的参数上。

业界说应用配置中心和服务注册中心不一样，我认为可以将服务注册中心集成到配置中心中，并没有那么多边界。

二、配置中心能干什么

配置中心可以在服务开发阶段，提供 OpenAPI，为其他基础设施的配置外置化，中心化提供支持。

在服务构建阶段，配合构建流水线，为服务软件包或镜像提供配置。在服务运维阶段，动态调整服务配置，满足运维的灵活性需求。

配置中心构建原则

我们在构建配置中心时参考了微服务配置原则。Heroku 创始人 AdamWiggins 发布的「十二要素应用宣言」中提出了关于配置管理的相关方法论。

配置相关的主要有以下四点：

配置是可分离的，可从微服务中抽离出来，任何的配置修改不需要动一行代码；
配置应该是中央的，通过统一的中央配置平台区配置管理不同的微服务；
配置中心必须可靠且稳定地提供配置服务；
配置是可追溯的，任何的配置历史都可追溯，被管理且可用。

三、我们是怎么实现的配置中心

配置中心现在已集成到了我们开发的自动化运维平台中，主要向外提供配置发布、服务注册、服务树管理、环境变量管理、操作历史记录等配置相关的功能。

配置中心模块底层通过 Consul 集群实现，现在有将近 20+ 服务单元、500+ 服务器通过 Consul 来进行服务发现。

下面通过几个案例来介绍一下 Kunkka 平台配置中心这块内容。

1、服务注册

案例一，通过HTTP接口注册。

curl -XPUT -H "X-Consul-Token: xxx-xxx-xx-xxxx-xx" --data @redis.json http://localhost:8500/v1/agent/service/register

// redis.json

{ "id": "redis",

"name": "redis", //服务名称

"tags": ["primary"], //标签，可多个，用于分类和搜索

"address": "10.13.x.x", //服务所在的主机IP

"meta": { //可以定义服务元数据

"meta": "for my service",

"weight": "50"

"port": 8000, //服务暴露端口

"client_addr": "0.0.0.0", // 为了可以在其他机器上注册服务

"enable_tag_override": false,

"checks": [

//检测类型，如HTTP": "检测脚本，如HTTP会响应200的地址", "Interval": "检测周期，如10s 1m等

{

"args": ["/usr/local/bin/check_redis.py"],

"interval": "10s"

}

]

}

上面是一个 Redis 服务注册到 Consul 集群的案例。

Tags 标签来用于在 Consul 集群中能够分类和搜索出相同属性的服务；为了满足一些特殊需求在服务注册时，会通过 Service Meta 这个属性来收集更多的服务元信息；最后每个服务提供自己健康监测的脚本。

案例二，Docker服务器注册。

docker run -d --name=registrator \

-v /var/run/docker.sock:/tmp/docker.sock \

-e CONSUL_HTTP_TOKEN="xxxx-xxxx-xxxx-xxxx" \

--net=host gliderlabs/registrator \

-tags=" `hostname`" \

--deregister=always \

-ip="10.xx.xx.xx " consul://10.xx.xx.xx:8500

Docker 容器中运行的服务统一通过 Registrator 注册到 Consul集群中。

Registrator 是一个能自动发现 docker container 提供的服务，并在后端服务注册中心或者取消服务注册的工具。后端注册中心支持 Consul、Etcd、Skydns2、Zookeeper 等存储。

Registrator 认为任何监听在某个端口的程序都是一个服务，如果这个程序监听了多个端口，则这个程序是多个服务。

2、配置发布

1）均衡负载

针对配置管理起初我们参考了业界比较火的几种方案：

因为业务性质，最终选择了 Consul-template 的方案，统一通过 Kunkka 运维平台进行配置调整，动态生成配置文件，逐台生效，有问题可直接回滚操作。

2）其他配置文件

除了负载均衡外，再工作中还有很多服务与服务之间的配置。我们通过 Consul+Consul-Template+Saltstack 进行配置调整。在Consul 集群 K/V 存储中我们定义了两个目录分别为 app、env 将服务与环境变量关联起来。关联完成后，将包含服务信息的环境变量通过调用 Saltstack API 下发到服务器上。

3、权限控制

在我们刚开始使用 Consul 集群的时候 ACL 功能是没有开启的。在交付给业务方使用的时候，前期没有约定好使用规范，导致各业务方注册服务命名五花八门，每个服务都可以注册到集群中，集群维护起来非常困难。

随着 Consul 1.4 发布，我们将集群进行了升级，制定了服务命名规范”产品名称-服务名称”，服务注册前需在平台上申请Token。Token 生成的策略为根据服务命名在 ACL Policies 生成服务权限(读、写)，然后将服务和权限关联起来生成 Token。

案例：索引服务

# 在Consul集群中默认所有服务可读，注册需要绑定服务名称

Service “aladdin-index”{

Policy = “write”

}

# Create Tokens

在Apply an existing policy选项中关联权限

4、集群监控