目录

Consul构成

Docker Consul 概述

Raft算法

服务注册与发现

健康检查

Key/Value存储

多数据中心

部署模式

consul-template守护进程

registrator容器

consul服务部署（192.168.41.31）

环境准备

搭建Consul服务

查看集群信息

registrator服务部署（192.168.41.32）

安装 Gliderlabs/Registrator：

测试服务发现功能是否正常

验证 http 和 nginx 服务是否注册到 consul

consul-template服务部署（192.168.41.31）

准备 template nginx 模板文件

编译安装配置nginx

配置并启动 template

访问 template-nginx

增加一个 nginx 容器节点测试

构建Consul架构多节点

搭建示例

---

之前的架构

 优化后

Consul构成

        Consul由多个关键组件组成，这些组件共同协作以实现分布式系统中的服务发现、健康检查、配置管理等功能。以下是Consul的主要组成部分：

• Agent（代理）： Agent是Consul集群中每个节点上运行的守护进程。它有两种模式：

• Server（服务器）： 负责维护集群状态、参与领导者选举、响应RPC查询等。一个数据中心通常有多个Server，通过Raft协议保持一致性。

• Client（客户端）： 转发所有RPC请求到Server，并可运行在应用程序的同一主机上，用于将服务发现请求转发给Server。

• Server集群： 由多个Server组成，通过Raft选举协议来维护领导者，负责处理集群状态和事务。

• DataCenter（数据中心）： 逻辑上划分的数据中心单元，Consul集群可以在不同的数据中心之间进行通信。

• Members（成员）： Consul集群中的各个节点或实例，通过Gossip协议进行通信和状态同步。

• Gossip协议： 基于Serf实现的Gossip协议用于节点之间的通信。包括LAN Gossip用于同一数据中心内的通信，以及WAN Gossip用于跨数据中心的通信。

• Catalog（目录）： 用于存储和管理服务和节点信息的目录服务。包括服务发现、健康检查和节点元数据等信息。

• Service Discovery（服务发现）： 通过DNS或HTTP接口提供服务注册和服务发现功能，使得应用程序能够发现并与其他服务通信。

• Health Checking（健康检查）： 定期检查服务的健康状态，如果服务不健康，则通知集群中的其他成员。

这些组件共同构成了Consul的体系结构，使其成为一个高度可用、分布式、横向可扩展的系统，适用于构建可靠的服务基础设施。

---

Docker Consul 概述

• Consul是由Google开源的服务管理软件，使用Go语言进行开发。它提供了多数据中心、分布式高可用、服务发现和配置共享的功能。采用Raft算法确保服务的高可用性，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value存储和多数据中心方案，不再依赖其他工具（例如ZooKeeper等）。Consul的部署简单，只需一个可运行的二进制包。

• 安装consul是用于服务注册，也就是容器本身的一些信息注册到consul里面，其他程序可以通过consul获取注册的相关服务信息，这就是服务注册与发现。

主要特点和运行模式如下：

• Raft算法： 用于保证服务的高可用性，实现分布式一致性。

• 服务注册与发现框架： 内置的机制允许服务在Consul中注册和被发现，实现动态的服务管理。consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。

• 健康检查： Consul支持对服务进行健康检查，确保只有健康的服务被提供给客户端。健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。

• Key/Value存储： 提供了简单的键值存储，适用于配置共享等场景。一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。

• 多数据中心： 支持跨多个数据中心的服务注册、发现和协作。无需复杂的配置，即可支持任意数量的区域。

• 部署模式： 每个节点都运行Consul agent，有两种运行模式：server和client。

• 在client模式下，节点不持久化注册的服务信息，而是将其转发到server节点。

• 在server模式下，节点负责持久化注册信息，并负责同步信息给其他server节点，同时执行健康监测。

        Consul的架构建议每个数据中心运行3或5个server节点以确保数据安全，并保证leader的选举能够正确进行。leader负责同步注册信息和执行节点健康监测。整体上，Consul提供了强大的服务治理和管理功能，使得构建分布式系统变得更加容易和可靠。

Raft算法

        Raft算法是一种分布式一致性算法，用于确保分布式系统中的多个节点能够就共享状态达成一致。Raft的设计目标是提供一种相对容易理解的分布式共识算法，以取代更复杂的Paxos算法。

