本篇主要介绍Spring cloud中Eureka组件的相关内容
目录
一、什么是Eureka
在了解什么是eureka之前,我们先来了解一下什么是注册中心。在前面的篇章中,我们知道了微服务是将一个完整的系统,拆分为多个微小的服务,并将这些服务各自单独部署到一台主机上,并且这些服务之间能够进行相互调用,并且在进行服务调用时,我们需要先去获取其它服务的地址才能够进行调用。对于这些地址,我们如果将其一个一个记录起来,用的时候再去找,这就会显得十分麻烦,并且服务的地址如果发生了改变,其它服务是不知道的。此时就需要使用到一个三方组件,当一个服务启动时,会去访问这个组件,并将自己的地址存放到这个第三方组件中,这个存放地址的过程就称为服务注册,如果需要去调用一个服务,则还是去这个组件中拿对应的地址,这个去拿地址的过程就称为服务发现。这样的组件就称为注册中心。而Eureka就是一个由Netfix提供,并整合到Spring cloud中的一个注册中心。
二、搭建和使用Eureka
Eureka通常包含两个部分,一个是Eureka Server,作为Eureka的服务端,向各微服务提供服务发现,服务注册,健康检查等功能,另一个是Eureka cilent,服务提供者(需要注册到Eureka的服务),启动时会向Eureka服务端提供自己的地址信息。
Eureka Server
我们先来了解一下Eureka服务端的使用。
Eureka Server是一个独立的项目,因此,我们需要单独创建一个Maven项目来使用,创建完成之后,我们需要在项目文件中引入eureka server的相关依赖,具体如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
并且,我们还需要手动创建一个启动类,并在启动类上加上一个@EnableEurekaServer注解用来开启Eureka服务
完成这些之后我们还需要创建一个配置文件 ,并进行一些相关配置。配置的内容大体如下:
server:
port: 10010
spring:
application:
name: eureka-server
eureka:
instance:
hostname: 127.0.0.1
client:
fetch-registry: false # 表示是否从其它Eureka Server获取注册信息,默认为true.因为这是一个单点的Eureka Server,不需要同步其他的Eureka Server节点的数据,这里设置为false
register-with-eureka: false # 表示是否将自己注册到Eureka Server,默认为true.由于当前应用就是Eureka Server,故而设置为false.
service-url:
# 设置Eureka Server的地址,查询服务和注册服务都需要依赖这个地址
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
logging:
pattern:
console: '%d{MM-dd HH:mm:ss.SSS} %c %M %L [%thread] %m%n'
然后启动项目,访问eureka所在服务器ip的10010端口,如果出现以下界面,Eureka Server就搭建好了。
Eureka cilent
搭建Eureka cilent我们也需要引入对应的依赖,具体如下:
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency
然后我们还需要完成一些配置,具体为配置服务名称,以及Eureka Server的地址,具体如下:
配置完成 启动项目,当前服务就会被注册到Eureka server了。
我们可以在eureka server提供的网页中查看,当前所注册的服务信息,例如我们注册一个product-server,就可以看到对应的信息
服务发现
接下来,我们来了解一下如何来获取Eureka server中的服务信息。获取服务信息,我们需要使用到一个DisCoverCilen类,这个类可以直接进行注入。通过这个类提供的getInstances(需要获取的服务的名称)方法,我们可以获取到一个ServiceInstance的list,将ServiceInstance强转成EurekaServiceInstance,然后在调用其getUri()方法就能获取到对应服务的地址信息了,具体代码如下:
在这串代码中,我们去获取了前面注册到Eureka server 的product-server的相关信息,并去打印了其对应的地址信息了。我们来执行一下这串代码,
根据打印的日志可以发现,product-service的地址信息已经获取到了。
三、CAP理论
CAP理论是分布式系统设计中,最基础,最位关键的理论。在CAP理论中,CAP代表着不同的含义,具体如下:
- C(一致性):这里表示的是强制性,也就是说在 所有节点中,同一时间的数据是一样的。
- A(可用性):保证每次请求都能有响应。
- P(分区容错性):出现网络分区,系统仍然能够对外服务(即使一个服务挂了,其它节点也能提供对应的服务)。
通常情况下,C,A,P,不可能同时满足,因为在满足P时,只能在C,A中选一个,也就是只能是CP或者AP,我们通过下面的例子来理解一下。
当一个节点处理完一个请求后,需要向其它节点同步数据,如果此时与其中一个节点之间的网络出现了故障,同步就会失败,此时,如果继续去尝试同步数据,就会导致没有数据返回,也就是使可用性不满足了,如果直接返回数据,那么各节点之间的数据就会有差异,从而使一致性不满足了。所以在满足分区容错性时,一致性,和可用性只能满足其一。
在常见的注册中心组件中,不同的组件在一致性和可用性的取舍上有所不同,例如Zookeeper保证了一致性,而Eureka则是保证了可用性,Nacos则是可以选择保证一致性或者保证可用性,默认是保证可用性。