eureka服务发现

1.SpringCloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、负载均衡、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。另外说明spring cloud是基于Springboot的，所以需要开发中对Springboot有一定的了解。 2.服务提供者与消费关系 　　就是我我们常说的消费者和生产者 　　生产者：提供服务给消费者调用 　　消费者：调用生产者提供的服务，从而实现自身的功能模块 3.服务注册中心Eureka 　　与duboo类似，duboo我们一般选择zookeper做服务的注册中心，而springcloud是使用Eureka做服务注册中心的。他的作用是就是服务注册与服务发现。以下是比较官方的说明 　　 　　官方的介绍在这里 Eureka wiki 。Eureka是Netflix开源的一个RESTful服务，主要用于服务的注册发现。Eureka由两个组件组成：Eureka服务器和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客　　　　　　 　　 　　 　　　　　　　　　　　　　　 户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量

Spring Cloud 基于 Netflix 的几个开源项目进行了封装，提供包括服务注册与发现（Eureka），智能路由（Zuul），熔断器（Hystrix），客户端负载均衡（Ribbon）等在内的核心组件。 在微服务系统中，服务少则十几、几十个，多则上百、几百个（据悉 Netflix 的云平台上运行了500多个微服务），这些微服务通过相互调用来为用户提供功能。那么一个服务调用另一个服务是如何进行的，如何定位到另一个服务的地址？代码中写死，还是配置文件中配置？显然对于服务数量较多的系统，这两种方式先不说后续维护，光写起来就很痛苦。于是，对于微服务架构来说，服务的自动注册与发现就成为非常核心的功能，Eureka就是来负责实现这个功能的。 本系列文章与示例均基于最新的Spring Cloud Hoxton版编写。 Eureka Eureka是一个基于REST的服务，包括Eureka Server与Eureka Client两个端。Eureka Server作为服务注册中心接受Eureka Client的注册及获取其它服务的地址信息。基本架构如下图所示： 其中 Eureka Server： 作为服务注册中心，提供服务注册与发现功能接口 Service Provider： 服务提供者，将自身服务注册到服务注册中心，供其它服务消费者发现与调用 Service Consumer： 服务消费者

一：创建 eureka-zuul-client 服务 1.1 在主Maven工程中创建一个新的 Module 工程，命名为eureka-zuul-client。采用Spring Initializr 的方式的方式创建。 1.2 eureka-zuul-client 的 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 https://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.springcloud</groupId> <artifactId>springcloud-hx</artifactId> <version>1.0-SNAPSHOT</version> <relativePath/> <!-- lookup parent from repository -->

参考自： 方志朋的专栏 1. Ribbon 1.1 Ribbon简介 Spring Cloud Ribbon是一个基于HTTP和TCP的客户端负载均衡工具，它基于Netflix Ribbon实现。通过Spring Cloud的封装，可以让我们轻松地将面向服务的REST模版请求自动转换成客户端负载均衡的服务调用。Spring Cloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个Spring Cloud构建的微服务和基础设施中。因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续我们将要介绍的Feign，它也是基于Ribbon实现的工具。所以，对Spring Cloud Ribbon的理解和使用，对于我们使用Spring Cloud来构建微服务非常重要。 1.2 创建服务消费者 这一篇文章基于上一篇文章的工程，启动eureka-server 工程，它的端口为8761；启动service-hi工程，它的端口为8762；将service-hi的配置文件的端口改为8763，并启动。这时你会发现：service-hi在eureka-server注册了2个实例，这就相当于一个小的集群。 重新新建一个spring-boot工程，取名为：service-ribbon; 在它的pom

参考： 方志鹏的专栏 1. Eureka简介 Spring Cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。 其中Eureka 是 Netflix 开发的，一个基于 REST 服务的，服务注册与发现的组件。 它主要包括两个组件：Eureka Server 和 Eureka Client。 Eureka Server：提供服务注册和发现的能力（通常就是微服务中的注册中心） Eureka Client：一个Java客户端，用于简化与 Eureka Server 的交互（通常就是微服务中的客户端和服务端） 各个微服务启动时，会通过 Eureka Client 向 Eureka Server 注册自己，Eureka Server 会存储该服务的信息；也就是说，每个微服务的客户端和服务端，都会注册到 Eureka Server，这就衍生出了微服务相互识别的话题。 同步：每个 Eureka Server 同时也是 Eureka Client（逻辑上的） 　　　多个 Eureka Server 之间通过复制的方式完成服务注册表的同步，形成 Eureka 的高可用 识别：Eureka Client 会缓存 Eureka Server 中的信息 　　　即使所有 Eureka Server 节点都宕掉

springcloud 1、微服务调用Ribbon 简介 初步应用 2、Ribbon负载均衡 3、Feign简介及应用 简介 应用 1、微服务调用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