领导者选举：

• Raft中的节点分为三种状态：领导者（Leader）、跟随者（Follower）和候选人（Candidate）。

• 集群启动时，所有节点都是跟随者。一个跟随者可以成为候选人，然后通过领导者选举机制竞争成为领导者。

• 在选举过程中，每个节点都有一个随机的选举超时时间，首先超时的节点成为候选人，并开始领导者选举。

领导者职责：

• 一旦节点成为领导者，它负责在集群中产生并复制日志条目，以确保所有节点的日志保持一致。

• 领导者定期向跟随者发送心跳，以维持其领导地位。

日志复制：

• 日志是Raft中用于达成一致性的关键组件。领导者负责向所有跟随者复制日志。

• 当客户端请求写入时，领导者将该请求附加到其日志中，并通过心跳将日志条目复制到所有跟随者的日志中。

一致性保证：

• Raft保证当大多数节点正常运行时，系统能够达成一致的状态。大多数节点包括领导者本身。

• 如果有部分节点不可用或发生网络分区，系统将等待大多数节点重新恢复后继续操作。

持久性：

• 节点的状态（包括日志、当前任期等）需要持久化到磁盘，以便在重启后能够恢复。

        Raft算法通过上述机制确保了分布式系统中的一致性和可用性，同时提供了相对较简单的理解和实现方式。这使得Raft在构建分布式系统时更易于应用和维护，相较于其他复杂的共识算法具有更高的可读性。

服务注册与发现

        服务注册与发现在微服务架构中扮演着至关重要的角色，特别是在从单节点服务过渡到多节点分布式架构的情境下。初始阶段，服务通常是单节点的，缺乏高可用性和对服务压力的有效处理，服务间调用主要通过简单的接口访问实现。随着多节点分布式架构的出现，最初的解决方法是在服务前端引入负载均衡，但这种方式存在一些问题：

• 繁琐的配置： 需要在配置文件中配置所有后端服务的网络位置，导致配置复杂繁琐。

• 网络位置的变化： 如果后端服务的网络位置发生变化，所有调用者都需要手动修改配置，不利于维护和扩展。

        为了解决这些问题，引入了服务注册与发现机制。其基本思想是后端服务（A-N）将自己的网络位置注册到服务发现模块，而服务发现模块以键值对的方式记录这些信息，其中键通常是服务名，值是对应的IP地址和端口。服务发现模块会定期进行健康检查，确保这些后端服务可用。前端在调用后端服务时，向服务发现模块查询它们的网络位置，然后再发起对它们的服务调用。

这种方式带来了以下好处：

• 简化配置： 前端不再需要手动配置所有后端服务的网络位置，极大地简化了配置管理。

• 动态适应： 服务发现模块可以动态监测后端服务的健康状态，使得系统能够在运行时适应服务的变化。

• 解耦前后端： 前端与后端服务完全解耦，前端只需与服务发现模块通信，而不需要关心后端服务的具体网络位置。

健康检查

        Consul是一个开源的服务发现和配置工具，它提供了健康检查的功能，以确保只有健康的服务被提供给客户端。

健康检查类型：

• Consul支持多种类型的健康检查，包括HTTP、TCP、Interval、Script等。这意味着你可以选择适合你服务类型的不同健康检查方式。

HTTP健康检查：

• 通过发送HTTP请求到服务的指定端点，Consul可以定期检查服务是否响应正常。如果服务响应正常，就被标记为健康状态，否则标记为不健康状态。

TCP健康检查：

• Consul还支持通过TCP连接检查服务的健康状态。它会尝试建立TCP连接并检查是否成功，从而确定服务是否健康。

Interval健康检查：

• Consul可以通过指定的时间间隔来定期检查服务的健康状态。如果在指定的时间内没有收到服务的响应，就会被标记为不健康。

Script健康检查：

• 对于一些特殊需求，Consul还支持通过执行自定义脚本来进行健康检查。这使得你可以根据具体情况定义健康检查的逻辑。

健康状态更新：

