consul

在 Spring Cloud 体系中，几乎每个角色都会有两个以上的产品提供选择，比如在注册中心有：Eureka、Consul、zookeeper、etcd 等；网关的产品有 Zuul、Spring Cloud Gateway 等。在注册中心产品中，最常使用的是 Eureka 和 Consul，两者各有特点，企业可以根据自述项目情况来选择。 前面给大家详细介绍了 Eureka ，本节给大家介绍 Consul 的使用。 什么是Consul Consul 是 HashiCorp 公司推出的开源产品，用于实现分布式系统的服务发现、服务隔离、服务配置，这些功能中的每一个都可以根据需要单独使用，也可以同时使用所有功能。Consul 官网目前主要推 Consul 在服务网格中的使用。 与其它分布式服务注册与发现的方案相比，Consul 的方案更“一站式”——内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具。Consul 本身使用 go 语言开发，具有跨平台、运行高效等特点，也非常方便和 Docker 配合使用。 Consul 的主要特点有： Service Discovery : 服务注册与发现，Consul 的客户端可以做为一个服务注册到 Consul，也可以通过 Consul 来查找特定的服务提供者

Consul 是什么 Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件,由 HashiCorp 公司用 Go 语言开发, 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对. 命令行超级好用的虚拟机管理软件 vgrant 也是 HashiCorp 公司开发的产品. 一致性协议采用 Raft 算法,用来保证服务的高可用. 使用 GOSSIP 协议管理成员和广播消息, 并且支持 ACL 访问控制. Consul 的使用场景 docker 实例的注册与配置共享 coreos 实例的注册与配置共享 vitess 集群 SaaS 应用的配置共享 与 confd 服务集成，动态生成 nginx 和 haproxy 配置文件 Consul 的优势 使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是 Paxos, 而 etcd 使用的则是 Raft. 支持多数据中心，内外网的服务采用不同的端口进行监听。 多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等. zookeeper 和 etcd 均不提供多数据中心功能的支持. 支持健康检查. etcd 不提供此功能

一，准备工作 准备四台centos服务器，三台用于consul server 高可用集群，一台用于consul client作服务注册及健康检查。架构如下图所示 二，在四台服务器上安装consul 1，安装unzip 工具：yum install -y zip unzip 2，查看centos版本。uname -m,从 https://www.consul.io/downloads.html 获取下载地址 3，下载consul:wget https://releases.hashicorp.com/consul/1.6.2/consul_1.6.2_freebsd_amd64.zip 4，解压 :unzip consul_1.6.2_freebsd_amd64.zip 5，移动解压出来的文件到/etc/usr/bin：mv consul /etc/usr/bin 6，运行consul指令验证安装是否成功 三，配置consul 在四台服务器上分别在/tmp目录创建名为consul_config.json的文件，内容如下 服务端1配置文件 { "bootstrap_expect": 1, "datacenter": "kingsun_consul", "data_dir": "/tmp/consul", "node_name": "kingsun_consul_server_1",

1.docker拉取consul镜像 docker pull consul 2.consul参数详解 –net=host docker参数, 使得docker容器越过了net namespace的隔离，免去手动指定端口映射的步骤 -server consul支持以server或client的模式运行, server是服务发现模块的核心, client主要用于转发请求 -advertise 通告地址用于更改我们通告给集群中其他节点的地址。默认情况下，-bind地址是通告的。 -retry-join 指定要加入的consul节点地址，失败后会重试, 可多次指定不同的地址 -client Consul将绑定客户端接口的地址，包括HTTP和DNS服务器。默认情况下，这是“127.0.0.1”，只允许回送连接。 -bind 内部集群通信绑定的地址。这是集群中所有其他节点都应该可以访问的IP地址。默认情况下，这是“0.0.0.0”，集群内的所有节点到地址必须是可达的 -bootstrap-expect 此标志提供数据中心中预期服务器的数量。不应该提供此值，或者该值必须与群集中的其他服务器一致。指定后，Consul将等待指定数量的服务器可用，然后启动群集。允许自动选举leader，但不能与传统-bootstrap标志一起使用, 需要在server模式下运行。 -data-dir

一、简单介绍 Go Micro是一个插件化的基础框架，基于此可以构建微服务。Micro的设计哲学是『可插拔』的插件化架构。在架构之外，它默认实现了consul作为服务发现，通过http进行通信，通过protobuf和json进行编解码。 二、示例 为了更为直观，先从示例开始。 1、环境搭建（安装依赖） （1）安装protobuf 具体内容参考： https://blog.csdn.net/weixin_42117918/article/details/88920221 （2）安装go-micro go get github.com/micro/go-micro （3）安装micro go get github.com/micro/micro （4）安装consul 由于Micro的服务发现并没有自己实现，仅仅是提供Plugin来接入第三方服务发现(consul, etcd), 默认使用的是consule，因此需要安装consul。（以Windows开发环境为例） 下载consul： https://www.consul.io/downloads.html 在安装的位置解压得到 consul.exe 文件（我的解压位置是：C:\consul） 设置环境变量： 启动： cmd 命令窗口执行： consul agent -dev consul 自带 UI 界面，打开网址： http:/

