Spring Cloud Eureka+Consul学习（二）

Consul和Eureka的优劣势：

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

1. consul自带key-value存储服务、健康检查 和 web页面。 内部使用了gossip协议和Raft协议，也正因为此Consul维护起来难度比eureka要大。
2. consul提供了官方的docker镜像，直接使用docker-consul集群用户服务发现的话，虽然维护起来难度较大，但是运维成本会直线下降，
3. 服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
4. Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。

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

1. Eureka完全开源，是Netflix公司的开源产品，经历了该公司三年时间的迭代，在功能和性能上都非常稳定
2. Eureka是SpringCloud首选推荐的服务注册与发现组件，与SpringCloud其他组件可以无缝对接
3. Eureka和其他组件，例如负载均衡组件Ribbon、熔断器组件Hystrix、熔断监控组件Hystrix Dashboard、熔断器绝活监控Turbine组件，以及Zuul组件相互配合，能够很容易实现服务注册、负载均衡、熔断和智能路由等功能。这些组件共同被称为Netflix OSS组件
4. 服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
5. 当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。

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

Eureka服务治理机制与Dubbo服务治理机制的比较

Feature	Eureka	zookeeper	Consul
服务健康检查	可配支持	(弱)长连接，keepalive	服务状态，内存，硬盘等
CAP	AP	CP	CP
watch支持（客户端观察到服务提供者变化）	支持 long polling/大部分增量	支持	全量/支持long polling
自我保护	支持	-	支持
客户端缓存	支持	-	支持
自身集群的监控	metrics	-	metrics

Eureka支持健康检查，自我保护等

Zookeeper为CP设计，Eureka为AP设计。作为服务发现产品，可用性优先级较高，一致性的特点并不重要，宁可返回错误的数据，也比不反回结果要好得多。

服务列表变更Zookeeper服务端会有通知，Eureka则通过长轮询来实现，Eureka未来会实现watch机制

理解CAP

理解第一步：分布式是前提

为了彻底讲清楚这个问题，首先需要明白的是，CAP理论的主要场景是在分布式环境下，在单机环境下，基本可不考虑CAP问题。如果不明白什么是分布式场景，请看下面这张图（此图借用自如何正确理解CAP理论一文）。图中除最上面那台标记为“客户端”电脑以外的部分（包括横着的那根粗线，以及A\B\C三个节点）共同组成了一个分布式系统。

理解第二步：C、A、P准确定义

其次，需要搞清楚Eric Brewer大神对CAP三者的准确定义。这里借用一下维基百科CAP理论一文中关于C、A、P三者的定义。（其实也试图想参考国人的某百科，但发现貌似仍然讲得不清不楚)。

Consistency	Availability	Partition tolerance
Every read receives the most recent write or an error	Every request receives a (non-error) response – without guarantee that it contains the most recent write	The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

三者的定义及个人理解如下：

• Consistency:一致性，原文翻译过来是说，对于任何从客户端发达到分布式系统的数据读取请求，要么读到最新的数据要么失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。

• Availability:可用性，原文翻译过来是说，对于任何求从客户端发达到分布式系统的数据读取请求，都一定会收到数据，不会收到错误，但不保证客户端收到的数据一定是最新的数据。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。

• Partition tolerance:分区容忍性，这个词有点怪，如果直接看中文的确有点不太好理解。那么看原文翻译怎么说的，分布式系统应该一直持续运行，即使在不同节点间同步数据的时候，出现了大量的数据丢失或者数据同步延迟。
  (PS:^V^,您瞧瞧，包容度多高，简直是打不死的小强，现在应该能够理解为什么用tolerance容忍度这个词了吧。)
  换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

理解第三步：串起来,So easy

搞明白三个字母的准确含义之后，结合到上面那张图，应该比较容易理解了。

对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。试想一下，如果稍微出现点数据丢包，我们的整个系统就挂掉的话，我们为什么还要做分布式呢？所以，按照CAP理论三者中最多只能同时保证两者的论断，对于任何分布式系统，设计时架构师能够选择的只有C或者A，要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。

PS:其实维基百科的原文里面也有这么一段，说的也是上面的意思，我就不翻译了：
CAP is frequently misunderstood as if one has to choose to abandon one of the three guarantees at all times. In fact, the choice is really between consistency and availability only when a network partition or failure happens; at all other times, no trade-off has to be made.

========================================================================
参考： https://blog.csdn.net/guitar___/article/details/80656681