SpringCloud——Eureka 讲解

当我们加入了eureka注册中心之后(这里eureka注册中心也是一个模块，需要独立出来)，他就会把这个分布式项目中所有的模块都记录下来，都登记一下名字，因为上面我们说到了，每一个模块都既有可能是服务提供者，也有可能是服务消费者，我们将他们全部都登记下来，这样当某个模块需要调用另一个模块时，它只需要向eureka要就行了，看看eureka中有没有。OK，以上就是Eureka的服务配置和服务注册，也

m0_70325779

985人浏览 · 2023-06-27 18:52:23

m0_70325779 · 2023-06-27 18:52:23 发布

4.1 第一步：我们要创建一个微服务项目，引入EurekaServer依赖，依赖如下：

4.2 第二步：要在启动类上添加 @EnableEurekaServer 注解，开启Eureka注册中心功能，如下所示：

4.3 第三步：要在EurekaServer模块中编写application.yml文件，编写如下配置：

五. Eureka注册中心实现服务注册

5.1 第一步：引入EurekaServer客户端依赖

5.2 第二步：仍然是在我们对应业务模块中编写application.yml文件

6.6 什么是Eureka的自我保护模式？

这两天开始了我的Java实习生活，今天2023年6月27日，因为大部分实习生还没有到公司，应主管要求，给我们几个来得早的实习生分配了一个小任务，让我们趁这几天自己做一个小型微服务分布式小系统，所以自己也是边学边整理，将所学习的知识点整理概括，方便日后复习观看。

相比说起了微服务，大多数在校生或许会觉得他遥不可及，或者觉得它比较难，但是，在现在大多数互联网企业，中型，中大型，大型企业几乎都在使用分布式系统，在一些发展良好的中小型企业，他们的系统模块也在逐渐向微服务分布式系统进行转变。而在微服务框架中，SpringCloud是绝大多数企业最为广泛使用的一个微服务框架，所以，学习SpringCloud对我们来说非常重要，对于我们以后面试找工作，也是一个很大的加分项。

OK，我们家下来开始正文

一. 什么是服务提供者与服务消费者？

我们都知道，微服务就是把一个项目拆分成很多功能模块。举例，一个电商项目，我们可以把它拆分成多个模块，比如用户模块，商家模块等等。各个模块中只负责自己的那一部分功能，别的功能无需关心。当一个模块需要另一个模块中的某个功能时，我们只需要让被调用的模块暴露自己的业务接口即可；调用者称为服务消费者，被调用者称为服务提供者。但是，这都只是相对而言的，比如说，服务A调用了服务B，服务B又调用了服务C，这时B又是什么角色呢？

很明显，服务B相对于服务A来说是服务提供者，服务B相对于服务C来说是服务消费者。因此，总结上面所举的例子，我们可以得出以下结论：

（1）服务提供者：暴露接口给其他微服务调用。

（2）服务消费者：调用其他微服务提供的接口。

（3）提供者与消费者是相对而言的。

（4）一个服务，既可以是提供者，又可以是消费者。

二. Eureka注册中心简单介绍

看下面两张图片

order-service是我们微服务项目中的一个订单模块，里面含有一个查询订单信息的方法；

user-service是我们微服务项目中的一个用户模块，里面包含了一个查询用户信息的方法。

假设现在某位用户要查询某条订单信息，而订单信息中又包含了用户信息，那么order-service订单模块和user-service用户模块这两个模块之间一定是有调用关系的。但是，由于我们已经将他们拆分成了独立的模块，它不像单体项目那样，是无法直接进行调用的，微服务项目中的远程调用大多是以发送http请求的方式来调用其他业务模块的方法；

但现在问题又来了，我们已经对微服务做了拆分，从理论上讲，我们的订单模块根本就不知道用户模块的存在，更无从谈起调用用户模块中的方法了。而且，我们如果对user-service模块再做一个集群，现在有三个user-service模块，order-service又是怎么知道该调用哪一个user-service模块呢？

