Eureka工作流程

Eureka工作流程,第1张

是Netflix开发的服务发现框架,本身是一个基于REST的服务,主要用于定位运行在AWS域中的中间层服务,以达到负载均衡和中间层服务故障转移的目的。

注册中心服务端主要对外提供了三个功能:

服务提供者启动时,会通过 Eureka Client 向 Eureka Server 注册信息,Eureka Server 会存储该服务的信息,Eureka Server 内部有二层缓存机制来维护整个注册表

服务消费者在调用服务时,如果 Eureka Client 没有缓存注册表的话,会从 Eureka Server 获取最新的注册表

Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。

Eureka Client 是一个 Java 客户端,用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉,服务消费者依然可以使用缓存中的信息找到服务提供者,但是当服务有更改的时候会出现信息不一致。

服务的提供者,将自身注册到注册中心,服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时,它提供自身的元数据,比如 IP 地址、端口,运行状况指示符 URL,主页等。

Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常,没有出现问题。 默认情况下,如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约,Server 端会将实例从其注册表中删除。

当服务进行正常关闭 *** 作时,它会触发一个服务下线的REST请求给Eureka Server,告诉服务注册中心:“我要下线 了”。服务中心接受到请求之后,将该服务置为下线状态

有时我们的服务可能由于内存溢出或网络故障等原因使得服务不能正常的工作,而服务注册中心并未收到“服务下线”的请求。相对于服务提供者的“服务续约” *** 作,服务注册中心在启动时会创建一个定时任务,默认每隔一段时间 (默认为60秒)将当前清单中超时(默认为90秒)没有续约的服务剔除,这个 *** 作被称为失效剔除。 可以通过 eurekaservereviction-interval-timer-in-ms 参数对其进行修改,单位是毫秒。

我们关停一个服务,在Eureka面板看到一条警告: 这是触发了Eureka的自我保护机制。
当一个服务未按时进行心跳续约时,Eureka会统计最近15分钟心跳失败的服 务实例的比例是否超过了85%,当EurekaServer节点在短时间内丢失过多客户端(可能发生了网络分区故障)。在 生产环境下,因为网络延迟等原因,心跳失败实例的比例很有可能超标,但是此时就把服务剔除列表并不妥当,因 为服务可能没有宕机。Eureka就会把当前实例的注册信息保护起来,不予剔除。生产环境下这很有效,保证了大多 数服务依然可用。

Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时,则认为是客户端的问题,剔除掉客户端;当 Eureka 捕获到大量的心跳失败时,则认为可能是网络问题,进入自我保护机制;当客户端心跳恢复时,Eureka 会自动退出自我保护机制。

如果在保护期内刚好这个服务提供者非正常下线了,此时服务消费者就会拿到一个无效的服务实例,即会调用失败。对于这个问题需要服务消费者端要有一些容错机制,如重试,断路器等。

了解完 Eureka 核心概念,自我保护机制,以及集群内的工作原理后,我们来整体梳理一下 Eureka 的工作流程:

1、Eureka Server 启动成功,等待服务端注册。在启动过程中如果配置了集群,集群之间定时通过 Replicate 同步注册表,每个 Eureka Server 都存在独立完整的服务注册表信息
2、Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务
3、Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求,证明客户端服务正常
4、当 Eureka Server 90s 内没有收到 Eureka Client 的心跳,注册中心则认为该节点失效,会注销该实例
5、单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳,则认为可能为网络异常,进入自我保护机制,不再剔除没有上送心跳的客户端
6、当 Eureka Client 心跳请求恢复正常之后,Eureka Server 自动退出自我保护模式
7、Eureka Client 定时全量或者增量从注册中心获取服务注册表,并且将获取到的信息缓存到本地
8、服务调用时,Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到,先从注册中心刷新注册表,再同步到本地缓存
9、Eureka Client 获取到目标服务器信息,发起服务调用
10、Eureka Client 程序关闭时向 Eureka Server 发送取消请求,Eureka Server 将实例从注册表中删除

参考链接: >一、服务注册中心的由来

假如没有服务注册中心,我们会干些什么事情呢?

在传统行业的项目架构中以下的方案最为常见了:

这种架构开发、部署都是最简单的,一般适用于中小企业访问量并不是太多的情况下,各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。

接下来可能因为应用B开始访问量大了,单台机器已经不能满足我们的需求,于是一些反向代理工具应运而出,其中比较常见的有Apache、Nigix,架构演变为:

