2021升级版微服务教程3—Eureka彻底使用指南

2021升级版SpringCloud教程从入门到实战精通「H版&alibaba&链路追踪&日志&事务&锁」

教程全目录「含视频」：https://gitee.com/bingqilinpeishenme/Java-Wiki

Eureka服务注册和发现

本文要点：

• 什么是服务注册和发现
• Eureka的使用
• CAP
• Eureka集群搭建

什么是服务注册和发现

• 治理中心
• 服务注册
• 服务发现
• 心跳机制

以上均可以经过 Eureka 能够实现

Eureka基本使用

基本概念

Spring Cloud 封装了 Netflix 公司开发的 Eureka 组件来实现服务注册和发现。

在Eureka的架构中有两个角色：服务注册中心 Eureka Server 和 服务客户端 Eureka Client

• Eureka注册中心 Eureka Server

  Eureka Server 做为服务注册功能的服务器，是服务注册中心。系统中的其余微服务，使用 Eureka 的客户端链接到 Eureka Server并维持心跳链接。这样系统的维护人员就能够经过 Eureka Server 来监控系统中各个微服务是否正常运行。

• Eureka客户端 Eureka Client

  EurekaClient是一个Java客户端，用于简化Eureka Server的交互

  • 在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。若是Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒）
  • Eureka Client会缓存服务注册表中的信息。这种方式有必定的优点首先能够下降Eureka Server的压力，其次当全部的Eureka Server宕机，服务调用方依然能够完成调用

Eureka注册中心搭建

1. 在Project中建立module

2. 导入依赖

   <!--        引入SpringCloud Eureka server的依赖-->
           <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
           </dependency>
       </dependencies>

3. 启动类上加注解

4. 配置文件

   server:
     port: 8800
   
   eureka:
     client:
       #    eureka.client. register-with-eureka:因为该应用为注册中心，因此设置为false，表明不向注册中心注册本身
       registerWithEureka: false
       #      不主动发现别人
       fetchRegistry: false
       #    声明注册中心的地址
       serviceUrl:
         defaultZone: http://localhost:8800/eureka/
   
   #给当前应用起个服务名称 不能经过路径访问的  这个服务名称 在微服务中使用表明当前服务
   spring:
     application:
       name: eureka-server

5. 启动注册中心 访问注册中心的监控页面 http://localhost:8800

客户端搭建—用户服务

以用户服务为例

1. 建立项目

   

2. 导入相关依赖

   <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
           </dependency>

3. 启动类上加注解

4. 配置文件

   server:
     port: 8804
   
   #指定当前服务的名称  这个名称会注册到注册中心
   spring:
     application:
       name: cloud-user-8804
   
   #  指定 服务注册中心的地址
   eureka:
     client:
       serviceUrl:
         defaultZone: http://localhost:8800/eureka

经过以上四步 就完成了一个 Eureka客户端的搭建 直接启动项目 经过Eureka的注册中心能够看到

按照上述步骤，将商品服务和订单服务改造为Eureka客户端。

Eureka进阶使用

CAP理论

目前，大型网站几乎都是分布式的，分布式系统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的起点。

1998年，加州大学的计算机科学家 Eric Brewer 提出，分布式系统有三个指标。

• Consistency 一致性
• Availability 可用性
• Partition tolerance 分区容错性

它们的第一个字母分别是 C、A、P。

Eric Brewer 说，这三个指标不可能同时作到。这个结论就叫作 CAP 定理。

• 分区容错性

  大多数分布式系统都分布在多个子网络。每一个子网络就叫作一个区（partition）。分区容错的意思是，区间通讯可能失败。好比，一台服务器放在中国，另外一台服务器放在美国，这就是两个区，它们之间可能没法通讯。

  Node1 和 Node2 是两台跨区的服务器。Node1 向 Node2 发送一条消息，Node2可能没法收到。系统设计的时候，必须考虑到这种状况。

  通常来讲，分区容错没法避免，所以能够认为 CAP 的 P 老是成立。CAP 定理告诉咱们，剩下的 C 和 A 没法同时作到。

• 数据一致性

  因为系统问题，Node1 的数据不能即时同步给Node2，此时若是获取数据，会获取到不一致的数据，全部为了保证分布式系统对外的数据一致性，选择不返回任何数据【或者全部节点不响应任何请求】。

• 可用性

  要求系统内的节点在接受到请求的时候可以即时给出响应，具体来讲就是：一方面须要在合理的时间内给出响应，另外一方面即使是部分节点宕机，那么其余未宕机的节点也须要可以正常处理请求，即时返回的数据有问题。

一致性和可用性，为何不可能同时成立？

答案很简单，由于可能通讯失败（即出现分区容错），因此，对于分布式系统，咱们只能能考虑当发生分区错误时，如何选择一致性和可用性。

须要强调的是：C 和 A 的抉择是发生在有分区问题的时候，正常状况下系统就应该有完美的数据一致性和可用性

例子：

好比，咱们有个分布式系统，由三个节点 a、b、c 组成。其中节点 a 存放了 A 表的数据，b 存放了 B 表的数据，c 存放了 C 表的数据。