• 当服务的健康状态发生变化时，Consul会及时更新服务注册表，确保客户端只能访问到健康的服务实例。

        通过这些健康检查机制，Consul能够实现对服务状态的实时监测和管理。这对于构建健壮的分布式系统以及提供高可用性的服务非常关键。

Key/Value存储

        Key/Value存储是一种简单而有效的数据存储方式，Consul提供了这样的功能，适用于配置共享等场景。

简单键值对：

• Consul的Key/Value存储是基于简单的键值对的概念。每个键都是一个字符串，与之相关联的是一个任意的数值或字符串值。

配置共享：

• Key/Value存储通常用于配置共享，服务可以将其配置信息存储在Consul的Key/Value存储中，而其他服务可以从中读取配置信息。这样的设计使得配置的管理变得简单且集中化。

动态配置更新：

• 由于Consul支持健康检查和服务注册，当服务的配置发生变化时，可以通过更新Consul中的Key/Value存储来实现动态配置的更新。这有助于系统在运行时适应配置的变化。

ACL控制：

• Consul提供了ACL（Access Control List）机制，可以对Key/Value存储进行访问控制。这意味着你可以定义哪些服务或用户有权访问和修改特定的配置。

版本控制：

• Consul的Key/Value存储支持版本控制，使得可以跟踪配置的历史变化。这在排查问题、回滚配置等方面非常有用。

HTTP API：

• Consul提供了HTTP API，允许通过API对Key/Value存储进行操作。这使得可以通过编程方式管理和更新配置信息。

        总体而言，Consul的Key/Value存储为分布式系统提供了一种简单而强大的配置管理方式，适用于多种场景，特别是在微服务架构中，服务间的配置共享和动态更新变得非常方便。

多数据中心

        Consul支持多数据中心的服务注册、发现和协作，这使得它在构建分布式系统时更具弹性和可扩展性。

服务注册与发现：

• Consul允许在不同数据中心的服务进行注册和发现。这意味着你可以在多个地理位置的数据中心中部署服务，并使它们能够互相发现和调用。

协作和一致性：

• Consul使用Raft算法来确保多数据中心之间的一致性。这使得在不同数据中心的服务能够保持一致的视图，从而协同工作而不受分布式环境的影响。

WAN感知：

• Consul是WAN（Wide Area Network）感知的，可以识别和处理位于不同地理位置的数据中心之间的网络延迟和可用性差异。这有助于提供更可靠的服务注册和发现功能。

多数据中心集群：

• Consul支持构建多数据中心的集群，每个数据中心都有自己的Consul集群。这些集群之间可以通过配置连接起来，实现跨数据中心的服务通信。

健康检查和故障转移：

• Consul的健康检查机制跨越多数据中心，确保服务在整个系统中保持健康状态。如果在一个数据中心中的服务发生故障，Consul可以协调故障转移以确保系统的可用性。

配置同步：

• Consul还支持跨数据中心的配置同步，使得在一个数据中心中进行的配置更改能够自动传播到其他数据中心。

        通过这些特性，Consul提供了一个强大的基础设施，支持构建分布式系统的多数据中心部署，同时确保服务之间的高度一致性和可靠性。这对于全球化的应用和服务非常重要。

部署模式

        每个节点都运行Consul agent，它是Consul的核心组件，负责实现服务注册、发现、健康检查等功能。有两种运行模式：server和client。

• 在client模式下，节点不持久化注册的服务信息，而是将其转发到server节点。

• 在server模式下，节点负责持久化注册信息，并负责同步信息给其他server节点，同时执行健康监测。

        Consul的架构建议每个数据中心运行3或5个server节点以确保数据安全，并保证leader的选举能够正确进行。leader负责同步注册信息和执行节点健康监测。整体上，Consul提供了强大的服务治理和管理功能，使得构建分布式系统变得更加容易和可靠。

---

consul-template守护进程

consul-template 是与 Consul 集成的一个工具，用于渲染模板并自动更新配置文件。它通常与服务发现和配置管理一起使用，以确保服务实例的配置始终保持最新和一致。

守护进程：

• Consul-Template 作为一个守护进程运行，实时查询 Consul 集群的信息。

查询功能：

• Consul-Template 可以查询 Consul 中的服务目录、Key、Key-values 等。这为动态配置文件的创建提供了强大的抽象功能。

