那些年,想和你一起认识的SpringCloud Eureka

2019-08-16 11:26:37来源:博客园 阅读 ()

新老客户大回馈,云服务器低至5折

那些年,想和你一起认识的SpringCloud Eureka

  前几天鲁班LB跟我说:你玩把游戏都要半个钟啦,为何不用这时间来看看书,如果涨工资还可以帮我买个皮肤。

  面对如此合理的这需求,但我不以为然,事实上并不是我不想学习,而是 ↓ 

  

  实力不允许呀~

  直到有一天,突然被叫到会议室,心里疙瘩一下,这难道?项目出严重Bug了,冷静的我思索片刻后,很快就会否定了这种想法,结果巴拉巴拉2小时后,结论竟然是说:“现在我们这个项目要求重构,需用使用微服务架构,所以不了解相关技术的同事请利用这段时间学习复习一下,下个月要开始进入开发阶段。

  呵呵,会议上,总是有人把微服务吹的很厉害似的,我笑而不语,于是

  

  一周后

  

  

   以下是我的笔记,我一般是带着问题去学习,有了需求,或者说是好奇心,因为这样学习的效率会更高

  当看到我们架构中有Eureka,我的第一个问题自然就是:做微服务为什么要使用Eureka,或者Eureka能够帮助我们解决什么样的问题?

  对于微服务的概念有经验的开发人员的一般都听说过吧,无非就是把大应用拆分为小应用,然后处理好服务的相互通讯即可,但是如果光启动微服务时,不启动eureka,其他微服务也是可以通过Nginx反向代理,用rest的方式从不同服务后台获取到数据(HTTP直怼),那多个eureka服务岂不是多此一举吗?细想一下其实并不是的,我觉得原因有如下:

  其一:

  如果后端微服务之间,有互相通信,那么在负载均衡时,相同的服务肯定会启动多个,而且使用不同的端口,这个时候,服务之间就可以通过注册在eureka中的名称来找到对方,而不是根据IP+端口号去找对方。反之如果后端微服务之间相互通信,都要知道具体的IP和端口,那开发起来十分麻烦,而IP地址也并不是固定不变的,除非使用域名封装,所以无论是测试还是开发还是上线都存在问题。

  其二:

  Eureka注册中心的作用很大的程度是作用于服务发现和服务心跳,在多个注册中心的时候,依赖于zuul的负载均衡,保证异常的服务停止,正常的服务加载,保证服务的稳定性。

  新手可能不理解这说的是什么意思,没关系,请往下看,首先我们先说说什么是SpringCloud

  SpringCloud是一系列框架的有序集合。它利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、 熔断器、数据监控等,都可以用SpringBoot的开发风格做到一键启动和部署。是一套简单易懂、易部署和易维护的分布式系统开发工具包。

  主要组成如下:

  •   服务发现——Netflix Eureka                      服务调用——Netflix Feign
  •   熔断器——Netflix Hystrix                          服务网关——Netflix Zuul
  •   分布式配置——Spring Cloud Config         消息总线 —— Spring Cloud Bus

  

  本文主要介绍Eureka注册中心

  组成原理:

  Eureka包含两个组件: Eureka Server和Eureka Client:

  Eureka Server提供服务注册服务,各个Client节点启动后,会在Eureka Server中进行注册,这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息,服务节点的信息可以在界面中直观的看到。

  Eureka Client是一个java客户端,用于简化与Eureka Server的交互,客户端有一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后,将会向Eureka Server发送心跳,默认周期为30秒,如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳,Eureka Server将会从服务注册表中把这个服务节点移除(默认90 秒)。如果Eureka Server做了集群,Eureka Server之间通过复制的方式完成数据的同步,同时Eureka还提供了客户端缓存机制,即使所有的Eureka Server都挂掉,客户端依然可以利用缓存中的信息消费其他服务的API。

  综上,Eureka能够通过心跳检查、客户端缓存等机制,确保了系统的高可用性。

 

  问题:同为注册中心,Eureka要比Zookeeper好在哪,或者说为什么Cloud为什么不集成Zookeeper,在CAP理论中说道,一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的,因此我们只能在A和C之间进行权衡。我们从需求出发考虑,当向注册中心查询服务列表时,我们可以容忍注册中心返回的是几分钟以前的注册信息,但不能接受服务直接down掉不可用。也就是说,对于服务注册功能对可用性的要求要高于一致性。

  Eureka不会出现这种问题,Zookeeper则会出现这样一种情况,当master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行leader选举。选举leader的时间太长,30 ~ 120s, 且选举期间整个zk集群都是不可用的,这就导致在选举期间注册服务瘫痪。在云部署的环境下,因网络问题使得zk集群失去master节点是较大概率会发生的事,虽然服务能够最终恢复,但是漫长的选举时间导致的注册长期不可用是不能容忍的。

  而在此Zookeeper保证的是CP, 而Eureka则是AP,显然Eureka更加合适。

  但在默认配置中,Eureka Server在默认90s没有得到客户端的心跳,则注销该实例,但是往往因为微服务跨进程调用,网络通信往往会面临着各种问题,比如微服务状态正常,但是因为网络分区故障时,Eureka Server注销服务实例则会让大部分微服务不可用,这很危险,因为服务明明没有问题。为了解决这个问题,Eureka 有自我保护机制,通过在Eureka Server配置参数,可启动保护机制它的工作原理是:当Eureka Server节点在短时间内丢失过多的客户端时(可能发送了网络故障),那么这个节点将进入自我保护模式,不再注销任何微服务,当网络故障回复后,该节点会自动退出自我保护模式。

  实战:

  Eureka服务端开发(非常简单的3步完成)

  1.从官网下载脚手架项目https://start.spring.io/

  2.修改一下配置文件

  3.启动,本质上也是一个SpringBoot项目

  

 

   把下载好的Demo导入编译器,打开application.properties或 .yml配置文件

  

