Eureka中的核心概念

　　本文是Spring Cloud系列的第四篇，前面三篇文章(使用Spring Cloud搭建服务注册中心、使用Spring Cloud搭建高可用服务注册中心、Spring Cloud中服务的发现与消费)咱们带你们搭建了服务注册中心，向服务注册中心注册了服务，同时也发现和消费了服务。前面的文章咱们是以实际代码操做为主，这篇文章我想对前面三篇文章中涉及到的一些知识点再进行详细的梳理，对于一些前面未涉及到的配置再作进一步的说明。
　　
　　首先，经过前面三篇文章的学习，小伙伴们已经发现了Eureka服务治理体系中涉及到三个核心概念：服务注册中心、服务提供者以及服务消费者，本文将从这三个方面来对Eureka服务治理体系进行一个详细的说明。
　　
　　服务提供者服务治理体系支持跨平台，虽然咱们前文使用了Spring Boot来做为服务提供者，可是对于其余技术平台只要支持通讯机制，同样也是能够做为服务提供者，换句话说，服务提供者既能够是Java写的，也能够是python写的，也能够是js写的。这些服务提供者将本身注册到上，供其它应用发现而后调用，这就是咱们的服务提供者，服务提供者主要有以下一些功能：服务注册服务提供者在启动的时候会经过发送REST请求将本身注册到Eureka Server上，同时还携带了自身服务的一些元数据信息。Eureka Server在接收到这个REST请求以后，将元数据信息存储在一个双层结构的Map集合中，第一层的key是服务名，第二层的key是具体服务的实例名，咱们在上篇文章最后展现出来的截图中，你们也能够看出一些端倪，以下：同时，咱们在服务注册时，须要确认一下eureka.client.register-with-eureka=true配置是否正确，该值默认就为true，表示启动注册操做，若是设置为false则不会启动注册操做。
　　
　　服务同步再说服务同步以前，我先描述一个场景：首先我有两个服务注册中心，地址分别是http://www.yunduanpingtai.cn  而后我还有两个服务提供者，地址分别是http://localhost:8080和http://localhost:8081，而后我将8080这个服务提供者注册到1111这个注册中心上去，将8081这个服务提供者注册到1112这个注册中心上去，此时我在服务消费者中若是只向1111这个注册中心去查找服务提供者，那么是否是只能获取到8080这个服务而获取不到8081这个服务？你们看下面一张图：答案是服务消费者能够获取到两个服务提供者提供的服务。虽然两个服务提供者的信息分别被两个服务注册中心所维护，可是因为服务注册中心之间也互相注册为服务，当服务提供者发送请求到一个服务注册中心时，它会将该请求转发给集群中相连的其余注册中心，从而实现注册中心之间的服务同步，经过服务同步，两个服务提供者的服务信息咱们就能够经过任意一台注册中心来获取到。OK，下面咱们来经过一个简单的案例来验证一下咱们上面的理论：工程咱们前面已经分别建立了application-peer1.properties和application-peer2.properties配置文件，以下：而后咱们经过下面两行命令来启动两个服务注册中心实例，以下：而后咱们给provider工程也建立两个配置文件，分别为application-p1.properties和application-p2.properties，内容以下：而后经过以下命令启动两个服务提供者的实例，以下：OK,咱们将8080这个服务注册到1111这个服务注册中心上去了，将8081这个服务注册到1112这个服务注册中心上去了。当两个服务提供者都启动成功以后，咱们来看看两个服务注册中心的控制面板，以下：  、最后咱们再来看看ribbon-consumer的配置文件，以下：你们看到，咱们运行消费端时只向1111那个服务注册中心去获取服务列表，可是在实际运行过程当中8080和8081两个服务提供者都有响应咱们的请求，以下图：上面的日志是8081打印的，下面的日志是8080打印的，没毛病。
　　
　　服务续约在注册完服务以后，服务提供者会维护一个心跳来不停的告诉Eureka Server：“我还在运行”，以防止Eureka Server将该服务实例从服务列表中剔除，这个动做称之为服务续约，和服务续约相关的属性有两个，以下：第一个配置用来定义服务失效时间，默认为90秒，第二个用来定义服务续约的间隔时间，默认为30秒。
　　
　　服务消费者消费者主要是从服务注册中心获取服务列表，拿到服务提供者的列表以后，服务消费者就知道去哪里调用它所须要的服务了，咱们从下面几点来进一步了解下服务消费者。
　　
　　获取服务当咱们启动服务消费者的时候，它会发送一个REST请求给服务注册中心来获取服务注册中心上面的服务提供者列表，而Eureka Server上则会维护一份只读的服务清单来返回给客户端，这个服务清单并非实时数据，而是一份缓存数据，默认30秒更新一次，若是想要修改清单更新的时间间隔，能够经过eureka.client.registry-fetch-interval-seconds=30来修改，单位为秒(注意这个修改是在eureka-server上来修改)。另外一方面，咱们的服务消费端要确保具备获取服务提供者的能力，此时要确保eureka.client.fetch-registry=true这个配置为true。
　　
　　服务调用服务消费者从服务注册中心拿到服务提供者列表以后，经过服务名就能够获取具体提供服务的实例名和该实例的元数据信息，客户端将根据这些信息来决定调用哪一个实例，咱们以前采用了Ribbon，www.rbuluoyl.cn/ Ribbon中默认采用轮询的方式去调用服务提供者，进而实现了客户端的负载均衡。
　　
　　服务下线服务提供者在运行的过程当中可能会发生关闭或者重启，当服务进行正常关闭时，它会触发一个服务下线的REST请求给Eureka Server，告诉服务注册中心我要下线了，服务注册中心收到请求以后，将该服务状态置为DOWN，表示服务已下线，并将该事件传播出去，这样就能够避免服务消费者调用了一个已经下线的服务提供者了。
　　
　　服务注册中心服务注册中心就是Eureka提供的服务端，它提供了服务注册与发现功能。
　　
　　失效剔除上面咱们说到了服务下线问题，正常的服务下线发生流程有一个前提那就是服务正常关闭,可是在实际运行中服务有可能没有正常关闭，好比系统故障、网络故障等缘由致使服务提供者非正常下线，那么这个时候对于已经下线的服务Eureka采用了定时清除：Eureka Server在启动的时候会建立一个定时任务，每隔60秒就去将当前服务提供者列表中超过90秒还没续约的服务剔除出去，经过这种方式来避免服务消费者调用了一个无效的服务。
　　
　　自我保护咱们在前三篇文章中给你们看的截图上，都有这样一个警告，以下图：这个警告实际上就是触发了Eureka Server的自我保护机制。Eureka Server在运行期间会去统计心跳失败比例在15分钟以内是否低于85%，若是低于85%，Eureka Server会将这些实例保护起来，让这些实例不会过时，可是在保护期内若是服务恰好这个服务提供者非正常下线了，此时服务消费者就会拿到一个无效的服务实例，此时会调用失败，对于这个问题须要服务消费者端要有一些容错机制，如重试，断路器等。咱们在单机测试的时候很容易知足心跳失败比例在15分钟以内低于85%，这个时候就会触发Eureka的保护机制，一旦开启了保护机制，则服务注册中心维护的服务实例就不是那么准确了，此时咱们能够使用eureka.server.enable-self-preservation=false来关闭保护机制，这样能够确保注册中心中不可用的实例被及时的剔除。
　　
　　OK，以上就是咱们对Eureka www.zzktv.cn中服务注册中心、服务提供者、服务消费者三个核心概念的一些理解，有问题欢迎留言讨论。
　　
　　更多JavaEE资料请关注公众号