模板语言：

• 支持灵活的模板语言，允许用户使用查询结果动态地填充配置文件的内容。这对于创建诸如 Apache/Nginx Proxy Balancers、Haproxy Backends 等动态配置非常有用。

自动更新：

• 一旦模板渲染完成，consul-template 可以监视 Consul 中的变化，并在检测到更改时自动重新渲染模板。这使得配置的更新可以实时反映到运行中的服务中。

触发命令执行：

• 更新完成后，Consul-Template 可以选择执行 shell 命令，这样可以在配置更新后触发一些操作，比如重新加载 Nginx。

事件通知：

• consul-template 提供了事件通知机制，可以在配置更改时执行自定义的命令或脚本。这允许用户根据需要执行一些额外的操作，例如重新加载服务或执行其他配置变更操作。

简化配置管理：

• 通过将配置信息从 Consul 中抽象出来，consul-template 简化了配置的管理和分发，特别适用于微服务架构中的服务实例。

命令行工具和集成性：

• consul-template 作为一个命令行工具，易于集成到不同的部署和自动化流程中，确保配置的动态性和一致性。

适用场景：

• Consul-Template 特别适合在动态环境中使用，其中服务的数量和配置信息可能会经常发生变化。它简化了配置的管理，确保配置文件与实际服务状态同步。

适用案例：

• 常见的使用案例包括创建反向代理配置、负载均衡器配置等，其中服务实例的动态变化需要实时地更新配置文件。

---

registrator容器

        Registrator 是一个用于自动注册和注销服务实例的工具，它通常与容器编排系统（如 Docker）一起使用。其主要功能是监控运行中的容器，并将它们注册到服务发现系统中，以便其他服务可以发现和与之通信。

以下是 Registrator 的一些关键特点和功能：

• 自动服务注册： Registrator 监控正在运行的容器，并自动将它们注册到服务发现系统中。这有助于确保所有运行的服务都被正确地加入到服务注册表中。

• 支持多种服务发现后端： Registrator 支持多种服务发现后端，其中包括 Consul、etcd、SkyDNS 等。这使得它能够适应不同的环境和需求。

• 容器事件监听： Registrator 通过监听容器的事件，例如容器的启动和停止，来感知容器的状态变化。一旦有新的容器启动或旧的容器停止，Registrator 就会相应地更新服务发现系统中的信息。

• 与 Consul 搭配使用： Registrator 与 Consul 搭配使用。这意味着 Registrator 可以将容器注册到 Consul 中，而Consul-Template则可以用来动态生成配置文件，实现服务配置的自动更新。

• 简化服务发现流程： Registrator 的存在简化了服务发现的流程，使得新的服务实例能够自动加入到服务注册表中，而无需手动干预。

consul服务部署（192.168.41.31）

环境准备

consul服务器	192.168.41.31	运行consul服务、nginx服务、consul-template守护进程
registrator服务器	192.168.41.32	运行registrator容器、运行nginx容器

这个架构的运行方式：

Consul服务器 (192.168.41.31)：

• Consul服务运行： Consul作为服务发现和配置管理的中心。其他服务可以注册到Consul，并通过其发现其他服务的实例和配置信息。

• Nginx服务运行： Nginx用于处理网络流量，是作为反向代理服务器、负载均衡器等。

• Consul-template守护进程： 运行Consul-template守护进程，该进程监视Consul中配置的更改，并相应地更新模板文件。这样可以实现动态配置。

Registrator服务器 (192.168.41.32)：

• Registrator容器运行： Registrator以容器方式运行，用于自动注册和注销其他服务实例到Consul。当新的服务容器启动或关闭时，Registrator会更新Consul中的服务注册信息。

• Nginx容器运行： Nginx以容器方式运行，这样可以更轻松地管理和部署。

        一般来说，这种架构的运行方式是基于微服务和容器化的理念，通过Consul实现服务的发现和配置管理，Nginx处理网络流量，并通过Registrator自动注册和注销服务实例。这种架构具有灵活性和可伸缩性，容器化的部署方式使得服务的管理和扩展更加方便。

systemctl stop firewalld.service
setenforce 0

搭建Consul服务

创建Consul服务目录：

mkdir /opt/consul