#配置端口
server:
    port: 8761  #服务端口
#配置服务名称
spring:
  application:
    name: service-name #是否将自己注册到Eureka服务中,本身就是服务端,所以无需注册
#是否从Eureka中获取注册信息
#客户端和服务端交互地址 eureka: client: registerWithEureka:
false fetchRegistry: false serviceUrl: defaultZone: http://127.0.0.1:${server.port}/eureka/

  配置启动类

@SpringBootApplication
//加入注解,声明为服务端 @EnableEurekaServer
public class EurekaServer { public static void main(String[] args) { SpringApplication.run(EurekaServer.class, args); } }

 

  上图为Eureka服务端启动成功,可视化界面,Application表示当前并无客户端用户注册进来,这里说的客户端就是我们开发的微服务应用

 

  Eureka客户端开发(其实就是我们真正业务微服务应用)

  1.从官网下载脚手架项目https://start.spring.io/

  2.修改一下配置文件

 

#配置端口
server:
  port:1111
#配置服务名称
spring:
  application:
    name : client-name
#配置服务器路径
eureka: client: service‐url: defaultZone: http:
//localhost:8761/eureka instance: prefer‐ip‐address: true

  启动类配置

//加入注解,声明为微服务客户端,项目启动后自动向服务端注册
@EnableDiscoveryClient @SpringBootApplication
public class ServiceProviderApplication { public static void main(String[] args) { SpringApplication.run(ServiceProviderApplication.class, args); } }

  启动后就能在服务端可视化界面看见客户端的注册信息,我们现在就将所有的微服务都注册到Eureka中,这样所有的微服务之间都可以互相调用,服务的调用将在下一篇文章详细讲解

   

  但是有时候会出现下面的文字

  

  说明Eureka已经进入了保护模式:

  Eureka Server在运行期间,会统计心跳失败的比例在15分钟之内是否低于85%,如果出现低于的情况(在生产环境上通常是由于网络不稳定导致),Eureka Server会将当前的实例注册信息保护起来,同时提示这个警告。保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保 护模式,Eureka Server将会尝试保护其服务注册表中的信息,不会注销任何微服务。

  

  关于Eureka Server集群的介绍

  Eureka注册中心只部署在一台机器上,一旦出现问题,会导致整个服务调用系统的崩溃,针对这种情况,我们需要部署两台Eureka注册中心,彼此相互注册,组成一个高可用的的Eureka集群。这样一来,每台服务器都包含着对方的服务注册信息,相当于双机热备,同时,服务提供者只需向其中的一个注册服务。

   在生产环境中,一般是把两个相互注册的服务器安装在两台服务器上,现在我们在一台机器上模拟双服务器的场景,具体的实现步骤如下:

  到C:\WINDOWS\system32\drivers\etc目录里,找到hosts文件,在其中加入两个机器名(其实都是指向本机),代码如下。修改后,需要重启机器。

          127.0.0.1      erueka-server

          127.0.0.1      erueka-server2

  配置如下

Eureka service

server:
        port: 8761 #端口号
spring:
  application:
    name: eureka-server #应用名
eureka: instance: hostname: hostname1 client: register
-with-eureka: true fetch-registry: true service-url: defaultZone: http://hostname1:8761/eureka/,http://hostname2:8762/eureka/

Eureka service2

server:
        port: 8762 #端口号
spring:
  application:
    name: eureka-server2 #应用名

eureka:
        instance:
              hostname: hostname2
         client:
            register-with-eureka: true
            fetch-registry: true
            service-url:
                defaultZone: http://hostname1:8761/eureka/,http://hostname2:8762/eureka/  

  这样下来,就算有一台机器死机了,然后可让服务正常工作。

 


原文链接:https://www.cnblogs.com/zhuoqingsen/p/Eureka.html
如有疑问请与原作者联系

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:Java入门 面向对象第一天

下一篇:Java学习第五天