CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）

Consul与Eureka区别

Consul强一致性(C)带来的是：

1. 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功.

2. Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

Eureka保证高可用(A)和最终一致性：

1. 服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功

2. 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。

其他方面，eureka就是个servlet程序，跑在servlet容器中; Consul则是go编写而成。

1.1.1 Spring Cloud Eureka

1.1.1.1 概述

Spring Cloud Eureka是Spring Cloud Netflix项目下的服务治理模块。而Spring Cloud Netflix项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。

1.1.1.2 重要注解

@EnableEurekaServer // 注册服务中心

@EnableEurekaClient // 服务提供端

1.1.1.3 服务治理机制

Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端）

Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心）

服务注册与续约：首先服务注册到eureka server上，注册之后服务提供者会维护一个心跳，用来告诉eureka server “我还OK”，也就是续约Renew，心跳默认三十秒检测一次。

服务剔除：当服务实例正常下线时，服务实例会告诉eureka server “我要下线了”，将服务状态改为 down。有时服务会出现非正常下线，eureka server 在启动时会去创建一个定时任务检测服务提供者，剔除服务，检测时间默认90秒。

自我保护：eureka server 会去将心跳在15分钟内是否低于85%，如果出现eureka会将他们保护起来，让这些实例不会过期，这样客户端就很容易拿到不存在的实例，这就需要容错机制，客户端重试、断路器等机制。

总结：

Eureka Client负责：

服务注册、服务续约、服务正常下线、查询eureka server中服务实例列表。

Eureka Server 负责：

服务非正常下线剔除、服务保护。

1.1.1.4 Zone

Eureka 有一个 Region 和 Zone 的概念，你可以理解为现实中的大区（Region）和机房（Zone）

Eureka Client 在启动时需要指定 Zone，它会优先请求自己 Zone 的 Eureka Server 获取注册列表同样的，Eureka Server 在启动时也需要指定 Zone，如果没有指定的话，其会默认使用 defaultZone.

1.1.1.5 服务配置

微服务client，配置文件：

##eureka

eureka.client.serviceUrl.defaultZone=http://localhost:8081/eureka/

eureka.instance.instance-id=${spring.application.name}:${server.port}

# 设置微服务调用地址为IP优先（缺省为false）

eureka.instance.prefer-ip-address=true

# 心跳时间，即服务续约间隔时间（缺省为30s）

eureka.instance.lease-renewal-interval-in-seconds=30

# 发呆时间，即服务续约到期时间（缺省为90s）

eureka.instance.lease-expiration-duration-in-seconds=90

注册中心配置文件：

## server

server.port=8081

##eureka

#指定环境

eureka.environment=work

# 设置是否将自己作为客户端注册到注册中心（缺省true）

# 这里为不需要（查看@EnableEurekaServer注解的源码，会发现它间接用到了@EnableDiscoveryClient）

eureka.client.register-with-eureka=false

# 设置是否从注册中心获取注册信息（缺省true）

# 因为这是一个单点的EurekaServer，不需要同步其它EurekaServer节点的数据，故设为false

eureka.client.fetch-registry=false

eureka.client.serviceUrl.defaultZone=http://localhost:${server.port}/eureka/

#是否开启自我保护模式，默认为true。

eureka.server.enable-self-preservation=true

#续期时间，即扫描失效服务的间隔时间（缺省为60*1000ms）

eureka.server.eviction-interval-timer-in-ms=10000 # 此处不开启缓存，上方配置开启一个即可

# use-read-only-response-cache: false

# 指定每分钟需要收到的续约次数的阈值，默认值就是：0.85

renewal-percent-threshold: 0.85

# 续约频率提高，默认：30

leaseRenewalIntervalInseconds: 10

------------------------------------------------------------------------------

注意下面开始讲解Consul

1.1.2 Consul

1.1.2.1 概述

Consul是基于GO语言开发的开源工具，主要面向分布式，服务化的系统提供服务注册、服务发现和配置管理的功能。Consul的功能都很实用，其中包括：服务注册/发现、健康检查、Key/Value存储、多数据中心和分布式一致性保证等特性。Consul本身只是一个二进制的可执行文件，所以安装和部署都非常简单，只需要从官网下载后，在执行对应的启动脚本即可。

1.1.2.2 Consul特性

基础特性：

1.服务注册/发现

为什么微服务架构下就需要做服务注册和服务发现呢？微服务的目标就是要将原来大一统的系统架构，拆分成细粒度的按功能职责分成的小系统，这样就会出现很多小的系统，部署的节点也会随之增加。试想一下，如果没有一个统一的服务组件来管理各系统间的列表，微服务架构是很难落地实现的。

Consul提供的服务注册/发现功能在数据强一致性和分区容错性上都有非常好的保证，但在集群可用性下就会稍微差一些（相比Euerka来说）。

2.数据强一致性保证

Consul采用了一致性算法Raft来保证服务列表数据在数据中心中各Server下的强一致性，这样能保证同一个数据中心下不管某一台Server Down了，请求从其他Server中同样也能获取的最新的服务列表数据。数据强一致性带来的副作用是当数据在同步或者Server在选举Leader过程中，会出现集群不可用。

3.多数据中心

Consul支持多数据中心(Data Center),多个数据中心之间通过Gossip协议进行数据同步。多数据中心的好处是当某个数据中心出现故障时，其他数据中心可以继续提供服务，提升了可用性。

4.健康检查

Consul支持基本硬件资源方面的检查，如：CPU、内存、硬盘等

5.Key/Value存储

Consul支持Key/Value存储功能，可以将Consul作为配置中心使用，可以将一些公共配置信息配置到Consul，然后通过Consul提供的 HTTP API来获取对应Key的Value。

高级特性：

1.HTTP API

2.ACL

1.1.2.3 Consul工作模式

从上图可以看到，Consul中包括的3种不同的角色：Client、Server、Server-Leader。还有一个在图上没有标出来的角色Agent，一共4个角色。

· Agent

1.是一个守护线程

2.跟随Consul应用启动而启动

3.负责检查、维护节点同步

· Client

1.转发所有请求给Server

2.无状态，不持久化数据

3.参与LAN Gossip的健康检查

· Server

1.持久化数据

2.转发请求给Server-Leader

3.参与Server-Leader选举

4.通过WAN Gossip，与其他数据中心交换数据

· Server-Leader

1.响应RPC请求

2.服务列表数据同步给Server

1.1.2.4 Consul工作原理

服务注册的方式

Consul服务注册有两种方式：HTTP API & JSON配置文件

方式一：HTTP API

http://{ip}:8500/v1/agent/service/register/:service

方式二：JSON 配置文件

启动Consul增加启动参数-config-dir

nohup ./consul agent -dev -config-dir=/consul-conf/service.json &

服务发现的方式

服务发现的方式同时有两种：HTTP API & DNS Agent

方式一：HTTP API

获取某个service下健康的服务列表信息

http://{ip}:8500/v1/health/service/:service

方式二：DNS Agent

工作流程

参考文档：https://www.jianshu.com/p/32dc52f28a14

https://www.cnblogs.com/knowledgesea/p/11208000.html