这里就需要说到我们的重点了，它就是Eureka注册中心，看下图

当我们加入了eureka注册中心之后(这里eureka注册中心也是一个微服务模块，只是没有业务方法，但也需要独立出来)，在Eureka模块中的pom.xml文件中引入Eureka服务端依赖，然后在每个微服务项目中引入Eureka客户端依赖，重启项目。它就会把这个分布式项目中所有的模块都记录下来，都登记一下名字，因为上面我们说到了，每一个模块都既有可能是服务提供者，也有可能是服务消费者，我们将他们全部都登记下来，这样当某个模块需要调用另一个模块时，它只需要向eureka要就行了，看看eureka中有没有。如图中所示，order-service从eureka-service中拉取出自己需要的信息即可。

这里还有一个问题不知道各位想到了没有，假设order-service挑中了localhost8081端口的user-service，但是localhost8081端口的user-service业务出现了故障无法对外正常服务，怎么办？

这里就要提到Eureka的另一个功能，心跳监控，当一个模块被注册到eureka注册中心之后，它每隔30秒就会向eureka注册中心发送一次请求，好比是心脏跳动，每隔30秒跳动一次，来向eureka证明自己还在正常运作，没有出现故障。如下图所示

当一个功能模块没有向eureka发送心跳请求时，eureka就会认为它出现故障了，然后会将它从注册列表中提出，如下图所示，假设localhost8083服务出现故障挂掉了，此时eureka-service中就会剔除localhost8083，这样出现故障的业务就不会被其他业务调用，避免了将错误扩大化。

三. Eureka注册中心的作用：

四. 搭建Eureka注册中心

上面理论讲解完毕，下面我们开始进行实战，实际操作配置EurekaServer服务端，搭建EurekaServer分为三步

4.1 第一步：我们要创建一个微服务项目，引入EurekaServer依赖，依赖如下：

<!--eureka服务端-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

4.2 第二步：要在启动类上添加 @EnableEurekaServer 注解，开启Eureka注册中心功能，如下所示：

4.3 第三步：要在EurekaServer模块中编写application.yml文件，编写如下配置：

server:
  port: 10086 # 服务端口
spring:
  application:
    name: eurekaserver # eureka的服务名称
eureka:
  client:
    service-url:  # eureka的地址信息
      defaultZone: http://localhost:10086/eureka

这里简单说一下配置是干什么的，

server.port 是配置Eureka的服务端门口；

spring.application.name 是给我们的这个模块的微服务起名称；

eureka.client.service-url 要配置我们的Eureka信息，因为Eureka本身也是微服务的一部分，所以要把自己也注册到微服务中去，这里我只写了一个Eureka，但实际上我们会建立一个Eureka集群，然后集群之间互相注册。

完成上述三步，我们即可启动，启动成功如下所示：

在ider中，当启动成功之后，我们点击左侧EurekaServer后面的端口10086，或者在自己的浏览器网址输入localhost:10086,即可跳转至对应页面，我们点进去看一下

可以有一部分人会看不懂啊，这里只看我红线圈出来的部分即可，那句英语翻译过来就是“注册到EurekaServer”的实例。

这里可能会有人有疑问，什么是实例，一个服务，每给它部署一个，它就是一个实例，EurekaServer会记录所有的实例，但现在我们只部署了一个EurekaServer，没有部署别的实例，所以上面显示只有一个实例，如上图中所示

Application就是服务的实例名称。

Status就是服务的IP地址和端口。

五. Eureka注册中心实现服务注册

OK，上面我们已经将EurekaServer配置完成，接下来我们实现服务注册，关于服务配置，只需要两步就够了。刚才我们配置EurekaServer引入的依赖是EurekaServer的服务端，接下来我们注册需要引入EurekaServer的客户端，引入的依赖与刚才略有差别，各位小伙伴要注意

5.1 第一步：引入EurekaServer客户端依赖

<!--eureka客户端依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

5.2 第二步：仍然是在我们对应业务模块中编写application.yml文件