将Consul二进制文件复制到创建的目录：

cp consul_0.9.2_linux_amd64.zip /opt/consul

进入Consul目录：

cd /opt/consul

解压Consul二进制文件：

unzip consul_0.9.2_linux_amd64.zip

将解压后的Consul二进制文件移动到/usr/local/bin/目录，以便系统能够识别并执行：

mv consul /usr/local/bin/

设置Consul代理，并在后台启动Consul服务端。

consul agent \
-server \
-bootstrap \
-ui \
-data-dir=/var/lib/consul-data \
-bind=192.168.41.31 \
-client=0.0.0.0 \
-node=consul-server01 &> /var/log/consul.log &

•         -server: 以server身份启动。默认是client。

  • -bootstrap: 表示该服务器将充当引导服务器。

  • -ui: 启用Consul的Web用户界面。

  • -data-dir=/var/lib/consul-data: 指定Consul存储数据的目录。

  • -bind=192.168.41.31: 指定Consul绑定的IP地址。

  • -client=0.0.0.0: 允许从任何IP连接到Consul客户端。

  • -node=consul-server01: 指定Consul节点的名称。

  • &> /var/log/consul.log &: 将Consul的日志输出到/var/log/consul.log文件，并在后台运行。

补充详解

• -server: 以server身份启动。默认情况下，Consul以client身份启动。

• -bootstrap: 控制server是否在bootstrap模式。在一个数据中心中，只能有一个server处于bootstrap模式。处于bootstrap模式的server可以自己选举为server-leader。

• -bootstrap-expect=2: 设置集群要求的最少server数量。当集群中的server数量低于这个值时，整个集群将失效。

• -ui: 启用Consul的Web用户界面。通过此参数启动后，可以通过 http://localhost:8500/ui 访问Consul自带的Web UI界面。

• -data-dir: 指定数据存储目录，即Consul用来存储数据的路径。

• -bind: 指定在集群内部的通讯地址。集群中的所有节点到此地址都必须是可达的。默认为0.0.0.0。

• -client: 指定Consul绑定在哪个client地址上，提供HTTP、DNS、RPC等服务。默认为127.0.0.1。

• -node: 指定节点在集群中的名称。在一个集群中，节点名称必须是唯一的。默认为节点的主机名。

• -datacenter: 指定数据中心的名称。默认为dc1。

查看服务

netstat -natp | grep consul

Consul 是一种开源的服务发现和配置工具，用于构建分布式系统。当启动 Consul 后，默认会监听以下五个端口：

• 8300端口：

  • 用于服务间的复制（replication）。

  • 用于 Leader 的 forward。

• 8301端口：

  • 用于局域网（LAN）中节点之间的 Gossip 协议通信。

  • 主要用于集群中的节点之间的发现和信息传播。

• 8302端口：

  • 用于广域网（WAN）中节点之间的 Gossip 协议通信。

  • 与8301端口类似，但主要用于跨越较大区域的节点之间的通信。

• 8500端口：

  • 提供 Consul 的 Web UI 界面。

  • 通过该端口可以访问可视化的用户界面，以便查看和管理 Consul 中的服务和节点。

• 8600端口：

  • 用于使用 DNS 协议查看节点信息。

  • 允许通过 DNS 查询的方式获取节点和服务的信息，方便在应用中通过域名进行服务发现。

这些端口的默认配置支持 Consul 在分布式环境中进行节点发现、服务注册和配置管理等任务。

查看集群信息

查看成员(Members)状态:

consul members

        这个命令显示了Consul集群中的成员状态。

查看集群状态:

consul operator raft list-peers

        这个命令显示了Consul Raft协议的集群状态，列出了所有的Raft节点。

consul info | grep leader

        这个命令通过Consul的信息检索了领导者（leader）节点的地址，

通过HTTP API获取集群信息: 通过Consul的HTTP API获取集群信息的命令。这些命令可以通过curl进行调用：

• 查看集群server成员:

curl 127.0.0.1:8500/v1/status/peers

• 查看集群server-leader:

curl 127.0.0.1:8500/v1/status/leader

• 注册的所有服务:

curl 127.0.0.1:8500/v1/catalog/services

• 查看nginx服务信息:

