基于nginx和consul构建高可用及自动发现的docker服务架构上

Posted 2021-04-24 点融黑帮

1导读

如果你在大量接触或使用微服务的话，你可能会碰到一个问题：当你创建的服务数量越来越多时，这些服务之间的通信便越难管理，而且维护代价会越来越高。

针对这个问题，Consul给出了一份完美的答卷。

Consul是一套开源的分布式服务发现和配置管理系统，支持多数据中心分布式高可用。Consul是HashiCorp（ Vagrant的创建者）开发的一个服务发现与配置项目，用Go语言开发，基于 Mozilla Public License 2.0 的协议开源。

另外，架构里的另一个重要的角色则是Docker。Docker技术的不断成熟，孵化出了大量优秀的相关技术，比如docker监控，开源技术有cAdvisor、Cloud Insight或telegraf等，自定义开发方式，Docker stats、Python API或伪文件系统；docker管理，forman、kubernetes与CoreOS（都已整合各类组件），各类技术覆盖网络、监控、维护、部署、开发等方面，帮助开发、运维人员快速构建、运营Docker服务环境。

面对如此优秀和快速发展的一个生态圈技术，在企业当中，我们该如何选择并发挥Docker的强大之处？

而现实中，我们一直渴望着追求提供高质量、高可用的服务架构体系，同时减少不必要的部署和维护代价，减少容错率。

面对如此高的要求，我们提供了以下两种架构方案：

1. Docker+Etcd+Confd+nginx

2. Docker+Consul+Nginx
   

2架构设计与架构流程

Docker+Etcd+Confd + Nginx，采用松散式的组织结构，但各个组件之间的通讯是非常严密的，且扩展性更强，定制也更加灵活，这样一个架构体系在实用环境中，确实也体现了各个组件的强大功效。Etcd用于提供分享配置和服务发现，Confd通过查询Etcd，结合配置模板引擎，保持本地配置最新，同时具备定期探测机制，配置变更自动reload；Nginx提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，为此提供一套完美的架构服务体系。

以上的一套架构方案确实也是当前用得比较普遍的方案，而今天我将对比以上方案，给大家提供另外一种更加高效、快捷，并且维护代价和容错率更低，分布式支持力度更强的架构方案Docker+Consul+Nginx(如图)。

（服务架构图）

使用Docker将Consul、Consul Template、Registrator和Nginx组装成一个值得信任且可扩展的服务框架，这套架构让你在这个框架中添加和移除服务，不需要重写任何配置，也不需要重启任何服务，一切都能正常运行，具体工作流程如下图。

（架构流程图）

3架构优势

Docker+Consul+Nginx虽然看起来是三个组件的运用，但却证明是一个有机的整体。它们互相联系、互相作用，完全满足我们对高可用、高效服务架构方案的需求，是Docker生态圈中最理想的组合之一，具有以下优势：

• 自动发现与注册组件consul(内部的架构设计参见图Consul内部的架构设计)使用 Raft 算法来保证一致性，比复杂的Paxos 算法更直接。相比较而言，zookeeper 采用的是 Paxos，而 etcd 使用的则是 Raft；

  
  

• 支持多数据中心(参见图Consul多数据中心分布式集群架构)，多数据中心集群可以避免单数据中心的单点故障，zookeeper 和 etcd 均不提供多数据中心功能的支持；

  
  

• 自动、实时发现及无感知服务刷新，具备资源弹性，伸缩自如（通过生成、销毁容器实现）；

  
  

• 支持健康检查，负载能动态在可用的服务实例上进行均衡，etcd 不提供此功能；

  
  

• 支持足够多台Docker容器(前提架构资源足以保证性能支撑)；

  
  

• 支持http 和dns 协议接口，zookeeper 的集成较为复杂，etcd 只支持 http 协议；

  
  

• 服务规模方便进行快速调整，官方提供web管理界面，etcd 无此功能；

  
  

• Consul template 搭配consul使用，支持多种接入层，如Nginx、Haproxy。

（Consul内部的架构设计）

（Consul多数据中心分布式集群架构）

4模块介绍

服务发现模块：

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

这些项目各有优缺点，功能上大同小异，都是要通过某种机制来获取服务信息，然后通过维护一套（分布式）数据库来存储服务的信息。在这里，选用 HashiCorp 公司的 consul 作为服务发现的管理端。

服务注册模块：

服务注册的手段有很多，从发起方是谁可以分为主动注册和被动探测，它们都对网络连通性要求较高。从短期看，主动注册方式会比较容易实现一些，应用情形更广泛；但长期维护上，被动探测方式应该是更高效的设计。

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

配置更新模块：

服务被调整后，负载均衡器要想动态重新分配负载，就需要通过配置来获取更新。笔者本着追求简单和高效，使用HashiCorp 公司 的 Consul Template，可以通过监听 consul 的注册信息，当添加或者移除服务时，Consul Template可以通过连接Consul更新配置并重启应用。

负载均衡模块：

负载均衡对性能要求很高，其实并不是软件所擅长的领域，但软件方案胜在成本低、维护方便，包括 lvs、haproxy、Nginx 都是很优秀的设计方案。

这里，我们选用 nginx(consul template官方同时提供了nginx和haproxy的配置demo)。nginx 不仅是个强大的 web 代理服务器，同时在负载均衡方面表现也不俗。更关键的，新版本的 nginx 对在线升级支持做到了极致。实时配置更新更是不在话下，可以保证服务的连续性。

未

完

待

续

---

---