一、ribbon是什么? Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端 负载均衡的工具。 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。 二、客户端负载均衡？？ 服务端负载均衡?? 我们用一张图来描述一下这两者的区别 这篇文章里面不会去解释nginx，如果不知道是什么的话，可以先忽略， 先看看这张图 服务端的负载均衡是一个url先经过一个代理服务器（这里是nginx），然后通过这个代理服务器通过算法（轮询，随机，权重等等…）反向代理你的服务，来完成负载均衡 而客户端的负载均衡则是一个请求在客户端的时候已经声明了要调用哪个服务，然后通过具体的负载均衡算法来完成负载均衡。 三、如何使用: 首先，我们还是要引入依赖，但是，eureka已经把ribbon集成到他的依赖里面去了，所以这里不需要再引用 ribbon的依赖，如图： 依赖： < dependency > < groupId

0、为什么需要eureka 　　当我们从当体系统拆分为多个独立服务项目之后，如果aaa.com/uer、aaa.com/order;；相互之间调用，如果只是一个服务一个实例，那还可以直接通过固定地址（如http://111.111.11.1：7119/user/getuser/1）直接访问； 　　但是，我们一个服务有很多个实例，这样你就不能写死地址了吧，多个之间你得挑出一个来调用吧（负载均衡），还有多个实例有的停止了，有的新加入了，这你得心跳检测健康监测吧等等；这些，都是从单体系统拆分后面临的实际问题，你可以自己一个一个去克服和实现；当遇到了spring cloud，哈哈，你有福了，spring cloud eureka正是为你解决以上问题而来； 　　 eureka服务发现组件包含eureka server(服务注册中心)和eureka client（服务注册与发现）；本身通过心跳检测（默认30S）进行服务的注册与发现与健康检查 一、eureka集成 1、eureka server 1.1、添加依赖： <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> 1

转眼已经2020，距离微服务这个词落地已经过去好多年！（我记得2017年就听过这个词）。然而今天我想想什么是微服务，其实并没有一个很好的定义。为什么这样说，按照微服务的定义： 微服务架构就是将一个庞大的业务系统按照业务模块拆分成若干个独立的子系统，每个子系统都是一个独立的应用，它是一种将应用构建成一系列按业务领域划分模块的，小的自治服务的软件架构方式，倡导将复杂的单体应用拆分成若干个功能单一、松偶合的服务，这样可以降低开发难度、增强扩展性、便于敏捷开发，及持续集成与交付活动。 根据这个定义，不难看出其实就是对复杂的业务系统统一做逻辑拆分，保持逻辑上的独立。那么逻辑上独立就是一个服务这样做真的是好吗，如何界定：小、独，还有要做一个事情，完成单一的业务，单一的功能要拆分出来，为了独立而独立会不会导致拆的过细？不同人有不同的见解，我们今天一起探讨微服务的过去和未来。 微服务缘起 在没有微服务之前，我们最早的架构模式就是 MVC 模式，把业务逻辑分为：表示层，业务逻辑层，数据访问层。MVC模式随着大前端的发展，从一开始的前后端不分离，到现在的前后端分离逐渐演进。这种演进好的一点是剥离了不同开发语言的开发环境和部署环境，使得开发较为便利，部署更直接。然而问题是：这种模式仍然是单体应用模式，如果有一个改动需要上线，你不得不因为这个改动去考虑更多

一、服务发现概述 1、服务发现由来 服务发现及注册中心(统一称为服务发现)，是跟随软件开发的架构方式而逐步演变而来的 早期的单体架构 对于外部的依赖，通常是采取调用域名接口的形式，例如短信发送接口，就会通过appId和appKey去调用相应的域名，完成短信的发送。 SOA架构发展 单体架构被拆分成粒度较粗的服务化架构，此时内部的依赖就比较多，那么是如何进行服务间的调用呢？以http暴露服务的形式来说，将服务A部署在多台虚拟机上，服务B通过调用服务A的ip地址来进行调用：1、服务A的ip由服务B来维护，通过配置nginx的upstream将服务A的所有实例ip写进去，但这样也暴露了服务A一些实现的细节且A和B不能解耦；2、服务B通过调用服务A的内部域名，而服务A的所有实例ip由自己的nginx维护。 微服务时代 由于docker的崛起，导致服务A的ip并不是固定的，因此上面的做法就比较麻烦了，有两个方案：1、在部署的时候更新nginx的文件，使用ngx_http_dyups_module通过rest api去更新nginx的upstream而不需要reload；2、将服务注册中心作为一个标配组件，网关等组件通过服务注册中心获取实例的相关信息，实现动态路由。 2、Eureka简介 什么是Eureka呢 官网中给出的解释： Eureka is a REST