curl 127.0.0.1:8500/v1/catalog/nginx

• 查看集群节点详细信息:

curl 127.0.0.1:8500/v1/catalog/nodes

        这些API调用允许通过HTTP请求获取Consul集群的各种信息，如成员列表、服务信息等。确保Consul代理在本地运行，并且API端口为8500。

registrator服务部署（192.168.41.32）

功能说明： 负责容器服务的自动注册到 Nginx 集群，并支持服务的注销到服务配置中心。

安装 Gliderlabs/Registrator：

使用 Docker 运行 Gliderlabs/Registrator 容器，并将其配置为使用 Consul 作为服务配置中心。

docker run -d \
  --name=registrator \
  --net=host \
  -v /var/run/docker.sock:/tmp/docker.sock \
  --restart=always \
  gliderlabs/registrator:latest \
  --ip=192.168.41.32 \
  consul://192.168.41.31:8500

解释说明：

• -d: 指定容器在后台运行（detached mode）。

• --name=registrator: 为容器指定名称为 "registrator"。

• --net=host: 使用主机网络模式，允许容器访问主机网络。

• -v /var/run/docker.sock:/tmp/docker.sock: 将 Docker 守护进程的 socket 映射到容器内，以便 Registrator 可以监测容器的运行状态。

• --restart=always: 指定容器在退出时总是重新启动。

• gliderlabs/registrator:latest: 使用 Gliderlabs/Registrator 镜像的最新版本。

• --ip=192.168.41.32: 设置 Registrator 的 IP 地址为 192.168.41.32。这是 Registrator 用于注册服务的地址。

• consul://192.168.41.31:8500: 指定 Consul 的连接地址为 consul://192.168.41.31:8500，这是作为服务配置中心。

        这段命令将启动 Registrator 容器，并配置其自动注册和注销服务到 Consul 中。确保 Consul 服务运行在 192.168.41.31 的地址上，并监听端口 8500。

docker run \
  --net=host \ # 将容器设定为host网络模式
  -v /var/run/docker.sock:/tmp/docker.sock \ # 挂载宿主机的Docker守护进程Unix域套接字到容器中
  --restart=always \ # 在容器退出时总是重启容器
  --ip <宿主机的IP> \ # 指定容器的IP为宿主机的IP
  consul \ # 指定容器使用Consul服务器，并可能包括IP和端口的指定

测试服务发现功能是否正常

docker run -itd -p 83:80 --name test-01 -h test01 nginx
docker run -itd -p 84:80 --name test-02 -h test02 nginx
docker run -itd -p 88:80 --name test-03 -h test03 httpd
docker run -itd -p 89:80 --name test-04 -h test04 httpd

        这些命令用于在Docker中运行四个容器（test-01、test-02、test-03、test-04），每个容器都运行不同的Web服务（nginx或httpd），并映射宿主机的端口以便外部访问。容器的主机名也通过-h参数进行了设置。这样可以测试服务发现功能是否正常工作。

验证 http 和 nginx 服务是否注册到 consul

• 打开浏览器，在地址栏中输入 http://192.168.41.31:8500。

• 在Web页面中，点击 "NODES"，然后点击 "consurl-server01"。应该会显示出5个服务。

在consul服务器使用curl测试连接服务器

curl 127.0.0.1:8500/v1/catalog/services

        执行上述命令后，返回的JSON数据应该包含已注册的服务信息，例如：

{"consul":[],"httpd":[],"nginx":[]}

        这表示Consul中已注册的服务有"consul"、"httpd"和"nginx"。通过这些步骤和测试，可以验证HTTP和Nginx服务是否成功注册到Consul。

consul-template服务部署（192.168.41.31）

准备 template nginx 模板文件

准备 Nginx 模板文件： 在 Consul 服务器上操作，创建并编辑 Nginx 模板文件。

vim /opt/consul/nginx.ctmpl

定义 Nginx Upstream： 在模板文件中，定义一个简单的 Nginx Upstream，使用 Consul-Template 查询服务信息并生成 Upstream 配置。

upstream http_backend {
  {{range service "nginx"}}
   server {{.Address}}:{{.Port}};
  {{end}}
}

