Eureka概述

（一）服务注册发现组件Eureka

1．什么是服务的注册?

有个产品服务,如果并发量太大的话,产品服务如果挂了,这个群体就崩溃了, 所以我们需要多个一样的产品服务,把多个产品服务注册到一个注册中心里面来,注册其实就是产品服务把自己的ip和端口保存到注册中心里面去.
有了这个ip和端口信息,消费者就可以找到对应的服务了.

2．什么是服务的发现?

消费者会连接上注册中心然后把注册中心中所有注册的服务下载到自己的本地上,这步骤叫服务的发现.

负载算法
既然我消费者把注册中心中所有的注册信息都下载到了本地,我要调用服务的时候我不可能调用所有的产品服务,我肯定是只调用其中的一个服务,这里面还有一个负载的算法,从几个产品服务里面通过算法获取其中一个服务的ip和地址就可以直接调用了.
负载算法有好多种,比如随机,轮询等等.



而在SpringCloud中，大量使用了Netflix的开源项目，其中Eureka就属于Netflix 提供的发现服务组件，所有的微服务都注册到Eureka中，它在其中扮演的就是注册中心的角色，后面所有的客户端直接从注册中心获取所需要的服务

Eureka是Netflix的一个子模块,也是核心模块之一,Eureka是一个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移

功能类似注册中心,注册中心就是将一些服务的服务信息注册到注册中心上面去(不要想的多难),其实就是把你要提供的接口信息,放到系统里面可以查询出来,可以知道有多少个接口

注册中心有很多,比如zookeeper,redis,SpringCloud的Eureka

Eureka客户端是可以互相交互的,是轮询负载算法,如果哪个服务挂了,不会立即消失,因为你在服务一启动之后,就注册到Eureka里面,服务不知道你挂了,就用了心跳模式(轮询模式)

3．Eureka解决的问题

像上面RPC架构,我怎么知道提供了多少个接口,我怎么知道调用接口是什么情况?

通过注册中心,两套系统当项目一启动的时候,先注册到注册中心上面来,必须标识一下注册中心,注册中心知道系统有没有启动.
然后会员系统和订单系统调用就是直接从注册中心那里获取对方的接口信息,

5．Eureka和Zookeeper比好在哪里

任何一个分布式系统按照现在的要求最多只能同时较好的满足两个.

CAP理论的核心是:一个分布式系统不可逆同时很好的满足一致性,可用性和分区容错性这三个需求,因此,根据CAP原理将NoSQL数据分成满足CA原则,满足CP原则和满足AP原则三大类:
CA-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大
CP-满足一致性,分区容忍性的系统,通常性能不是特别高
AP-满足可用性,分区容忍性的系统,通常可能对一致性要求低一点.



分布式 部署不可能是一台机器,所以说CAP 中的P (分区容错性)是绝对得需要占有的,也就是你在构建你的业务网站操作和产品的时候,对于分布式的系统和结构,只能CP 和AP 二选一
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点的,

假如说在淘宝双11的时候, 你是选一致性还是可用性??
我们只能保证AP (满足可用性,分区容忍性),不能选择CP
理由如下
我们对象时整个网站,不是整个产品,如果你作为网站的技术经理或者架构师,思考这么一个问题,首先P是绝对固定,要被拿走的,因为是分布式,分区容错性是必须保证的,假设选C (强一致性) ,双十一的时候,我点进去肯定会有一种东西,多少人点赞什么的,查看数什么的, 这些数据代表客户对某一个产品访问的喜爱爱好等等. 这个数据很重要,比如猜你喜欢功能. 所以说强一致性是很重要,但是如果你不保证A只是保证C ,也就说一瞬间你跟我讲多少人喜欢这件毛衣,11万还是12万,这个数据对客户是不关心的,客户只是关心双11当天这个网站能不能用,能不能买东西 ,但是如果A丢了,双11整个网站都崩溃了,广大群众就会因为买不了东西不爽,可能也会上头条, 比如双11当天淘宝网站瘫痪的新闻,这个灾难是谁都承受不起的,.所以,只能是保证这个网站不能瘫痪, 等过了双11之后再给商品多少人点赞多少人查看数据统计出来

所以结论, Eureka比zookeeper好在哪里
著名的CAP理论指出,一个分布式系统不可能同时满足C(一致性)A(可用性)P(分区容错性),由于分区容错性P是在分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡

Zookeeper保证的是CP
Eureka则是AP

6．为什么推荐Zookeeper作为SpringCloud的基础设置

Eureka

如果是Eureka的话,假如三台服务器ABC ,此时C服务器挂掉了,Eureka的心跳检测可能会没反应过来,这个时候Eureka服务器还没检测到C 生产者服务器宕机了,此时服务的消费者应用程序恰巧被Eureka轮询到C服务器上就会出现访问失败的情况,此时会触发retry重试机制,由Eureka重写负载均衡轮询一次给Consumer 要调用的Producer的ip和端口
所以从上面的案例的角度来讲的话,会出现三分之一的概率会失败.


Zookeeper
Zookeeper一致性强(CP),非高可用,
举例,假设有三台服务器,如果用Zookeeper来做的话,假设A服务器挂掉了,由于Zookeeper的高一致性,Zookeeper会及时发现,此时服务的消费者不会调用到那个已经挂掉的服务器