相比之前的应用B的单台机器访问,这种nginx代理的方式减轻了服务器的压力,但是可能会出现Nginx挂了,那么整个服务也不可用,于是又来了这么一套架构:

这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺,这还只是应用A调用一个应用B,如果应用A调用的可能是应用B、C、D、E,这种完全就不知道他后面到底还想干嘛,这种架构看似可以,但是绝对会累死运维的(nginx的配置将会非常混乱,直接导致运维不干了)。

服务注册中心干些什么事情呢?

上面提到的那种靠人力(主要是运维干的事情)比较繁琐,还不好维护,有这么几点不方便:应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构:

    服务注册中心主要是维护各个应用服务的ip+port列表,并保持与各应用服务的通讯,在一定时间间隔内进行心跳检测,如果心跳不能到达则对服务IP列表进行剔除,并同时通知给其它应用服务进行更新。同样要是有新增的服务进来,应用服务会向注册中心进行注册,服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表,这样在进行调用时只要处理客户负载杂均衡即可。

二、微服务注册中心

1Zookeeper

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。

上面的话直接摘抄百度百科的内容,国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP,一般集群部署最少需要3台机器。

2Euraka

先来看一下euraka的架构图:

Register:服务注册

当Eureka客户端向Eureka Server注册时,它提供自身的元数据,比如IP地址、端口,运行状况指示符URL,主页等。

Renew:服务续约

Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在,没有出现问题。 正常情况下,如果Eureka Server在90秒没有收到Eureka客户的续约,它会将实例从其注册表中删除。 建议不要更改续约间隔。

Fetch Registries:获取注册列表信息

Eureka客户端从服务器获取注册表信息,并将其缓存在本地。客户端会使用该信息查找其他服务,从而进行远程调用。该注册列表信息定期(每30秒钟)更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同, Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配,Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息,整个注册表以及每个应用程序的信息进行了压缩,压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。

Cancel:服务下线

Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后,该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成,它需要调用以下内容:

DiscoveryManagergetInstance()shutdownComponent();

Eviction 服务剔除

在默认的情况下,当Eureka客户端连续90秒没有向Eureka服务器发送服务续约,即心跳,Eureka服务器会将该服务实例从服务注册列表删除,即服务剔除。

自我保护机制:

既然Eureka Server会定时剔除超时没有续约的服务,那就有可能出现一种场景,网络一段时间内发生了 异常,所有的服务都没能够进行续约,Eureka Server就把所有的服务都剔除了,这样显然不太合理。所以,就有了 自我保护机制,当短时间内,统计续约失败的比例,如果达到一定阈值,则会触发自我保护的机制,在该机制下, Eureka Server不会剔除任何的微服务,等到正常后,再退出自我保护机制。自我保护开关(eurekaserverenableself-preservation: false)

3Consul

consul推荐的架构图:

Consul不像Euraka的部署那么简单,他是go语言开发的,需要运维单独部署,有提供java的客户端连接,采用的是CAP的CP。

4Nacos

    Euraka是Spring Cloud Netflix早期版本中推荐使用的,后来euraka10版本不再维护,euraka20已经闭源,导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul

Nacos是阿里开源的服务注册中心,它可以与spring cloud aliaba集成使用。

Nacos的官方介绍:

    Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,帮助您实现动态服务发现、服务配置管理、服务及流量管理。

    Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。

Nacos 地图

Nacos 生态图

如 Nacos 全景图所示,Nacos 无缝支持一些主流的开源生态,例如

Spring Cloud

Apache Dubbo and Dubbo Mesh TODO

Kubernetes and CNCF TODO

三、服务注册与发现技术选型

以下是来自网上的一个分享:

除了上述的几种以外,笔者更推荐使用Nacos作为服务注册中心。

推荐理由:

Nacos服务注册表结构Map<namespace, Map<group::serviceName, Service>>采用多层次Map结构,控制的颗粒度更细,支持金丝雀模式发布,心跳同步机制也更快速,服务更新更及时。

applicationyml

eureka:

  client:

    healthcheck:

      enabled: true

警告eurekaclienthealthcheckenabled=true只能在applicationyml中设置。设置bootstrapyml中的值将导致不期望的副作用,例如在具有UNKNOWN状态的eureka中注册。

如果您需要更多的控制健康检查,您可以考虑实施自己的comnetflixappinfoHealthCheckHandler。

Eureka实例和客户端的元数据

