余思博客

断路器原理断路器在HystrixCommand和HystrixObservableCommand执行过程中起到了非常重要的作用，它是Hystrix的核心部件。那么问题来了，断路器是如何决策熔断和记录信息的呢？本篇就来深入了解这其中的原理。 首先我们在服务消费者的入口类上添加@EnableCircuitBreaker注解，它的作用是开启断路器，查看一下该注解的源码： 1234567@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import({EnableCircuitBreakerImportSelector.class})public @interface EnableCircuitBreaker {} 既然开启的是CircuitBreaker（断路器），且此处必定和Hystrix相关，因此可以搜索HystrixCircuitBreaker这个对象，可以发现存在一个同名的类和接口，此处主要关注接口，查看一下 ...

原理分析通过前面的demo演示，我们对Hystrix的使用场景和使用方法已经有了一个初步的了解。接下来通过解读Netflix Hystrix官方提供的流程图来详细了解当一个请求调用了相关服务依赖之后Hystrix是如何工作的（即当你访问http://localhost:9000/ribbon-consumer请求之后，在RIBBON-CONSUMER中是如何处理的）。 工作流程接下来根据官方提供的Netflix Hystrix流程图中的所标记的数字顺序来解释每一个环节的详细内容，如下图所示： 这一流程中所涉及的流程如下所示：（1）创建HystrixCommand或HystrixObservableCommand对象；（2）执行command命令；（3）结果是否被缓存；（4）断路器是否打开;（5）线程池/请求队列/信号量是否占满；（6）HystrixObservableCommand.construct() 或者HystrixCommand.run()；（7）计算断路器的健康度；（8）fallback处理；（9）返回成功的响应。接下来将详细对以上流程进行分析，以加深对于Netflix ...

Hystrix断路器在微服务架构中，我们将系统拆分成很多服务单元，各单元的应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因等待出现故障的依赖方响应形成任务积压，最终导致自身服务的瘫痪。 上面那样说你可能不太明白，没关系接下来举一个司空见惯的例子来帮助你理解。如果你想开发一个电商网站，里面包括用户管理、商品管理、类目管理、订单管理等模块，按照传统的软件开发方式其实非常简单，只需要创建一个Web服务，很快就能将这个功能上线，但是如果我们会采用微服务架构+服务治理的方式来实现，那么此时就稍微麻烦一些。首先需要将这个项目拆分为用户管理、商品管理、类目管理、订单管理等4个微服务，这四个服务各建一个模块，分别是用户模块、商品模块、类目模块、订单模块，然后这四个模块通过内部服务治理互相调用。但是可能会出现一个问题，就是目前这些模块是通过服务注册与订阅的方式互相依赖，如果某个模块出现故障，那么会导致依 ...

写在前面在前面介绍服务发现与消费实现的时候，就使用到了RestTemplate，该对象会使用Ribbon的自动化配置，同时通过配置@LoadBalanced注解来开启客户端负载均衡功能。（前面也说过Ribbon实现了服务消费者的客户端负载均衡功能。）前面的例子演示了通过RestTemplate来发起一个GET或者POST请求，其实是实现对HELLO-SERVICE服务提供的/hello接口进行调用。 接下来介绍RestTemplate针对几种不同请求类型和参数类型的服务调用实现，同时为了加深印象，笔者会通过一个例子来进行验证。 GET请求首当其冲是Get请求，对于Get请求我们太司空见惯了，在RestTemplate中，我们可以通过以下两种方式来发送一个GET请求。 getForEntity方法使用getForEntity方法返回了一个ResponseEntity<T>对象，该对象是Spring对HTTP请求响应的封装，其中主要存储了HTTP的几个重要元素，如HTTP请求状态码的枚举对象HttpStatus（也就是常说的404，500等状态码），在它的父类HttpEntit ...

SpringCloud Ribbon是一个基于Http和Tcp的客户端负载均衡工具，它基于Netflix Ribbon实现。通过SpringCloud的封装，可以让我们轻松的将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。SpringCloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个SpringCloud构建的微服务和基础设施中。 因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续将要学习的Feign，它也是基于Ribbon实现的工具。所以对于SpringCloud Ribbon的理解和使用，对于我们使用SpringCloud来构建微服务非常重要。 负载均衡负载均衡在系统架构中是一个非常重要的角色，因为它是应对系统高可用、网络压力缓冲和处理能力扩容的重要手段之一。 服务端负载均衡一般情况下我们所说的负载均衡通常都是指服务端负载均衡，服务端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。 硬件负载均衡主要通过在服务器节点之间安装专门用于负 ...

