Eureka概念

Eureka

什么是服务治理？

在传统rpc远程调用框架中，管理每个服务与服务间的关系比较复杂，管理比较复杂，需要使用服务治理，服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册

什么是服务注册与发现

避免单点故障

Eureka俩个组件

CAP理论（eureka与zookeeper选型）

C:Consistency，数据一致性
A:Availability，可用性，系统响应速度
P：Partition tolerance，分区容错性

1.Partition tolerance
分区容错性：大多数分布式系统，都分布在多个子网络，每个子网络就叫一个区，分区容错意思是：区之间通信可能失败，例如一个区在中国，一个区在美国，它们之间可能会无法通信
如下图，G1和G2是两个区的服务器，G1向G2发送一条消息，G2可能无法收到，系统设计时，必须考虑这种情况，但是一般情况下，分区容错无法避免，所以，我们认为在CAP理论中，P总是成立

2.Consistency
一致性：用户写和读的内容保持一致，例如：client写的是v1，读的就必须是v1，这就是数据一致

问题是，由于client可能想G1写数据，但是在G2读数据，由于G1和G2网络通信失败，造成数据不一致，这就不满足一致性

3.Availability
可用性：即只要服务器收到用户的请求，立刻做出回应，例如client无论向G1还是G2发起请求，只要服务器收到请求，立刻将数据相应给client

4.Consistency和Availability的矛盾
一致性和可用性不能同时成立，原因很简单，因为通信可能失败（分区容错性一定成立）
如果保证G1和G2数据一致性，那么客户端在向G1写数据时，G1必须将数据同步到G2，只有数据同步，才能保证数据的一致性，但是，在同步时，网络可能出现异常，此时client向G2发起读的请求，
如果要保持数据一致性，G2必须等到数据同步后才能响应给client，这样就不能保证可用性
如果要保证可用性，则G2需要立刻向client响应，但此时并未同步到G1的数据，那么响应的数据与client之前写的数据不一致
结论：CAP不能在分布式结构中同时存在，一般只能做到cp或者ap

5.eureka和zookeeper选型
强一致性（偏向cp）：任意时间，查看分布式结构的任意节点，数据都是一致的
弱一致性（最终一致性）（偏向ap）：任意时间，整体一致性未必一致，但是只要过了一段时间（毫秒、微秒）,整体一致性存在，可用性更高
eureka：偏向ap（对一致性要求较低，响应要求较高）
zookeeper:偏向cp，一致性要求较高，响应相对较低