consul

在分布式集群部署模式下，为了维护数据一致性，通常需要选举出一个leader来进行协调，并且在leader挂掉后能从集群中选举出一个新的leader。选举leader的方案有很多种，对Paxos和Raft协议有过了解的同学应该对leader选举有一些认识，一般都是按照少数服从多数的原则来实现，但是因为分布式环境中无法避免的网络不稳定、数据不同步、时间偏差等问题，要想搞好leader选举并不是一件特别容易的事。这篇文章将提供一个使用Consul做leader选举的简单方案。 原理 Consul 的leader选举只有两步： 1、Create Session：参与选举的应用分别去创建Session，Session的存活状态关联到健康检查。 2、Acquire KV：多个应用带着创建好的Session去锁定同一个KV，只能有一个应用锁定住，锁定成功的应用就是leader。 如上图所示，这里假设App2用Session锁定住了KV，其实就是KV的Session属性设置为了Session2。 什么时候会触发重新选举呢？ Session失效：Session被删除、Session关联的健康检查失败、Session TTL过期等。 KV被删除：这个没什么需要特别说明的。 那应用们怎么感知这些情况呢？ 应用在选举结束后，应该保持一个到KV的阻塞查询，这个查询会在超时或者KV发生变化的时候返回结果

1 master节点 cat << EOF > /lib/systemd/system/consul.service [Unit] Description=consul-master After=network-online.target [Service] ExecStart=/bin/sh -c 'consul agent -server -bootstrap -ui -data-dir=/data/consul -bind=10.0.2.57 -client=0.0.0.0 -node=10.0.2.57 >> /data/consul/consul.log' StandardOutput=journal StandardError=inherit LimitNOFILE=65536 TimeoutStopSec=0 KillSignal=SIGTERM SendSIGKILL=no SuccessExitStatus=0 Restart=always User=root Group=root WorkingDirectory=/data/consul [Install] WantedBy=multi-user.target EOF 2 node1 cat << EOF > /lib/systemd/system/consul.service [Unit]

consul、eureka、nacos对比 配置中心 eureka 不支持 consul 支持 但用起来偏麻烦，不太符合springBoot框架的命名风格，支持动态刷新 nacos 支持 用起来简单，符合springBoot的命名风格，支持动态刷新 注册中心 eureka 依赖：依赖ZooKeeper 应用内/外：直接集成到应用中，依赖于应用自身完成服务的注册与发现， ACP原则：遵循AP（可用性+分离容忍）原则，有较强的可用性，服务注册快，但牺牲了一定的一致性。 版本迭代：目前已经不进行升级 集成支持：只支持SpringCloud集成 访问协议：HTTP 雪崩保护：支持雪崩保护 界面：英文界面，不符合国人习惯 上手：容易 consul 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：遵循CP原则（一致性+分离容忍） 服务注册稍慢，由于其一致性导致了在Leader挂掉时重新选举期间真个consul不可用。 版本迭代：目前仍然进行版本迭代 集成支持：支持SpringCloud K8S集成 访问协议：HTTP/DNS 雪崩保护：不支持雪崩保护 界面：英文界面，不符合国人习惯 上手：复杂一点 nacos 依赖：不依赖其他组件 应用内/外：属于外部应用，侵入性小 ACP原则：通知遵循CP原则（一致性+分离容忍） 和AP原则（可用性+分离容忍） 版本迭代

一、 什么是consul consul的基本介绍 在分布式架构中，服务治理是一个重要的问题。在没有服务治理的分布式集群中，各个服务之间通过手工或者配置的方式进行服务关系管理，遇到服务关系变化或者增加服务的时候，人肉配置极其麻烦且容易出错。之前在一个C/C++项目中，采用ZooKeeper进行服务治理，可以很好的维护服务之间的关系，但是使用起来较为麻烦。现在越来越多新的项目采用consul进行服务治理，各方面的评价都优于ZooKeeper，经过几天的研究，这里做一个总结。 zookeeper和consul比较 • 开发语言方面，zookeeper采用java开发，安装的时候需要部署java环境；consul采用golang开发，所有依赖都编译到了可执行程序中，即插即用。 • 部署方面，zookeeper一般部署奇数个节点方便做简单多数的选举机制。consul部署的时候分server节点和client节点（通过不同的启动参数区分），server节点做leader选举和数据一致性维护，client节点部署在服务机器上，作为服务程序访问consul的接口。 • 一致性协议方面，zookeeper使用自定义的zab协议，consul的一致性协议采用更流行的Raft。 • zookeeper不支持多数据中心，consul可以跨机房支持多数据中心部署，有效避免了单数据中心故障不能访问的情况。 •

Consul 简化了分布式环境中的服务的注册和发现流程，通过 HTTP 或者 DNS 接口发现。支持外部 SaaS 提供者等。 consul提供的一些关键特性： service discovery：consul通过DNS或者HTTP接口使服务注册和服务发现变的很容易，一些外部服务，例如saas提供的也可以一样注册。 health checking：健康检测使consul可以快速的告警在集群中的操作。和服务发现的集成，可以防止服务转发到故障的服务上面。 key/value storage：一个用来存储动态配置的系统。提供简单的HTTP接口，可以在任何地方操作。 multi-datacenter：无需复杂的配置，即可支持任意数量的区域(数据中心)。 官方网站： https://www.consul.io/ 系统环境：CentOS release 6.5 (Final) x64 consul最新版的下载地址 https://releases.hashicorp.com/consul/0.6.4/consul_0.6.4_linux_amd64.zip 下载解压，里面只有一个consul可执行文件，执行 ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 [root@localhost consul-0.6.4]#

