eureka服务发现

目录 Eureka 系列（01）最简使用姿态 1. 服务发现与发现 1.1 服务发现(Service Discovery) 1.2 服务注册(Service Registration) 2. Eureka 2.1 服务端: Eureka Server 2.2 客户端: Eureka Client Eureka 系列（01）最简使用姿态 Eureka 是由 Netflix 公司的服务发现中间件，包括服务发现服务器和客户端的。 Spring Cloud Eureka 官网文档 1. 服务发现与发现 1.1 服务发现(Service Discovery) 服务发现：在计算机网络中，一种自动发现设备或者服务的技术，通过服务发现协议(Service Discovery Protocol)实现。常见的协议有以下几种： Java: Jini(Apache River) REST: HATEOAS Web Services: UDDI(Universal Description Discovery and Integration) 1.2 服务注册(Service Registration) 服务注册(Service Registration)在计算机网络中，为了更好地治理多个设备或者服务，这些设备或者服务主动或者被动注册到管理中心，以便服务被发现和消费。常见注册中心有以下几种： Apache

Eureka 系列（02）服务发现源码分析 [TOC] 在上一篇 Eureka 系列（01）最简使用姿态 中对 Eureka 的简单用法做了一个讲解，本节分析一下 EurekaClient 的实现 DiscoveryClient。本文的源码是基于 Eureka-1.9.8。 1）服务注册（发送注册请求到注册中心） 2）服务发现（本质就是获取调用服务名所对应的服务提供者实例信息，包括IP、port等） 3）服务续约（本质就是发送当前应用的心跳请求到注册中心） 4）服务下线（本质就是发送取消注册的HTTP请求到注册中心） 1. DiscoveryClient 基本功能简介 图1：DiscoveryClient 服务注册与发现时序图 sequenceDiagram participant DiscoveryClient participant InstanceInfoReplicator participant scheduler participant cacheRefreshExecutor participant CacheRefreshThread participant heartbeatExecutor participant HeartbeatThread DiscoveryClient ->> scheduler : initScheduledTasks loop 1

Eureka 是 Netflix 开发的，一个基于 REST 服务的，服务注册与发现的组件 它主要包括两个组件：Eureka Server 和 Eureka Client Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端） Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心） 各个微服务启动时，会通过 Eureka Client 向 Eureka Server 注册自己，Eureka Server 会存储该服务的信息 也就是说，每个微服务的客户端和服务端，都会注册到 Eureka Server，这就衍生出了微服务相互识别的话题 同步：每个 Eureka Server 同时也是 Eureka Client（逻辑上的） 　　　多个 Eureka Server 之间通过复制的方式完成服务注册表的同步，形成 Eureka 的高可用 识别：Eureka Client 会缓存 Eureka Server 中的信息 　　　即使所有 Eureka Server 节点都宕掉，服务消费者仍可使用缓存中的信息找到服务提供者（笔者已亲测） 续约：微服务会周期性（默认30s）地向 Eureka Server 发送心跳以Renew（续约）信息（类似于heartbeat） 续期：Eureka

本系列七篇文章列表如下： 微服务实战（一）：微服务架构的优势与不足 微服务实战（二）：使用API Gateway 微服务实战（三）：深入微服务架构的进程间通信 微服务实战（四）：服务发现的可行方案以及实践案例 微服务实践（五）：微服务的事件驱动数据管理 微服务实践（六）：选择微服务部署策略 微服务实践（七）：从单体式架构迁移到微服务架构 这是关于使用微服务架构创建应用系列的第四篇文章。第一篇介绍了微服务架构的模式，讨论了使用微服务架构的优缺点。第二和第三篇描述了微服务架构内部的通讯机制。这篇文章中，我们将会探讨服务发现相关问题。 为什么要使用服务发现? 设想一下，我们正在写代码使用了提供REST API或者Thrift API的服务，为了完成一次服务请求，代码需要知道服务实例的网络位置（IP地址和端口）。传统应用都运行在物理硬件上，服务实例的网络位置都是相对固定的。例如，代码可以从一个经常变更的配置文件中读取网络位置。 而对于一个现代的，基于云微服务的应用来说，这却是一个很麻烦的问题。其架构如图所示： 服务实例的网络位置都是动态分配的，而且因为扩展、失效和升级等需求，服务实例会经常动态改变，因此，客户端代码需要使用一种更加复杂的服务发现机制。 目前有两大类服务发现模式： 客户端发现 和 服务端发现 。 我们先来来讨论一下客户端发现。 客户端发现模式 当使用 客户端发现模式 时

前言 在分布式系统领域有个著名的CAP定理： C——数据一致性； A——服务可用性； P——服务对网络分区故障的容错性。 这三个特性在任何分布式系统中不能同时满足，最多同时满足两个。 Zookeeper是著名Hadoop的一个子项目，很多场景下Zookeeper也作为Service发现服务解决方案。Zookeeper保证的是CP，即任何时刻对Zookeeper的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是它不能保证每次服务请求的可用性。 而Spring Cloud Netflix在设计Eureka时遵守的就是AP原则。因为对于服务消费者来说，能消费才是最重要的——拿到可能不正确的服务实例信息后尝试消费一下，也好过因为无法获取实例信息而不去消费。所以，对于服务发现而言，可用性比数据一致性更加重要——AP胜过CP。 1、服务注册与服务发现 服务治理是微服务架构中最为核心和基础的模块，主要为各个微服务实例提供自动化注册与发现功能。 服务注册：服务治理框架会构建一个注册中心，每个服务向注册中心注册登记自己提供的服务，将服务名、主机、端口号、版本号、通信协议等告知注册中心，注册中心按服务名分类组织成一个服务清单。 例如： 有三个提供订单服务的实例分别运行在 192.168.0.100:8081、192.168.0.101:8082、192.168.0.102:8083；

