eureka服务发现

概述 在这里，我们需要用的组件是 Spring Cloud Netflix 的 Eureka，Eureka 是一个服务注册和发现模块 # 创建服务注册中心 其 pom.xml 文件配置如下： <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.funtl</groupId> <artifactId>hello-spring-cloud-dependencies</artifactId> <version>1.0.0-SNAPSHOT</version> <relativePath>../hello-spring-cloud-dependencies/pom.xml</relativePath> </parent> <artifactId

Eureka 是Spring Cloud Netflix 微服务套件中的一部分，它基于Netflix Eureka做了二次开发，主要负责完成微服务架构中的服务治理功能。 Eureka 基础架构三个核心要素 1：服务注册中心 2：服务提供者 3：服务消费者 服务治理主要分为 ： 1：服务注册： 在服务治理框架中，通常都会构建一个服务注册中心，每个服务提供者需要向注册中心，登记自己的注册信息。比如IP，端口号，版本号，服务名，通信协议等等附加信息告知注册中心，注册中心会根据服务名，进行分类服务清单。例如下图： eureka维护分类服务清单，是通过一个双层Map, 第一层Map的key就是服务名，例如上图的HELLO-SERVICE,第二层的Key就是具体的实例信息，例如上图的DLBOOH........:hello-service:8081 2：服务发现 由于在服务治理框架下运作程序，服务间的调用不在是通过指定具体的实例地址来实现，服务间的调用通过服务名来调用，例如：http://hello-service:8081/hello。所以当 服务调用方 想要调用 服务提供方 的接口时，服务调用方是不知道服务提供方的具体实例地址的， 因此调用方需要向注册中心Eureka咨询服务，并获取所有服务的实例清单。例如：现有服务B想要调用服务A，服务B就需要向注册中心发起请求获取服务A的实例清单

一. 简介 什么是SpringCloud Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、熔断器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包 SpringCloud与SpringBoot的关系 Spring Boot 是 Spring 的一套快速配置脚手架，可以基于Spring Boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring Boot专注于快速、方便集成的单个微服务个体，Spring Cloud关注全局的服务治理框架； Spring Boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring Boot来实现，可以不基于Spring Boot吗？不可以。 Spring Boot可以离开Spring Cloud独立使用开发项目，但是Spring

　　springcloud是一个基于springboot的一站式企业级分布式应用开发框架。springboot为其提供了创建单一项目的便利性，springcloud组合了现有的、常用的分布式项目的解决方案，融合为一个全家桶。对于中小企业来说，这将使其轻易就能够构建出分布式应用。 　　 对于研发人员来说，学会使用它并不是最终目的。spring带来的东西总是值得被拿来学习的，从源码得角度靠近spring或者apache一点，对于热衷于代码的程序员还是很有意思的。 　　本系列文章，将开始学习了解一些springcloud源码相关的东西，也希望通过这种记录的方式来一点点分解得破开springcloud的迷雾。 　　 目录： 　　辅助阅读 　　　　 1、 springboot启动流程源码解析 　　　　2、 restTemplate源码解析 　　eureka服务发现 　　　　1、eureka服务端自动配置 　　　　2、eureka服务端注册服务 　　　　3、eureka服务端查找服务 　　　　4、eureka服务端集群分发 　　　　5、eureka客户端自动配置 　　　　6、eureka客户端注册服务 　　　　7、eureka客户端查找服务 　　　　8、eureka客户端调用服务 　　 feign接口调用 　　ribbon客户端负载均衡 　　hystrix熔断 　　zuul网关 　

微服务调用Ribbon 简介 前面讲了eureka服务注册与发现，但是结合eureka集群的服务调用没讲。 这里的话 就要用到Ribbon，结合eureka，来实现服务的调用； Ribbon是Netflix发布的负载均衡器，它有助于控制HTTP和TCP的客户端的行为。为Ribbon配置服务提供者地址后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为我们提供了很多负载均衡算法，例如轮询、随机等。当然，我们也可为Ribbon实现自定义的负载均衡算法。 在Spring Cloud中，当Ribbon与Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例。展示了Ribbon与Eureka配合使用时的架构。 Ribbon是客户端负载均衡，所以肯定集成再消费端，也就是consumer端 我们修改 microservice-student-consumer-80 首先，引入依赖，pom.xml 加入 ribbon相关依赖 <!--ribbon相关依赖--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId>