近几年随着Docker容器技术、微服务等架构的兴起，人们开始意识到服务发现的必要性。微服务架构简单来说，是一种以一些微服务来替代开发单个大而全应用的方法, 每一个小服务运行在自己的进程里,并以轻量级的机制来通信, 通常是 HTTP RESTful API。微服务强调小快灵, 任何一个相对独立的功能服务不再是一个模块, 而是一个独立的服务。那么，当我们需要访问这个服务时，如何确定它的地址呢？这时就需要服务发现了。 Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。通常拿来和zookeeper、etcd这些服务注册与发现的工具进行比较。Consul更像一个“全栈”解决方案，内置了服务注册与发现，具有健康检查、Key/Value存储、多数据中心的功能。个人比较偏爱他有三点：1、开箱即用，方便运维：安装包仅包含一个可执行文件，方便部署，无需其他依赖，与Docker等轻量级容器可无缝配合 。2、自带ui界面，可以通过web界面直接看到注册的服务，更新K/V。3、采用GOSSIP协议进行集群内成员的管理和消息的传播，使用和etcd一样的raft协议保证数据的一致性。 Consul提供的四个关键特性： 1、 服务发现。 提供HTTP和DNS两种发现方式。 2、 健康监测。 支持多种方式，HTTP、TCP、Docker、Shell脚本定制化监控。 3、

分配三台虚拟机： 192.168.5.125 192.168.5.128 192.168.5.129 在每台虚拟机上创建 /usr/consul 文件件 命令： mkdir /usr/consul mkdir /usr/consul-ui 常用命令 command ： agent作用：运行一个consul agent Join 作用：将agent加入到consul cluster members作用：列出consul cluster集群中的members 常用选项 option ： -data-dir 作用：指定agent储存状态的数据目录，这是所有agent都必须的，对于server尤其重要，因为他们必须持久化集群的状态 -config-dir作用：指定service的配置文件和检查定义所在的位置，通常会指定为"某一个路径/consul.d"（通常情况下，.d表示一系列配置文件存放的目录） -config-file作用：指定一个要装载的配置文件，该选项可以配置多次，进而配置多个配置文件（后边的会合并前边的，相同的值覆盖） -dev作用：创建一个开发环境下的server节点，该参数配置下，不会有任何持久化操作，即不会有任何数据写入到磁盘，这种模式不能用于生产环境（因为第二条） -bootstrap-expect作用：该命令通知consul

创建自定义网络 sudo docker network create my-consul 获取consul镜像 sudo docker search consul sudo docker pull consul 创建consul服务器 sudo docker run -d --name node1 -h node1 --net my-consul consul agent -server -bootstrap-expect 3 -datacenter dc001 -bootstrap-expect 在一个datacenter中期望提供的server节点数目，当该值提供的时候，consul一直等到达到指定sever数目的时候才会引导整个集群，该标记不能和bootstrap公用（推荐使用的方式） 获取node1的ip地址 JOIN_IP="$(sudo docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' node1)" JOIN_IP 设置节点1的ip，方便后面使用 继续创建其他服务器 sudo docker run -d --name node2 -h node2 --net my-consul consul agent -server -join $JOIN_IP

博文大纲： 一、Bridge模式（同一台Docker服务器上容器间的通信） 二、部署consul服务实现Docker容器跨主机通信 前言： 当你开始大规模使用Docker时，你会发现需要了解很多关于网络的知识。Docker作为目前最火的轻量级容器技术，有很多令人称道的功能，如Docker的镜像管理。然而，Docker同样有着很多不完善的地方，网络方面就是Docker比较薄弱的部分。因此，我们有必要深入了解Docker的网络知识，以满足更高的网络需求。本文首先介绍了Docker自身的4种网络工作方式，然后介绍一些自定义网络模式。 我们安装Docker时，它会自动创建三个网络，bridge（创建容器默认连接到此网络）、 none 、host。 host：容器将不会虚拟出自己的网卡，配置自己的IP等，而是使用宿主机的IP和端口。 None：该模式关闭了容器的网络功能，相当于一个回环网络。 Bridge：此模式会为每一个容器分配、设置IP等，并将容器连接到一个叫docker0的虚拟网桥，通过docker0网桥以及Iptables nat表配置与宿主机通信。 [ root@docker ~ ] # docker network ls #执行该命令查看docker创建的网络 关于上述提到的三个网络解释如下： Host：相当于Vmware中的桥接模式，与宿主机在同一个网络中，但没有独立的IP地址

consul 的安装及使用： docker 单机版： docker run -d --name consul_1 -p 8500:8500 -v /alldata/consul/data:/consul/data -v /alldata/consul/config:/consul/config consul agent -server -ui -bootstrap-expect=1 -node=s1 -enable-script-checks=true -bind=0.0.0.0 -client=0.0.0.0 -datacenter=dc1 安装： wget https://releases.hashicorp.com/consul/1.5.3/consul_1.5.3_linux_amd64.zip unzip consul_1.5.3_linux_amd64.zip cp consul /usr/local/bin/ consul -v consul agent -dev -ui -config-dir=/etc/consul.d -client=192.168.142.191 #开发版安装成功 consul agent -server -bootstrap -ui -bind=172.19.0.138 -client=0.0.0.0 -data-dir /consul