定义 Nginx Server 配置： 继续在模板文件中定义 Nginx Server 配置，监听8000端口，设置反向代理到上述定义的 Upstream。

server {
    listen 8000;
    server_name localhost 192.168.41.31;
    access_log /var/log/nginx/kgc.com-access.log;  # 修改日志路径
    index index.html index.php;
    location / {
        proxy_set_header HOST $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header Client-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_pass http://http_backend;
    }
}

说明：

• 模板中使用 {{range service "nginx"}} 遍历 Consul 中所有名为 "nginx" 的服务实例，动态生成 Upstream 中的服务器地址和端口。

• Server 配置中的监听端口为 8000，可以根据实际需求进行调整。

• Access log 路径已经设置为 /var/log/nginx/kgc.com-access.log，您可以根据需要修改日志路径。

通过这样的模板文件和 Consul-Template 的使用，您可以实现 Nginx 配置的自动更新，确保新的服务实例能够动态加入反向代理。这在微服务架构中是一种灵活且自动化的方式来管理服务配置。

• listen 8000;: Nginx 会在8000端口上监听请求。

• server_name localhost 192.168.41.31;: 限定了这个 Server 配置的域名，只有请求中的域名匹配其中一个，这个 Server 配置才会生效。

• access_log /var/log/nginx/kgc.com-access.log;: 设置访问日志的路径，记录请求的详细信息。

• index index.html index.php;: 定义默认的索引文件，Nginx 会依次尝试使用这些文件。

• location / { ... }: 配置了处理请求的位置，这里是根路径 /。在这个位置配置了反向代理，将请求转发到定义的 http_backend upstream。

通过这样的模板文件和 Consul-Template 的使用，可以实现 Nginx 配置的自动更新，确保新的服务实例能够动态加入反向代理。这在微服务架构中是一种灵活且自动化的方式来管理服务配置。

编译安装配置nginx

安装必要的依赖：

yum -y install pcre-devel zlib-devel gcc gcc-c++ make

创建nginx用户：

useradd -M -s /sbin/nologin nginx

解压nginx源码文件：

tar zxvf nginx-1.12.0.tar.gz -C /opt/

进入解压后的目录：

cd /opt/nginx-1.12.0/

配置并编译nginx：

./configure --prefix=/usr/local/nginx --user=nginx --group=nginx && make -j && make install

创建符号链接：

ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/

配置nginx主配置文件：

vim /usr/local/nginx/conf/nginx.conf

在配置文件中添加以下内容：