Eureka、Consul、Zookeeper的基本原理与比较。 前言 在云计算和容器化技术发展火热的当下，对于微服务架构，服务注册与发现组件是必不可少的。在传统的服务架构中，服务的规模处于运维人员的可控范围内。当部署服务的多个节点时，一般使用静态配置的方式实现服务信息的设定。在微服务应用中，服务实例的数量和网络地址都是动态变化的，这对系统运维提出了巨大的挑战。因此，动态的服务注册与发现就显得尤为重要。 解决的问题 在一个分布式系统中，服务注册与发现组件主要解决两个问题：服务注册和服务发现。 服务注册：服务实例将自身服务信息注册到注册中心。这部分服务信息包括服务所在主机IP和提供服务的Port，以及暴露服务自身状态以及访问协议等信息。 服务发现：服务实例请求注册中心获取所依赖服务信息。服务实例通过注册中心，获取到注册到其中的服务实例的信息，通过这些信息去请求它们提供的服务。 除此之外，服务注册与发现需要关注监控服务实例运行状态、负载均衡等问题。 监控：微服务应用中，服务处于动态变化的情况，需要一定机制处理无效的服务实例。一般来讲，服务实例与注册中心在注册后通过心跳的方式维系联系，一旦心跳缺少，对应的服务实例会被注册中心剔除。 负载均衡：同一服务可能同时存在多个实例，需要正确处理对该服务的负载均衡。 CAP CAP原则，指的是在一个分布式系统中，Consistency(一致性)

eureka官方已经正式宣布：自2.0起不再维护该项目，并在 github 项目wiki 上放出了一段吓唬人的话: 大意就是：从2.x起，官方不会继续开发了，如果需要使用2.x，风险自负。但其实我觉得问题并不大，eureka目前的功能已经非常稳定，就算不升级，服务注册/发现这些功能已经够用。 如果想寻找替代方案的话，建议采用功能更为丰富的consul，除了服务注册、发现，consul还提供了k-v存储等其它功能，consul的官网针对其它同类软件也做了详细比较，详见 consul vs other software ，有兴趣的可以看看，特别是有一句话，翻译成大白话就是：我不是针对在座的各位，我想说除我之外其它的都是渣渣（足见其相当的自信！） 进入正题，先来看consul的部署安装： 一、集群规划 consul借助agent来运行，类似elk的logstash agent 或 zabbix监控系统的agent ，每个需要被发现的服务上，通过consul agent client 来收集服务本身的信息，然后向consul agent server汇报, consul server 可以集群部署。 规划一下： 序号　 节点ip 节点名称 角色 1 10.0.xx.55 server1 server 2 10.0.xx.203 server2 server 3 10.0.xx.204

CAP 定理 CAP定理：CAP定理又称CAP原则，指的是在一个分布式系统中，一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。CAP 原则指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（P），就是高可用性，一个节点崩了，并不影响其它的节点（100个节点，挂了几个，不影响服务，越多机器越好） 一般来讲，基于网络的不稳定性，分布容错是不可避免的，所以我们默认CAP中的P总是成立的。 我们接下来介绍的服务注册和发现组件中，Eureka满足了其中的AP，Consul和Zookeeper满足了其中的CP Eureka Eureka是在Java语言上，基于Restful Api开发的服务注册与发现组件，由Netflix开源。遗憾的是，目前Eureka仅开源到1.X版本，2.X版本已经宣布闭源。 Eureka 采用的是Server/Client的模式进行设计的。Server是服务注册中心的角色，为Client提供服务的注册与发现功能，维护着注册到自身的Client的相关信息

1. 什么是微服务 以前的模式是 所有的代码在同一个工程中 部署在同一个服务器中 同一个项目的不同模块不同功能互相抢占资源 微服务 将工程根据不同的业务规则拆分成微服务 微服务部署在不同的机器上 服务之间进行相互调用 Java微服务的框架有 dubbo（只能用来做微服务），spring cloud（提供了服务的发现，断路器等） 微服务化的核心就是将传统的一站式应用,根据业务拆分成一个一个的服务,彻底地去耦合, 每一个微服务提供单个业务功能的服务,一个服务做一件事, 从技术角度看就是一种小而独立的处理过程,类似进程概念,能够自行单独启动或销毁 拥有自己独立的数据库 2. springcloud如何实现服务的注册和发现 服务在发布时 指定对应的服务名（服务名包括了IP地址和端口） 将服务注册到注册中心（eureka或者zookeeper） 这一过程是springcloud自动实现 只需要在main方法添加@EnableDisscoveryClient 同一个服务修改端口就可以启动多个实例 调用方法：传递服务名称通过注册中心获取所有的可用实例 通过负载均衡策略调用（ribbon和feign）对应的服务 3.Ribbon和Feign的区别 Ribbon和Feign都是用于调用其他服务的，不过方式不同。 1.启动类使用的注解不同，Ribbon用的是@RibbonClient，Feign用的是

Netflix开源提供的一款提供服务注册与服务发现的产品， 基于REST的服务，定位服务，来进行中间层服务器的负载均衡和故障转移 采用C/S架构，一个服务器，多个客户端。 eureka-server作为服务注册功能的服务器，它是服务注册中心，而系统中的其它的微服务会使用Eureka的客户端连接，连接到eureka-server上，并维持一个心跳连接，告诉evreka-server说我这个微服务还是存在的。这样系统的维护人员/客户端就可通过eureka-server来监控系统中其它各个微服务是否正常运行 SpringCloud本身已经帮我们实现了EurekaServer，只需要在工程上注解或标识就可以了 来源： https://www.cnblogs.com/greycdoer0/p/11863799.html