用 consul + consul-template + registrator + nginx 打造真正可动态扩展的服务架构

在互联网应用领域，服务的动态性需求十分常见，这就对服务的自动发现和可动态扩展提出了很高的要求。

Docker 的出现，以及微服务架构的兴起，让众多开源项目开始关注在松耦合的架构前提下，如何基于 Docker 实现一套真正可动态扩展的服务架构。

基本需求

基本的需求包括：

• 服务启动后要能自动被发现（vs 传统需要手动进行注册）；
• 负载要能动态在可用的服务实例上进行均衡（vs 传统需要静态写入配置）；
• 服务规模要方便进行快速调整（vs 传统需要较长时间的手动调整）。

相关项目

服务发现

服务发现的项目已经有不少，包括之前介绍的 consul，以及 skydns、serf、以及主要关注一致性的强大的 zookeeper 等。

这些项目各有优缺点，功能上大同小异，都是要通过某种机制来获取服务信息，然后通过维护一套（分布式）数据库来存储服务的信息。这也是为什么 etcd 受到大家关注和集成。

在这里，选用 HashiCorp 公司的 consul 作为服务发现的管理端，它的简介可以参考 这里。

服务注册

服务注册的手段有很多，当然，从发起方是谁可以分为两大类，主动注册还是被动探测。

主动注册，顾名思义，服务启动后，向指定的服务发现管理端的 API 发送请求，给出自身的相关信息。这样做，对管理端的要求简单了很多，但意味着服务自身要完成注册工作，并且极端情况下，管理端比较难探测出真正存活的服务。

被动探测，则是服务发现管理端通过某种机制来探测存活的服务。这样可以获取真实的服务情况，但如何探测是个很难设计的点，特别当服务类型比较复杂的时候。

以上两种，都对网络连通性要求较高。从短期看，主动注册方式会比较容易实现一些，应用情形更广泛；但长期维护上，被动探测方式应该是更高效的设计。

这里，我们选用 gliderlabs 的 registrator，它可以通过跟本地的 docker 引擎通信，来获取本地启动的容器信息，并且注册到指定的服务发现管理端。

配置更新

服务被调整后，负载均衡器要想动态重新分配负载，就需要通过配置来获取更新。这样的方案也有不少，基本上都是要安装一些本地 agent 来监听服务发现管理端的信息，生成新的配置，并执行更新命令。

HashiCorp 公司 的consul-template，可以通过监听 consul 的注册信息，来完成本地应用的