http {
  include mime.types;
  include vhost/*.conf;  # 添加虚拟主机目录
  default_type application/octet-stream;
}

创建虚拟主机目录：

mkdir /usr/local/nginx/conf/vhost

创建日志文件目录：

mkdir /var/log/nginx

启动nginx：

nginx

配置并启动 template

下载并解压Consul Template：

unzip consul-template_0.19.3_linux_amd64.zip -d /opt/

移动Consul Template到系统路径：

cd /opt/
mv consul-template /usr/local/bin/

在前台启动Consul Template服务（请确保不要按下Ctrl+C中止Consul Template进程）：

consul-template --consul-addr 192.168.41.41:8500 \
--template "/opt/consul/nginx.ctmpl:/usr/local/nginx/conf/vhost/kgc.conf:/usr/local/nginx/sbin/nginx -s reload" \
--log-level=info

在另一个终端查看生成的配置文件：

upstream http_backend {
   server 192.168.41.32:83;
   server 192.168.41.32:84;
}

server {
   listen 8000;
   server_name 192.168.41.31;
   access_log /var/log/nginx/kgc.cn-access.log;
   index index.html index.php;

   location / {
      proxy_set_header HOST $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header Client-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass http://http_backend;
   }
}

访问 template-nginx

列出所有Docker容器：

docker ps -a

进入Nginx容器并创建一个测试文件：

docker exec -it 4f74d2c38844 bash
echo "this is test1 web" > /usr/share/nginx/html/index.html

进入另一个Nginx容器并创建另一个测试文件：

docker exec -it b73106db285b bash
echo "this is test2 web" > /usr/share/nginx/html/index.html

通过浏览器访问 http://192.168.41.31:8000/，并不断刷新。

增加一个 nginx 容器节点测试

增加一个 Nginx 容器节点，测试服务发现及配置更新功能。

docker run -itd -p 85:80 --name test-05 -h test05 nginx

该命令使用 Docker 运行一个名为 test-05 的 Nginx 容器，将容器的端口映射到主机的端口 85，并设置容器的主机名为 test05。

观察 template 服务，该服务会从模板更新 /usr/local/nginx/conf/vhost/kgc.conf 文件内容，并重载 Nginx 服务。

查看 /usr/local/nginx/conf/vhost/kgc.conf 文件内容：

cat /usr/local/nginx/conf/vhost/kgc.conf

文件内容展示了一个名为 http_backend 的 upstream 块，包含四个服务器节点的定义，每个节点使用不同的端口（83、84、85、86）。

查看三台 Nginx 容器的日志，以确认请求正常轮询到各个容器节点上：

docker logs -f test-01
docker logs -f test-02
docker logs -f test-05
docker logs -f test-06

这些命令分别查看了 test-01、test-02、test-05 和 test-06 这四个容器的日志，以确认请求是否正常地轮询到它们各自的节点上。

总体而言，这些步骤和命令用于测试在 Nginx 中增加新容器节点后的服务发现和配置更新功能，并确保请求能够正常轮询到新的容器节点。

构建Consul架构多节点

建立多节点的Consul集群有几个重要的原因：

• 高可用性： 多节点集群可以提供更高的系统可用性。当一个节点发生故障或不可用时，其他节点仍然可以继续提供服务。这是通过在集群中引入冗余节点来实现的，确保即使有节点失效，整个系统仍然能够正常运行。

• 负载均衡： 多节点集群能够均衡处理请求，防止某个节点成为瓶颈。通过在多个节点上分布服务实例，可以有效地分担负载，提高系统的整体性能。

• 容错性： 多节点集群提供容错机制，即使某个节点发生故障，系统也能够保持可用。Consul使用Raft一致性算法来确保在节点失效或网络分区的情况下，集群仍能维持一致的状态。

• 服务发现和配置： Consul用于服务发现和配置管理。多节点集群能够更有效地管理和监控分布式系统中的服务，使其更易于扩展和维护。

• 水平扩展： 随着业务需求的增长，可以向集群添加更多的节点，从而实现水平扩展。这使得系统能够处理更多的请求和数据，保持高性能。

总体而言，建立多节点的Consul集群有助于构建稳健、可靠、高性能的分布式系统，适用于各种规模的应用和服务。

搭建示例

Consul 多节点配置

# 添加一台已有docker环境的服务器192.168.41.33/24加入已有的群集中
consul agent \
-server \
-ui \
-data-dir=/var/lib/consul-data \
-bind=192.168.41.33 \
-client=0.0.0.0 \
-node=consul-server02 \
-enable-script-checks=true  \
-datacenter=dc1  \
-join 192.168.41.31 &> /var/log/consul.log &

参数说明:

• -server: 将节点配置为服务器。

• -ui: 启用Consul的Web UI。

• -data-dir=/var/lib/consul-data: 指定Consul数据目录。

• -bind=192.168.41.33: 绑定到指定的IP地址。

• -client=0.0.0.0: 监听所有可用的网络接口。

• -node=consul-server02: 指定节点名称为"consul-server02"。

• -enable-script-checks=true: 设置检查服务为可用。

• -datacenter=dc1: 指定数据中心名称。

• -join 192.168.41.31: 将节点加入到已有的集群中。

其他命令:

# 显示当前Consul集群的成员列表
consul members
Node             Address             Status  Type    Build  Protocol  DC
consul-server01  192.168.41.31:8301  alive   server  0.9.2  2         dc1
consul-server02  192.168.41.33:8301  alive   server  0.9.2  2         dc1

# 显示Raft协议中的节点信息
consul operator raft list-peers
Node             ID                  Address             State     Voter  RaftProtocol
Node             ID                  Address             State     Voter  RaftProtocol
consul-server01  192.168.41.31:8300  192.168.41.31:8300  leader    true   2
consul-server02  192.168.41.33:8300  192.168.41.32:8300  follower  true   2

这些命令帮助建立了一个高可用、负载均衡的Consul集群，用于服务发现和配置管理。