SpringCloud（⼀）之微服务核⼼组件Eureka（注册中⼼）的介
绍和使⽤
⼀ Eureka服务治理体系
1.1 服务治理
服务治理是微服务架构中最为核⼼和基础的模块，它主要⽤来实现各个微服务实例的⾃动化注册和发现。
Spring Cloud Eureka是Spring Cloud Netflix微服务套件中的⼀部分，它基于Netflix Eureka做了⼆次封装。主要负责完成微服务架构中的服务治理功能。
Eureka服务治理体系如下：
1.2 服务注册
在服务治理框架中，通常都会构建⼀个注册中⼼，每个服务单元向注册中⼼登记⾃⼰提供的服务，包括服务的主机与端⼝号、服务版本号、通讯协议等⼀些附加信息。注册中⼼按照服务名分类组织服务清单，同时还需要以⼼跳检测的⽅式去监测清单中的服务是否可⽤，若不可⽤需要从服务清单中剔除，以达到排除故障服务的效果。
1.3 服务发现
在服务治理框架下，服务间的调⽤不再通过指定具体的实例地址来实现，⽽是通过服务名发起请求调⽤实现。服务调⽤⽅通过服务名从服务注册中⼼的服务清单中获取服务实例的列表清单，通过指定的负载均衡策略取出⼀个服务实例位置来进⾏服务调⽤。
⼆ Netflix Eureka
2.1 Netflix Eureka介绍
Spirng Cloud Eureka使⽤Netflix Eureka来实现服务注册与发现。它既包含了服务端组件，也包含了客户端组件，并且服务端与客户端均采⽤java编写，所以Eureka主要适⽤于通过java实现的分布式系统，或是JVM兼容语⾔构建的系统。Eureka的服务端提供了较为完善的REST API，所以Eureka也⽀持将⾮java语⾔实现的服务纳⼊到Eureka服务治理体系中来，只需要其他语⾔平台⾃⼰实现Eureka的客户端程序。⽬前.Net平台的Steeltoe、Node.js的eureka-js-client等都已经实现了各⾃平台的Ereka客户端组件。
2.2 Eureka服务端
Eureka服务端，即服务注册中⼼。它同其他服务注册中⼼⼀样，⽀持⾼可⽤配置。依托于强⼀致性提供良好的服务实例可⽤性，可以应对多种不同的故障场景。
Eureka服务端⽀持集模式部署，当集中有分⽚发⽣故障的时候，Eureka会⾃动转⼊⾃我保护模式。它允许在分⽚发⽣故障的时候继续提供服务的发现和注册，当故障分配恢复时，集中的其他分⽚会把他们的状态再次同步回来。集中的的不同服务注册中⼼通过异步模式互相复制各⾃的状态，这也意味着在给定的时间点每个实例关于所有服务的状态可能存在不⼀致的现象。
2.3 Eureka客户端
Eureka客户端，主要处理服务的注册和发现。客户端服务通过注册和参数配置的⽅式，嵌⼊在客户端应⽤程序的代码中。在应⽤程序启动时，Eureka客户端向服务注册中⼼注册⾃⾝提供的服务，并周期性的发送⼼跳来更新它的服务租约。同时，他也能从服务端查询当前注册的服务信息并把它们缓存到本地并周期⾏的刷新服务状态。
三服务注册中⼼
3.1 服务注册中⼼功能概述
在服务治理框架中，通常都会构建⼀个注册中⼼，每个服务单元向注册中⼼登记⾃⼰提供的服务，包括服务的主机与端⼝号、服务版本号、通讯协议等⼀些附加信息。注册中⼼按照服务名分类组织服务清单，同时还需要以⼼跳检测的⽅式去监测清单中的服务是否可⽤，若不可⽤需要从服务清单中剔除，以达到排除故障服务的效果。
3.2 创建Eureka Server服务
  3.2.1 可以通过Idea 创建项⽬时直接勾选
