Eureka总框架搭建（集成Eureka+Ribbon+Feign+Hystrix+Zuul）

最新推荐文章于 2022-08-23 23:56:31 发布

VIP文章 ZBFurr

最新推荐文章于 2022-08-23 23:56:31 发布

阅读量417

点赞数

分类专栏：学习回顾文章标签： java eureka ribbon 分布式

本文链接：https://blog.csdn.net/kjhkjhbkjh/article/details/115134066

版权

Eureka

总览

Eureka是用于SpringCloud Netflix的服务注册与发现的一个核心模块，与Zookeeper类似

Eureka 包含两个组件：Eureka Server 和 Eureka Client 。

Eureka Server 提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。 Eureka Client是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳（默认周期为30秒）。如果 Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉（默认周期为90秒）

三大角色

Eureka Server：提供服务的注册于发现。
Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。
Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。

使用步骤

大体上可分为：

1.导入依赖

2.编写配置

3.开启功能（@EnableXxxxx）

4.配置类

Eureka的自我保护机制

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YXgWMFXY-1616493246231)(C:\Users\Redgoat\AppData\Roaming\Typora\typora-user-images\image-20210321163028751.png)]

某时刻某一个微服务不可以用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存！默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生时，微服务与Eureka之间无法正常通行，以上行为可能变得非常危险了–因为微服务本身其实是健康的，此时本不应该注销这个服务。Eureka通过自我保护机制来解决这个问题

–当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。
一旦进入该模式，EurekaServer就会保护服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）。当网络故障恢复后，该 EurekaServer节点会自动退出自我保护模式。在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话：好死不如赖活着。
综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留），也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定。
在SpringCloud中，可以使用
```
eureka.server.enable-self-preservation = false 
```
禁用自我保护模式【不推荐关闭自我保护机制】

服务发现

在controller中注入DiscoveryClient对象

    @Autowired
    DiscoveryClient discoveryClient;

编写方法

@GetMapping("/discover")
public Object discover(){
   

    System.out.println("当前注册了的服务为"+discoveryClient.getServices());
    List<ServiceInstance> instances = discoveryClient.getInstances("springcloud-provider-dept");
    for (ServiceInstance instance : instances) {
   
        System.out.println("当前服务注册的实例有"+instance);
    }
    return discoveryClient;
}

访问指定url，发现服务

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DRG4RX6y-1616493246233)(C:\Users\Redgoat\AppData\Roaming\Typora\typora-user-images\image-20210321165149376.png)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-LmyP36cC-1616493246235)(C:\Users\Redgoat\AppData\Roaming\Typora\typora-user-images\image-20210321165135990.png)]

集群环境配置

创建端口号为7002和7003的服务器模块，除端口号不同外与7001服务器模块没有任何区别

CAP原则

RDBMS （Mysql、Oracle、sqlServer）===>ACID

NoSQL（redis、mongdb）===> CAP

ACID是什么？

A（Atomicity）原子性
C（Consistency）一致性
I （Isolation）隔离性
D（Durability）持久性

CAP是什么？

C（Consistency）强一致性
A（Availability）可用性
P（Partition tolerance）分区容错性
CAP的三进二：CA、AP、CP

CAP理论的核心一个分布式系统不可能同时很好地满足一致性，可用性和分区容错性这三个需求

根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类：

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错性的系统，通常性能不是特别高
AP：满足可用性，分区容错性的系统，通常可能对一致性要求低一些

作为服务注册中心，Eureka比Zookeeper好在哪里？著名的CAP理论指出，一个分布式系统不可能同时满足C（一致性）、A（可用性）、P（容错性）。由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。 Zookeeper保证的是CP； Eureka保证的是AP；

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个 Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上（即保证当前节点依然可用）
当网络稳定时，当前实例新的注册信息会被同步到其他节点中

※因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪

Ribbon

总览

Ribbon是什么？

※ 对于Eureka来说，所有结点都是平等的，那么用户请求到来时应该访问哪一个结点？——负载均衡算法

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。

简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如：连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer（简称LB：负载均衡）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法！

Ribbon能做什么？

LB，即负载均衡（Load Balance），在微服务或分布式集群中经常用的一种应用。

负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA（高可用）。HA（高可用）是负载均衡的核心。

常见的负载均衡软件有 Nginx，Lvs 等

Dubbo、SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义负载均衡简单分类：

集中式LB
- 即在服务的消费方和提供方之间使用独立的LB设施
- 如之前学习的Nginx（反向代理服务器），由该设施负责把访问请求通过某种策略转发至服务的提供方！
进程式LB
- 将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。
- Ribbon就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址！

集成Ribbon到SpringCloud中

Ribbon的LB逻辑集成到了消费方，故我们集成Ribbon只用操作消费方代码

导入依赖

		<!--ribbon -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
            <version>1.4.7.RELEASE</

最低0.47元/天解锁文章

ZBFurr

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
1
评论
Eureka总框架搭建（集成Eureka+Ribbon+Feign+Hystrix+Zuul）

Eureka总览Eureka是用于SpringCloud Netflix的服务注册与发现的一个核心模块，与Zookeeper类似Eureka 包含两个组件：Eureka Server 和 Eureka Client 。Eureka Server 提供服务注册服务，各个节点启动后，会在Eureka Server中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到。 Eureka Client是一个Java客户端，用于简化Eur
复制链接

扫一扫