Eureka源码分析通过前面的学习，我们对Eureka中各个核心元素的通信行为有了较为详细的认识，为了更加深入理解它的运作和配置，接下来将结合源码来分别看看各个通信行为是如何实现的。 在阅读源码之前，先回顾之前所实现的内容，从而找到一个合适的切入口来分析。首先对于服务注册中心、服务提供者、服务消费者这三个核心元素来说，服务提供者和服务消费者都是Eureka Client，在整个运行机制中是大部分通信行为的主动发起者，而服务注册中心主要是处理请求的接收者。因此Eureka采用的是客户端发现机制，我们可以从Eureka Client着手来分析它是如何完成这些主动通信行为的。 仔细回忆一下，当我们需要将一个普通的SpringBoot应用注册到Eureka Server中，或者是从Eureka Server中获取服务列表时都进行了哪些操作？显然只进行了两步：第一步，在项目入口类上添加@EnableDiscoveryClient注解；第二步，在application.yml配置文件中通过eureka.client.service-url.defaultZone参数来配置服务注册中心的位置。 那就 ...

Eureka详解在前面通过一个简单的demo演示了服务注册与发现，构建了Eureka服务治理体系中的三个核心角色：服务注册中心、服务提供者、服务消费者。通过对前一篇的学习我们已经对Eureka的服务治理机制有了一些初步的认识，并学会了如何搭建单节点和高可用的服务注册中心，也知道了如何使用Eureka的注解和配置将SpringBoot应用纳入Eureka的服务治理体系中，成为服务提供者或是消费者。同时对于客户端负载均衡的服务消费也有了一些简单的接触，但是在实际工作中遇到的系统结构往往比前面列举的demo要复杂的多，此时如果仅仅依靠之前构建的服务治理内容，大多数情况是无法直接满足业务系统要求的，还需要结合实际情况来做一些配置、调整和扩展。因此本篇来学一些较深的知识，如Eureka的基础架构、节点间的通信机制、以及一些进阶的配置等。 基础架构在前面介绍服务治理时，举了一个例子，尽管该例子非常简单，但是却包含了整个Eureka服务治理基础架构的三个核心要素：服务注册中心、服务提供者、服务消费者。 服务注册中心，它是Eureka提供的服务端，提供服务注册与发现的功能，如前面实现的eureka-s ...

高可用注册中心高可用的必要性在微服务架构这样的分布式环境中，开发者需要充分考虑故障发生的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。在前面咋们使用的都是单节点的服务注册中心，这在生产环境中显然是不合适的，因此我们需要构建高可用的服务注册中心以增强系统的可用性。 Eureka Server从设计时就考虑了高可用的问题，在Eureka的服务治理设计中，所有的节点既是服务提供方，也是服务消费方，注册中心也不例外。在前面搭建单节点的配置中，我们设置过下面两个参数，用于禁止服务注册中心自己注册自己： 1234eureka: client: register-with-eureka: false fetch-registry: false Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，进而达到高可用的效果。 接下来尝试搭建高可用的服务注册中心集群，这里选择在前面实现的单节点服务注册中心的基础上进行扩展，使之变成一个双节点的服务注册 ...

写在前面在前面学习了Eureka相关的基础知识，接下来将通过一些简单的示例，来学习如何使用Eureka构建注册中心以及进行注册与发现服务。 搭建服务注册中心为了更好的学习，此处提供两种方式，第一种是基于一个基础的SpringBoot工程来构建，另一种则是直接构建Eureka项目。 基于普通的SpringBoot工程第一步，创建一个普通的Spring Boot工程。首先需要创建一个普通的SpringBoot工程，工程名称为eureka-server，注意里面一个starter都不需要添加，这样创建成功后pom文件中只引用了一个父starter。 第二步，添加Eureka依赖。工程创建成功之后，需要向pom.xml文件中添加eureka-server依赖，笔者使用的SpringBoot版本是2.3.3，因此所对应的Eureka版本为Hoxton.SR7，请注意SpringBoot版本和Eureka的版本必须一一对应，开发者可以点击 这里进行查阅： 当然了，如果想查阅更为详细的版本对应信息，可以点击 这里： 注意此时pom.xml依赖文件中的依赖信息添加，可以参考Spring Cl ...

SpringCloud Eureka是SpringCloud Netflix微服务套件中的一部分，它基于Netflix Eureka进行了二次封装，不是重复造轮子，主要负责完成微服务架构中的服务治理功能。SpringCloud通过为Eureka增加了SpringBoot风格的自动化配置，我们只需要通过简单引入依赖和注解配置就能让SpringBoot构建的微服务应用轻松的与Eureka服务治理体系进行整合。 服务治理服务治理是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册与发现。你可能要问了，在微服务架构中为什么需要服务治理模块呢？往下看你就知道了。 在最开始构建微服务系统的时候可能服务并不多，我们可以通过做一些静态配置来完成服务的调用。比如这里有两个服务A和B，其中服务A需要调用服务B来完成一个业务操作，为了实现服务B的高可用，开发者可能采用服务端的负载均衡或者客户端的负载均衡，但是无论怎样还需要手工来维护服务B的具体实例清单。 但是随着业务的发展，系统功能越来越复杂，相应的微服务应用也越来越多，此时依赖采用静态配置这种方式就显得捉襟见肘了。并且面对不断发展 ...