　3.2.2 可以导⼊依赖
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>    </dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
</dependencies>
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-dependencies</artifactId>
<version>${spring-cloud.version}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
</dependencies>
</dependencyManagement>
3.3 Eureka Server相关配置
#服务注册中⼼端⼝号
server:
port: 8761
#服务注册中⼼实例的主机名
eureka:
instance:
hostname: localhost
client:
#是否向服务注册中⼼注册⾃⼰
registerWithEureka: false
#是否检索服务
fetchRegistry: false
serviceUrl:
#服务注册中⼼的配置内容，指定服务注册中⼼的位置
defaultZone: ${eureka.instance.hostname}:${server.port}/eureka/ 3.4 启动服务注册中⼼
@SpringBootApplication
/
/启动Eureka服务注册中⼼
@EnableEurekaServer
public class EurekaServerApplication {
public static void main(String[] args) {
SpringApplication.run(EurekaServerApplication.class, args);
}
}
3.5 Eureka可视化界⾯
3.5 ⾼可⽤服务注册中⼼
3.5.1 ⾼可⽤服务注册中⼼的概念
考虑到发⽣故障的情况，服务注册中⼼发⽣故障必将会造成整个系统的瘫痪，因此需要保证服务注册中⼼的⾼可⽤。
Eureka Server在设计的时候就考虑了⾼可⽤设计，在Eureka服务治理设计中，所有节点既是服务的提供⽅，也是服务的消费⽅，服务注册中⼼也不例外。
Eureka Server的⾼可⽤实际上就是将⾃⼰做为服务向其他服务注册中⼼注册⾃⼰，这样就可以形成⼀组互相注册的服务注册中⼼，以实现服务清单的互相同步，达到⾼可⽤的效果。
3.5.2 构建服务注册中⼼集
Eureka Server的同步遵循着⼀个⾮常简单的原则：只要有⼀条边将节点连接，就可以进⾏信息传播与同步。可以采⽤两两注册的⽅式实现集中节点完全对等的效果，实现最⾼可⽤性集，任何⼀台注册中⼼故障都不会影响服务的注册与发现
（1）创建application-peer1.properties
server.port=1111
springcloud和springbooteureka.instance.hostname=master
ister-with-eureka=false
eureka.client.fetch-registry=false
eureka.instance.preferIpAddress=true
ableSelfPreservation=false
（2）创建application-peer2.properties
server.port=1112
eureka.instance.hostname=backup1
ister-with-eureka=false
eureka.client.fetch-registry=false
eureka.instance.preferIpAddress=true
ableSelfPreservation=false
（3）创建application-peer3.properties
server.port=1113
eureka.instance.hostname=backup2
ister-with-eureka=false
eureka.client.fetch-registry=false
eureka.instance.preferIpAddress=true
ableSelfPreservation=false
(4) 在hosts⽂件中增加如下配置
127.0.0.1 master
127.0.0.1 backup1
127.0.0.1 backup2
3.6 失效剔除
有些时候，我们的服务实例并不⼀定会正常下线，可能由于内存溢出、⽹络故障等原因使服务不能正常
运作。⽽服务注册中⼼并未收到“服务下线”的请求，为了从服务列表中将这些⽆法提供服务的实例剔除，Eureka Server在启动的时候会创建⼀个定时任务，默认每隔⼀段时间（默认为60秒）将当前清单中超时（默认为90秒）没有续约的服务剔除出去。
3.7 ⾃我保护
服务注册到Eureka Server后，会维护⼀个⼼跳连接，告诉Eureka Server⾃⼰还活着。Eureka Server在运⾏期间会统计⼼跳失败的⽐例在15分钟以之内是否低于85%，如果出现低于的情况，Eureka Server会将当前实例注册信息保护起来，让这些实例不会过期。这样做会使客户端很容易拿到实际已经不存在的服务实例，会出现调⽤失败的情况。因此客户端要有容错机制，⽐如请求重试、断路器。
以下是⾃我保护相关的属性：
ableSelfPreservation=true. 可以设置改参数值为false，以确保注册中⼼将不可⽤的实例删除
3.8 region（地域）与zone（可⽤区）
region和zone（或者Availability Zone）均是AWS的概念。在⾮AWS环境下，我们可以简单地将region理解为地域，zone理解成机房。⼀个region可以包含多个zone，可以理解为⼀个地域内的多个不同的机
房。不同地域的距离很远，⼀个地域的不同zone间距离往往较近，也可能在同⼀个机房内。
region可以通过配置⽂件进⾏配置，如果不配置，会默认使⽤us-east-1。同样Zone也可以配置，如果不配置，会默认使⽤defaultZone。Eureka Server通过eureka.client.serviceUrl.defaultZone属性设置Eureka的服务注册中⼼的位置。
指定region和zone的属性如下：
（1）eureka.ion=myzone# myregion是region
（2）ion=myregion
Ribbon的默认策略会优先访问通客户端处于同⼀个region中的服务端实例，只有当同⼀个zone中没有可⽤服务端实例的时候才会访问其他zone中的实例。所以通过zone属性的定义，配合实际部署的物理结构，我们就可以设计出应对区域性故障的容错集。
（1）pom⽂件中引⼊依赖
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-security</artifactId>
</dependency>
（2）serviceurl中加⼊安全校验信息
四服务提供者
4.1 服务注册
服务提供者在启动的时候会通过REST请求的⽅式将⾃⼰注册到Eureka Server上，同时带上⾃⾝服务的⼀些元数据信息。Eureka Server接收到这个Rest请求之后，将元数据信息存储在⼀个双层结构的Map中，其中第⼀层的key是服务名。第⼆层的key 是具体服务的实例名。
在服务注册时，需要确认⼀下ister-with-eureka=true参数是否正确，该值默认为true。若设置为fasle将不会启动注册操作。
4.2 服务同步
从eureka服务治理体系架构图中可以看到，不同的服务提供者可以注册在不同的服务注册中⼼上，它们的信息被不同的服务注册中⼼维护。
此时，由于多个服务注册中⼼互相注册为服务，当服务提供者发送注册请求到⼀个服务注册中⼼时，它会将该请求转发给集中相连的其他注册中⼼，从⽽实现服务注册中⼼之间的服务同步。通过服务同步，提供者的服务信息就可以通过集中的任意⼀个服务注册中⼼获得。
4.3 服务续约
在注册服务之后，服务提供者会维护⼀个⼼跳⽤来持续⾼速Eureka Server，“我还在持续提供服务”，否则Eureka Server的剔除任务会将该服务实例从服务列表中排除出去。我们称之为服务续约。
下⾯是服务续约的两个重要属性：
（1）eureka.instance.lease-expiration-duration-in-seconds
leaseExpirationDurationInSeconds，表⽰eureka server⾄上⼀次收到client的⼼跳之后，等待下⼀次⼼跳的超时时间，在这个时间内若没收到下⼀次⼼跳，则将移除该instance。
默认为90秒
如果该值太⼤，则很可能将流量转发过去的时候，该instance已经不存活了。
如果该值设置太⼩了，则instance则很可能因为临时的⽹络抖动⽽被摘除掉。
该值⾄少应该⼤于leaseRenewalIntervalInSeconds
（2）eureka.instance.lease-renewal-interval-in-seconds
leaseRenewalIntervalInSeconds，表⽰eureka client发送⼼跳给server端的频率。如果在leaseExpirationDurationInSeconds后，server端没有收到client的⼼跳，则将摘除该instance。除此之外，如果该instance实现了HealthCheckCallback，并决定让⾃⼰unavailable的话，则该instance也不会接收到流量。
默认30秒
4.4 创建并注册服务提供者
4.4.1 创建Eureka客户端服务

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。