若是有一个业务，它的意图是想往 A 表插入一条新数据，在 B 表删除一条已有数据，在 C 表更新一条老数据，这个分布式系统该怎么处理这种业务？

技术上咱们对这种一个意图想作多件事的状况每每会包装成一个事务。当咱们包装成一个事务之后，咱们可能会经过先在 a 节点执行，而后去 b 节点执行，最后去 c 节点执行，等到都成功了，才会返回成功。

可是，发生了分区之后怎么办？当在 a、b 节点都成功了，到 c 发现发生了通讯故障？

此时，根据 CAP 定理，你有两个选择，要么就直接返回一个部分红功的结果给客户端，要么直接卡死等客户端超时或者返回失败给客户端。当返回部分红功的时候，这就是选择了可用性（A），当卡死或者返回失败给客户端的时候，就是选择了一致性（C）。

而根据一致性和可用性的选择不一样，开源的分布式系统每每又被分为 CP 系统和 AP 系统。

• 当一套系统在发生分区故障后，客户端的任何请求都被卡死或者超时，可是，系统的每一个节点老是会返回一致的数据，则这套系统就是 CP 系统，经典的好比 Zookeeper。

• 若是一套系统发生分区故障后，客户端依然能够访问系统，可是获取的数据有的是新的数据，有的仍是老数据，那么这套系统就是 AP 系统，经典的好比 Eureka。

不少时候一致性和可用性并非二选一的问题，大部分的时候，系统设计会尽量的实现两点，在两者之间作出妥协，当强调一致性的时候，并不表示可用性是彻底不可用的状态，好比，Zookeeper 只是在 master 出现问题的时候，才可能出现几十秒的不可用状态，而别的时候，都会以各类方式保证系统的可用性。而强调可用性的时候，也每每会采用一些技术手段，去保证数据最终是一致的。

自我保护机制

Eureka首页输出警告如图：

默认状况下，若是Eureka Server在必定时间内没有接受到服务实例的心跳，Eureka将会注销该实例(默认90秒).可是当网络分区发生故障时，微服务客户端和Eureka Server 没法正常通讯。以上行为可能变得特别危险了，由于微服务自己是健康的，此时不能注销该服务实例。

Eureka经过自我保护机制来解决这个问题，当Eureka Server在短期丢失过多的服务实例（可能发生了网络分区的故障），那么Eureka Server进入自我保护模式，一旦进入此模式，Eureka Server将会保护服务注册表中的信息，再也不删除服务注册表中的数据（也就是再也不注销任何的服务实例），当网络故障恢复后，Eureka Server会自动退出自我保护模式。

综上，自我保护模式是一种应对网络故障的安全保护措施，它的架构哲学是宁肯同时保留全部的微服务，也不盲目注销任何健康的微服务，使用自我保护模式可让Eureka，更加健壮，稳定。

一句话：大面积出现客户端失联的时候，Eureka 注册中心进入自我保护模式，不注销任何实例

自我保护机制的配置【了解】

在Eureka Server中配置关闭自我保护机制

#关闭自我保护机制  默认开启
eureka.server.enable-self-preservation=false

若是想及时剔除失效的eureka服务除了关闭自我保护机制外，能够调低eureka的心跳值

eureka-server服务端
配置文件中咱们添加以下配置

#关闭保护机制，以确保注册中心将不可用的实例正确剔除
eureka.server.enable-self-preservation=false
#（表明是5秒，单位是毫秒,清理失效服务的间隔 ）
eureka.server.eviction-interval-timer-in-ms=5000

客户端
配置文件中咱们添加以下配置

# 心跳检测检测与续约时间
# 测试时将值设置设置小些，保证服务关闭后注册中心能及时踢出服务
# 配置说明
#　　lease-renewal-interval-in-seconds 每间隔10s，向服务端发送一次心跳，证实本身依然”存活“
#　　lease-expiration-duration-in-seconds  告诉服务端，若是我20s以内没有给你发心跳，就表明我“死”了，将我踢出掉。
eureka.instance.lease-renewal-interval-in-seconds=10
eureka.instance.lease-expiration-duration-in-seconds=20

Eureka集群搭建

注册中心集群，防止注册中心单机故障。

1. 建立一个新的注册中心 eureka-server-8801

   1. 建立项目

   2. 导入依赖

   3. 启动类加注解

   4. 写配置文件

2. 修改注册中心 Eureka-server-8800的配置文件

3. 修改全部的客户端的配置，让客户端可以同时向两个注册中心注册

4. 启动全部的客户端和注册中心 看看能不能正常注册

若是你以为这篇内容对你挺有有帮助的话：

1. 点赞支持下吧，让更多的人也能看到这篇内容（收藏不点赞，都是耍流氓 -_-）

2. 欢迎在留言区与我分享你的想法，也欢迎你在留言区记录你的思考过程。

3. 以为不错的话，也能够关注 编程鹿 的我的公众号看更多文章和讲解视频（感谢你们的鼓励与支持🌹🌹🌹）