目录 服务搭建 1.注册中心——Eureka Server 2.服务提供方——Service Provider 3.服务消费方——Service Consumer 服务消费 Feign 与断路器 Hystrix 特别注意 Summary Reference Source Code 本文首发于我的个人博客， Spring Cloud 负载均衡初体验 ，欢迎访问！ 使用 Spring Cloud Netflix 组件 Eureka 和 Ribbon 构建单注册中心的负载均衡服务。 Spring Cloud 是基于 Spring 的微服务技术栈，可以这么概括吧，里面包含了很多例如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等组件，可以通过 Spring Boot 的形式进行集成和使用。 目前，项目中有这么个需求，Spring Boot 做一个 web 服务，然后调用 TensorFlow 模型得到结果。但是由于 TensorFlow GPU 版，不支持多线程多引擎，所以只能采用多进程的方式去进行调度，所以需要做一个负载均衡。负载均衡的话，可以分为客户端和服务端负载均衡。我目前还没能领悟到有什么不同，毕竟整体的架构都是一样的，如下如图。其中客户端均衡负载的代表是 Spring Cloud 的 Ribbon，服务端负载均衡代表是 Nginx。 由于项目的压力并不大

前言 服务注册与发现是微服务中最为基础的环节，而 Eureka 就是一个可以帮助你实现服务注册与发现的选择之一。如果你对 Eureka 和服务发现了解甚少，那么该篇博客将会帮助到你。文中通过具体操作带你了解如下内容： 什么是服务注册与发现 什么是 Eureka SpringCloud Eureka 单台环境搭建 SpringCloud Eureka 高可用环境搭建 SpringCloud Eureka RestTemplate Ribbion 的使用 SpringCloud Feign SpringCloud Eureka 的使用 阅读本文需要你熟悉SpringBoot项目的基本使用即可，还有一点需要注意的是在操作过程中尽量和我本地环境一致，因为环境不一致可能会带来一些问题。我本地环境如下： SpringBoot Version: 2.1.0.RELEASE SpringCloud Version: Greenwich.RELEASE Apache Maven Version： 3.6.0 Java Version： 1.8.0_144 IDEA：Spring Tools Suite (STS) 服务注册与发现介绍 上面讲到服务发现是微服务中最为基础的环节，什么是服务发现呢 ？我们可以从单体架构说起，单体架构各个服务都在一起，是不需要被发现的。但是在微服务的架构中会出现很多的服务

一、Eureka Eureka 是 Netflix 开发的，一个基于 REST 服务的，服务注册与发现的组件 它主要包括两个组件：Eureka Server 和 Eureka Client Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端） Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心） 二、Feign Feign其实就是HTTP客户端， Feign可以帮助我们更快捷、优雅地调用HTTP API。 注意：Feign依赖于Eureka，因为Feign需要从Eureka中获取被调用服务的应用名称和地址，如下图： @FeignClient(name = "spring-boot-db5") public interface FeignService { //服务中方法的映射路径 @RequestMapping("/ww/db2/hello") String hello(); @RequestMapping(value = "/ww/db2/findAll", method= RequestMethod.GET) String findAll(@RequestParam("idc") String idc) ; } 三、ribbon（待补充） Spring Cloud

zookeeper保证了CP（C：一致性，P：分区容错性），Eureka保证了AP（A：高可用） 1.当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的信息，但不能容忍直接down掉不可用。也就是说，服务注册功能对高可用性要求比较高，但zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新选leader。问题在于，选取leader时间过长，30 ~ 120s，且选取期间zk集群都不可用，这样就会导致选取期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够恢复，但是漫长的选取时间导致的注册长期不可用是不能容忍的。 2.Eureka保证了可用性，Eureka各个节点是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点仍然可以提供注册和查询服务。而Eureka的客户端向某个Eureka注册或发现时发生连接失败，则会自动切换到其他节点，只要有一台Eureka还在，就能保证注册服务可用，只是查到的信息可能不是最新的。除此之外，Eureka还有自我保护机制，如果在15分钟内超过85%的节点没有正常的心跳，那么Eureka就认为客户端与注册中心发生了网络故障，此时会出现以下几种情况： ①、Eureka不在从注册列表中移除因为长时间没有收到心跳而应该过期的服务。 ②

简介 Eureka服务器用作服务注册服务器。 Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。 Eureka特点 servlet 应用 Jersey 框架实现自身的 RESTful HTTP接口 服务的注册通过 HTTP 协议实现 通过 JDK 自带的 Timer 实现定时任务：心跳、定时清理过期服务、节点同步 使用Google的guava包实现内存缓存 Eureka客户端 服务启动时，向注册中心注册服务，同时从一个服务注册服务中查询所有可用服务实例的库，并缓存到本地； 用来简化与服务器的交互、作为轮询负载均衡器，并提供故障切换支持； 内置使用轮询负载均衡算法；默认发送心跳的周期是30s；当一个服务器不可用，需要3个心跳才能让服务器和客户端的元数据相同。 eureka.instance.leaseRenewalIntervalInSeconds eureka.instance.leaseExpirationDurationInSeconds Eureka服务端： 服务注册中心； 为服务实例注册管理和查询可用实例提供了REST API； 架构图 配置maven父项目的pom < groupId > com.xfdmao </ groupId > < artifactId > fcat-springcloud </