值得花点时间了解Eureka元数据的工作原理,以便您可以在平台上使用它。有主机名,IP地址,端口号,状态页和运行状况检查等标准元数据。这些发布在服务注册表中,由客户使用,以直接的方式联系服务。额外的元数据可以添加到eurekainstancemetadataMap中的实例注册中,并且这将在远程客户端中可访问,但一般不会更改客户端的行为,除非意识到元数据的含义。下面描述了几个特殊情况,其中Spring Cloud已经为元数据映射指定了含义。

在Cloudfoundry上使用Eureka

Cloudfoundry有一个全局路由器,所以同一个应用程序的所有实例都具有相同的主机名(在具有相似架构的其他PaaS解决方案中也是如此)。这不一定是使用Eureka的障碍,但如果您使用路由器(建议,甚至是强制性的,具体取决于您的平台的设置方式),则需要明确设置主机名和端口号(安全或非安全),以便他们使用路由器。您可能还需要使用实例元数据,以便您可以区分客户端上的实例(例如,在自定义负载平衡器中)。默认情况下,eurekainstanceinstanceId为vcapapplicationinstance_id。例如:

applicationyml

eureka:

  instance:

    hostname: ${vcapapplicationuris[0]}

    nonSecurePort: 80

根据Cloudfoundry实例中安全规则的设置方式,您可以注册并使用主机VM的IP地址进行直接的服务到服务调用。此功能尚未在Pivotal Web Services( PWS )上提供。

在AWS上使用Eureka

如果应用程序计划将部署到AWS云,那么Eureka实例必须被配置为AWS意识到,这可以通过定制来完成 EurekaInstanceConfigBean 方式如下:

@Bean

@Profile("!default")

public EurekaInstanceConfigBean eurekaInstanceConfig(InetUtils inetUtils) {

  EurekaInstanceConfigBean b = new EurekaInstanceConfigBean(inetUtils);

  AmazonInfo info = AmazonInfoBuildernewBuilder()autoBuild("eureka");

  bsetDataCenterInfo(info);

  return b;

}

更改Eureka实例ID

香草Netflix Eureka实例注册了与其主机名相同的ID(即每个主机只有一个服务)。Spring Cloud Eureka提供了一个明智的默认,如下所示:${springcloudclienthostname}:${springapplicationname}:${springapplicationinstance_id:${serverport}}}。例如myhost:myappname:8080。

使用Spring Cloud,您可以通过在eurekainstanceinstanceId中提供唯一的标识符来覆盖此。例如:

applicationyml

eureka:

  instance:

    instanceId: ${springapplicationname}:${vcapapplicationinstance_id:${springapplicationinstance_id:${randomvalue}}}

使用这个元数据和在localhost上部署的多个服务实例,随机值将在那里进行,以使实例是唯一的。在Cloudfoundry中,vcapapplicationinstance_id将在Spring Boot应用程序中自动填充,因此不需要随机值。

使用EurekaClient

一旦您拥有@EnableDiscoveryClient(或@EnableEurekaClient)的应用程序,您就可以使用它来从 Eureka服务器 发现服务实例。一种方法是使用本机comnetflixdiscoveryEurekaClient(而不是Spring云DiscoveryClient),例如

@Autowired

private EurekaClient discoveryClient;

public String serviceUrl() {

    InstanceInfo instance = discoveryClientgetNextServerFromEureka("STORES", false);

    return instancegetHomePageUrl();

}

提示不要使用@PostConstruct方法或@Scheduled方法(或ApplicationContext可能尚未启动的任何地方)EurekaClient。它被初始化为SmartLifecycle(带有phase=0),所以最早可以依靠它可用的是另一个具有更高阶段的SmartLifecycle。

本机Netflix EurekaClient的替代方案

您不必使用原始的NetflixEurekaClient,通常在某种包装器后面使用它更为方便。Spring Cloud支持 Feign (REST客户端构建器),还支持 SpringRestTemplate 使用逻辑Eureka服务标识符(VIP)而不是物理URL。要使用固定的物理服务器列表配置Ribbon,您可以将<client>ribbonlistOfServers设置为逗号分隔的物理地址(或主机名)列表,其中<client>是客户端的ID。

您还可以使用orgspringframeworkcloudclientdiscoveryDiscoveryClient,它为Netflix不具体的发现客户端提供简单的API,例如

@Autowired

private DiscoveryClient discoveryClient;

public String serviceUrl() {

    List<ServiceInstance> list = discoveryClientgetInstances("STORES");

    if (list != null && listsize() > 0 ) {

        return listget(0)getUri();

    }

    return null;

}


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/12808393.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-28
下一篇 2023-05-28

发表评论

登录后才能评论

评论列表(0条)

保存