一、跨主机网络概述 前面已经学习了 Docker 的几种网络方案：none、host、bridge 和 joined 容器，它们解决了单个 Docker Host 内容器通信的问题。本章的重点则是讨论跨主机容器间通信的方案。 docker 原生的 overlay 和 macvlan。 第三方方案：常用的包括 flannel、weave 和 calico。 二、准备 overlay 环境 为支持容器跨主机通信，Docker 提供了 overlay driver。Docerk overlay 网络需要一个 key-value 数据库用于保存网络状态信息，包括 Network、Endpoint、IP 等。Consul、Etcd 和 ZooKeeper 都是 Docker 支持的 key-vlaue 软件，我们这里使用 Consul。 1、环境描述 我们会直接使用上一节 docker-machine 创建的实验环境。在 docker 主机 host1（192.168.1.201）和 host2（192.168.1.203）上实践各种跨主机网络方案，在 192.168.1.200 上部署支持的组件，比如 Consul。 2、创建 consul 在 192.168.1.200 这台设备上面执行如下命令。 docker run -d -p 8500:8500 -h consul --name

How do I start a docker swarm cluster with consul back-end? I can't see any discovery param in the docker swarm init command? or the docker swarm join command? I successfully ran docker swarm init .... and than docker swarm join to start a cluster on the internal swarm discovery mechanism, but it's not recommended for production. So what am I missing? You are running the newer Swarm Mode commands but asking about the usage of the classic Swarm that runs as a container, these are two very different things. Swarm Mode uses a raft implementation for the manager state that is not swappable with an

在上一篇文章里面，我们讲了如何搭建带有Acl控制的Consul集群。 这一篇文章主要讲述一下上一篇文章那一大串配置文件的含义。 1.配置说明 #1.1 勘误 上一篇文章关于机器规划方面，consul client agent的端口写的有误。这里再贴一下正确的机器规划。 1.2 我们先来看一下consul server agent的配置。 上一节中，提供了三个配置文件，consul-server1.json, consul-server2.json以及consul-server3.json。 其中consul-server1.json参数最多，这里就以它来说明各个配置的含义： { "datacenter":"dc1", "primary_datacenter":"dc1", "bootstrap_expect":1, "start_join":[ "10.211.55.25", "10.211.55.26" ], "retry_join":[ "10.211.55.25", "10.211.55.26" ], "advertise_addr": "10.211.55.28", "bind_addr": "10.211.55.28", "server":true, "connect":{ "enabled":true }, "node_name":"consul-server1",

服务注册 - 服务进程在注册中心注册自己的位置。它通常注册自己的主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的详细资料。 服务发现 - 客户端应用进程向注册中心发起查询，来获取服务的位置。服务发现的一个重要作用就是提供一个可用的服务列表。 服务定义的格式类似如下： { "service":{ "id": "jetty", "name": "jetty", "address": "192.168.1.200", "port": 8080, "tags": ["dev"], "checks": [ { "http": "http://192.168.1.200:8080/health", "interval": "5s" } ] } } 其中，check是用来做服务的健康检查的，可以有多个，也可以没有，支持多种方式的检查。check定义在配置文件中，或运行时通过HTTP接口添加。Check是通过HTTP与节点保持一致。 有五种check方法： check必须是script或者TTL类型的，如果是script类型，则script和interval变量必须被提供，如果是TTL类型，则ttl变量必须被提供 script是consul主动去检查服务的健康状况，ttl是服务主动向consul报告自己的健康状况。 以下是几种配置方式 Check必须是Script、HTTP、TCP

最近使用consul作为项目的服务注册与服务发现的基础功能。在塔建集群使用中遇到一些坑，下面一个个的记录下来。 consul集群多node consul集群的node也就是我们所说的consul实例。集群由多个node组成，为了集群的可用性，需要超过半数的node启用server。如5个node中建议3个启用server模式，3个node组成的集群就2个node启用server模式。 看到这里的时候你一定觉得没有什么问题呀，但是consul坑就是多。加入你的集群组成如下： Node Address Status Type Build Protocol DC Segment BJ-MQTEST-01 10.163.145.117:8301 alive server 1.0.6 2 iget-topology-aliyun <all> BJ-MQTEST-02 10.163.147.47:8301 alive server 1.0.6 2 iget-topology-aliyun <all> BJ-TGO-01 10.163.145.110:8301 alive client 1.0.6 2 iget-topology-aliyun <default> 那么client可以使用上述的3个ip连接到consul集群，假设client A使用使用10.163.145