内容如下所示：

spring:
  application:
    name: userservice
eureka:
  client:
    service-url:  # eureka的地址信息
      defaultZone: http://127.0.0.1:10086/eureka

配置成功如图所示：

打开自己电脑的浏览器输入localhost:10086查看，我们可以得到如下图片中的情况：

可以看到，user-service和eureka-service已经启动成功了。

同理，我们也可以按照同样的方法启动order-service

第一步：向order-service项目中添加依赖

<!--eureka客户端依赖-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

第二步：编写order-service业务模块的application.yml文件，这里我就不展示了。

完成上述两步之后，启动order-service模块，打开浏览器输入localhost:10086查看，得到如下结果

可以看到，order-service模块和user-service模块都已经启动成功了。

但这里大家要注意，其实每个模块的服务实力都是一个列表，正常情况下都不止一个，但我这里只列举了一个，那么我也来试着展示一下列表的情况吧！

很简单，我们来看，只需要在已经启动某个模块上单击右键，点击复制配置，这里我下载了中文补丁，正常情况下为 Copy Configuration

点击了 Copy Configuration 之后,就会出现下面这个框框、

这里修改一下名称，不要和刚才的一样避免冲突，还有一个需要修改的就是虚拟机选项

这里填写为 -Dserver.port=8082，被复制的模块端口号为8081，所以新复制的不能与被复制的端口号一样，否则会端口冲突，这里需要修改，我修改的是8082，其实改成什么都可以，只要是一个空闲端口。

修改后如下图所示：

点击应用，点击确认，然后启动这个复制的模块，打开浏览器输入localhost:10086，即可看到下图种情况：

这时我们可以清楚的看到，USERSERVICE后面是两个端口，分别是8081和8082。

六. Eureka是AP还是CP？

6.1 什么是CAP？

CAP原则又称CAP定理，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。

6.2 CAP相关理论

CAP 原则指示3个要素最多只能同时实现两点，不可能三者兼顾，由于网络硬件肯定会出现延迟丢包等问题，但是在分布式系统中，我们必须保证部分网络通信问题不会导致整个服务器集群瘫痪，另外即使分成了多个区，当网络故障消除的时候，我们依然可以保证数据一致性，所以我们必须保证分区容错性。

至于剩下的一致性和可用性，我们需要二选一，但是鱼和熊掌不可兼得，假设我们选择一致性，那我们就不能让用户访问无法进行数据同步的机器，毕竟该机器上的数据和其他正常机器上的不一致，但是这样我们就丢弃了可用性；假设我们选择可用性，那我们就可以让用户访问无法进行数据同步的服务器，虽然保证了可用性，但是我们无法保证数据一致性。

6.3 什么是AP？什么是CP？

违背了一致性C的要求，只满足可用性和分区容错，即AP；

违背了可用性A的要求，只满足一致性和分区容错，即CP；

6.4 Eureka是AP。

Eureka在设计时就优先保证可用性。Eureka的AP结构选择了高可用和分区容错性。假如我们Eureka服务中某个节点服务宕机了，依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。Eureka就是一个AP架构的例子，当Eureka客户端心跳消失的时候，那Eureka服务端就会启动自我保护机制，不会剔除该EurekaClient客户端的服务，依然可以提供需求；所以Eureka是AP机制。

6.5 Eureka是如何保证AP的？

eureka在设计时的分区容错保证了eureka各个节点都是平等的，只要不是所有节点都挂掉eureka就可以正常注册与使用，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。

6.6 什么是Eureka的自我保护模式？

eureka server自我保护模式指的是如服务长时间没有收到心跳导致未能及时续约会等待修复，而不是服务剔除，是一种针对网络异常波动的安全措施，能够保证服务的高可用。自我保护模式情况下如果该服务长时间未能收到心跳而导致服务过期，eureka server仍然能够接收新的服务注册和查询，但不会同步到其他节点上，当前节点依然可用，网络稳定后新注册的信息会被同步到其他节点中。