服务注册与发现Consul

在Eureka的GitHub上，宣布Eureka 2.x闭源。这意味着如果开发者继续使用作为 2.x 分支上现有工作 repo 一部分发布的代码库和工件，则将自负风险。
Eureka的替换方案：Zookeeper、Consul、Nacos（服务治理 + 配置中心 | Nacos = Eureka + Config）

consul 概述：

　　Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。与其它分布式服务注册与发现的方案，Consul 的方案更“一站式”，内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其它工具（比如 ZooKeeper 等）。使用起来也较为简单。Consul 使用 Go 语言编写，因此具有天然可移植性(支持Linux、windows和Mac OS X)；安装包仅包含一个可执行文件，方便部署，与 Docker 等轻量级容器可无缝配合。
　　Consul 的优势：

　　　　使用 Raft 算法来保证一致性, 比复杂的 Paxos 算法更直接. 相比较而言, zookeeper 采用的是Paxos, 而 etcd 使用的则是 Raft。
　　　　支持多数据中心，内外网的服务采用不同的端口进行监听。多数据中心集群可以避免单数据中心的单点故障,而其部署则需要考虑网络延迟, 分片等情况等。zookeeper 和 etcd 均不提供多数据中心功能的支持。
 　　　　支持健康检查。 etcd 不提供此功能。
　　　　支持 http 和 dns 协议接口。 zookeeper 的集成较为复杂, etcd 只支持 http 协议。
　　　　官方提供 web 管理界面, etcd 无此功能。
　　　　综合比较, Consul 作为服务注册和配置管理的新星, 比较值得关注和研究。

　　特性：
　　　　服务发现
　　　　健康检查
　　　　Key/Value 存储
　　　　多数据中心

　　consul与Eureka的区别
　　　　（1）一致性
　　　　Consul强一致性（CP）
　　　　　　服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
　　　　　　Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
　　　　Eureka保证高可用和最终一致性（AP）
　　　　　　服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
　　　　　　当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。
　　　　（2）开发语言和使用
　　　　　　eureka就是个servlet程序，跑在servlet容器中
　　　　　　Consul则是go编写而成，安装启动即可

consul的下载与安装：
　　官网：https://www.consul.io/downloads.html

　　window系统安装：下载完解压，进入解压后的文件夹，在cmd命令行执行　consul agent -dev -client=0.0.0.0　以开发者模式快速启动

　　安装成功后，在浏览器输入 http://127.0.0.1:8500/ 即可打开web管理界面

consul的基本使用：

　　Consul 支持健康检查,并提供了 HTTP 和 DNS 调用的API接口完成服务注册，服务发现，以及K/V存储这些功能。
　　服务注册与发现：

　　　　注册服务

　　　　　　通过postman发送put请求到 http://192.168.43.33:8500/v1/catalog/register 地址可以完成服务注册

{
    "Datacenter": "dc1",
        "Node": "node01",
        "Address": "192.168.43.33",
        "Service": {
    "ID":"mysql-01",
            "Service": "mysql",
            "tags": ["master","v1"],
    "Address": "192.168.43.33",
            "Port": 3306
    }
}

　　　　服务查询

　　　　　　通过postman发送get请求到 http://192.168.43.33:8500/v1/catalog/services　　查看所有的服务列表

　　　　　　

　　　　　　通过postman发送get请求到 http://192.168.43.33:8500/v1/catalog/service/服务名　　查看具体的服务详情

　　　　　　

　　　　服务删除

　　　　　　通过postman发送put请求到http://192.168.43.33:8500/v1/catalog/deregister　　删除服务

{
    "Datacenter": "dc1",
    "Node": "node01",
    "ServiceID": "mysql-01"
}

基于consul的服务注册：

　　复制一份 erueka 工程的项目，进行改造

　　修改每个微服务的pom文件，添加SpringCloud提供的基于Consul的依赖

<!--SpringCloud提供的基于Consul的服务发现-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>
<!--actuator用于心跳检查-->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

　　配置服务注册

　　　　修改每个微服务的application.yml配置文件，添加consul服务发现的相关配置信息

spring:
  ...省略
  cloud:
    consul: #consul相关配置
      host: 192.168.43.33 #ConsulServer请求地址
      port: 8500 #ConsulServer端口
      discovery:
        #是否注册
        register: true
        #实例ID（唯一）springCloud官网文档的推荐，为了保证生成一个唯一的id ，可以使用
        instance-id: ${spring.application.name}:${spring.cloud.client.ip-address}
        #服务实例名称
        service-name: ${spring.application.name}
        #服务实例端口
        port: ${server.port}
        #健康检查路径
        health-check-path: /actuator/health
        #健康检查时间间隔
        health-check-interval: 15s
        #开启ip地址注册
        prefer-ip-address: true
        #实例的请求ip
        ip-address: ${spring.cloud.client.ip-address}

　　　　启动测试，在控制台中查看服务列表

　　　　　　

　　　　服务调用Ribbon与consul配合使用和与erueka配合使用是一样的，所以不用修改任何东西，访问 http://localhost:9002/order/buy/1 查看展示效果如下

　　　　　　

 consul高可用集群：

　　分为Server和Client

　　　　Server是consul服务端高可用集群，Client是consul客户端。
　　　　consul客户端不保存数据，客户端将接收到的请求转发给响应的Server端。Server之间通过局域网或广域网通信实现数据一致性。
　　　　每个Server或Client都是一个consul agent。Consul集群间使用了GOSSIP协议通信和raft一致性算法。

　　　　　　Agent——agent是一直运行在Consul集群中每个成员上的守护进程。通过运行 consul agent来启动。最开始在window启动console命令（consul agent -dev -client=0.0.0.0），就是启动一个开发者的守护进程。

　　　　　　　　agent可以运行在client或者server模式。指定节点作为client或者server是非常简单的，除非有其他agent实例。所有的agent都能运行DNS或者HTTP接口，并负责运行时检查和保持服务同步。

　　在每个数据中心，client和server是混合的。一般建议有3-5台server。这是基于有故障情况下的可用性和性能之间的权衡结果（consul强一致性[cp]导致），因为越多的机器加入达成共识越慢。然而，并不限制client的数量，它们可以很容易的扩展到数千或者数万台。

　　Consul的核心知识：

　　　　Gossip协议（流感协议）

　　　　　　传统的监控，由于每个节点都会向server报告状态，随着节点数量的增加server的压力随之增大。在所有的Agent之间（包括服务器模式和普通模式）运行着Gossip协议。服务器节点和普通Agent都会加入这个Gossip集群，收发Gossip消息。每隔一段时间，每个节点都会随机选择几个节点发送Gossip消息，其他节点会再次随机选择其他几个节点接力发送消息。这样一段时间过后，整个集群都能收到这条消息。
　　　　RAFT一致性算法
　　　　　　为了实现集群中多个ConsulServer中的数据保持一致性，consul使用了基于强一致性的RAFT算法。
　　　　　　在Raft中，任何时候一个服务器可以扮演下面角色之一：

　　　　　　　　1. Leader: 处理所有客户端交互，日志复制等，一般一次只有一个Leader.
　　　　　　　　2. Follower: 类似选民，完全被动
　　　　　　　　3. Candidate（候选人）: 可以被选为一个新的领导人。

　　　　　　Leader全权负责所有客户端的请求，以及将数据同步到Follower中（同一时刻系统中只存在一个Leader）。Follower被动响应请求RPC，从不主动发起请求RPC。Candidate由Follower向Leader转换的中间状态。