Hystrix服务降级和分组
异常处理当我们在调用服务提供者时有可能会抛异常（注意HystrixBadRequestException异常是不会触发服务降级，原因会在后面进行介绍），默认情况下方法抛了异常会自动触发服务降级，并交给服务降级中的方法去处理。同样由于Hystrix命令存在两种实现方法来调用服务，因此异常处理也需要分为两种情况。
继承类方式如果开发者使用继承类的方式来实现Hystrix命令，那么我们可以在getFallback()方法内通过Throwable executionException = getExecutionException();方法来获取具体的异常信息，然后通过判断以进入不同的处理逻辑。
修改MovieCommand类中的getFallback方法的代码为如下所示：
123456@Overrideprotected Movie getFallback() { Throwable executionException = getExecutionException(); System.out.println(executionException.getMessage ...
Hystrix自定义命令
使用详解在前面我们已经使用了Hystrix中的核心注解@HystrixCommand，通过它创建了HystrixCommand的实现，同时利用fallback属性指定了服务降级的实现方法。但是这都是Hystrix的一小部分，在实现一个大型分布式系统时，还需要更多高级的配置功能，接下来就详细学习Hystrix各接口和注解的使用方法。
自定义HystrixCommandHystrix命令就是之前所说的HystrixCommand，它用来封装具体的依赖服务调用逻辑。在前面是使用了@HystrixCommand注解的方式，其实也可以采用自定义类然后继承HystrixCommand抽象类的方式。
第一步，在之前的ribbon-consumer项目内新建pojo包，并在里面新建一个Movie类，其中的代码为：
123456public class Movie { private String name; private double price; private String author; //getter、setter、toString和有参、无参的构造方法& ...
Hystrix断路器原理和依赖隔离
断路器原理断路器在HystrixCommand和HystrixObservableCommand执行过程中起到了非常重要的作用，它是Hystrix的核心部件。那么问题来了，断路器是如何决策熔断和记录信息的呢？本篇就来深入了解这其中的原理。
首先我们在服务消费者的入口类上添加@EnableCircuitBreaker注解，它的作用是开启断路器，查看一下该注解的源码：
1234567@Target({ElementType.TYPE})@Retention(RetentionPolicy.RUNTIME)@Documented@Inherited@Import({EnableCircuitBreakerImportSelector.class})public @interface EnableCircuitBreaker {}
既然开启的是CircuitBreaker（断路器），且此处必定和Hystrix相关，因此可以搜索HystrixCircuitBreaker这个对象，可以发现存在一个同名的类和接口，此处主要关注接口，查看一下 ...
Hystrix原理分析
原理分析通过前面的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基础使用
Hystrix断路器在微服务架构中，我们将系统拆分成很多服务单元，各单元的应用间通过服务注册与订阅的方式互相依赖。由于每个单元都在不同的进程中运行，依赖通过远程调用的方式执行，这样就有可能因为网络原因或是依赖服务自身问题出现调用故障或延迟，而这些问题会直接导致调用方的对外服务也出现延迟，若此时调用方的请求不断增加，最后就会因等待出现故障的依赖方响应形成任务积压，最终导致自身服务的瘫痪。
上面那样说你可能不太明白，没关系接下来举一个司空见惯的例子来帮助你理解。如果你想开发一个电商网站，里面包括用户管理、商品管理、类目管理、订单管理等模块，按照传统的软件开发方式其实非常简单，只需要创建一个Web服务，很快就能将这个功能上线，但是如果我们会采用微服务架构+服务治理的方式来实现，那么此时就稍微麻烦一些。首先需要将这个项目拆分为用户管理、商品管理、类目管理、订单管理等4个微服务，这四个服务各建一个模块，分别是用户模块、商品模块、类目模块、订单模块，然后这四个模块通过内部服务治理互相调用。但是可能会出现一个问题，就是目前这些模块是通过服务注册与订阅的方式互相依赖，如果某个模块出现故障，那么会导致依 ...
RestTemplate详解
写在前面在前面介绍服务发现与消费实现的时候，就使用到了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 ...
Ribbon实现客户端负载均衡
SpringCloud Ribbon是一个基于Http和Tcp的客户端负载均衡工具，它基于Netflix Ribbon实现。通过SpringCloud的封装，可以让我们轻松的将面向服务的REST模板请求自动转换成客户端负载均衡的服务调用。SpringCloud Ribbon虽然只是一个工具类框架，它不像服务注册中心、配置中心、API网关那样需要独立部署，但是它几乎存在于每一个SpringCloud构建的微服务和基础设施中。
因为微服务间的调用，API网关的请求转发等内容，实际上都是通过Ribbon来实现的，包括后续将要学习的Feign，它也是基于Ribbon实现的工具。所以对于SpringCloud Ribbon的理解和使用，对于我们使用SpringCloud来构建微服务非常重要。
负载均衡负载均衡在系统架构中是一个非常重要的角色，因为它是应对系统高可用、网络压力缓冲和处理能力扩容的重要手段之一。
服务端负载均衡一般情况下我们所说的负载均衡通常都是指服务端负载均衡，服务端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。
硬件负载均衡主要通过在服务器节点之间安装专门用于负 ...
Eureka源码分析
Eureka源码分析通过前面的学习，我们对Eureka中各个核心元素的通信行为有了较为详细的认识，为了更加深入理解它的运作和配置，接下来将结合源码来分别看看各个通信行为是如何实现的。
在阅读源码之前，先回顾之前所实现的内容，从而找到一个合适的切入口来分析。首先对于服务注册中心、服务提供者、服务消费者这三个核心元素来说，服务提供者和服务消费者都是Eureka Client，在整个运行机制中是大部分通信行为的主动发起者，而服务注册中心主要是处理请求的接收者。因此Eureka采用的是客户端发现机制，我们可以从Eureka Client着手来分析它是如何完成这些主动通信行为的。
仔细回忆一下，当我们需要将一个普通的SpringBoot应用注册到Eureka Server中，或者是从Eureka Server中获取服务列表时都进行了哪些操作？显然只进行了两步：第一步，在项目入口类上添加@EnableDiscoveryClient注解；第二步，在application.yml配置文件中通过eureka.client.service-url.defaultZone参数来配置服务注册中心的位置。
那就 ...
Eureka架构分析
Eureka详解在前面通过一个简单的demo演示了服务注册与发现，构建了Eureka服务治理体系中的三个核心角色：服务注册中心、服务提供者、服务消费者。通过对前一篇的学习我们已经对Eureka的服务治理机制有了一些初步的认识，并学会了如何搭建单节点和高可用的服务注册中心，也知道了如何使用Eureka的注解和配置将SpringBoot应用纳入Eureka的服务治理体系中，成为服务提供者或是消费者。同时对于客户端负载均衡的服务消费也有了一些简单的接触，但是在实际工作中遇到的系统结构往往比前面列举的demo要复杂的多，此时如果仅仅依靠之前构建的服务治理内容，大多数情况是无法直接满足业务系统要求的，还需要结合实际情况来做一些配置、调整和扩展。因此本篇来学一些较深的知识，如Eureka的基础架构、节点间的通信机制、以及一些进阶的配置等。
基础架构在前面介绍服务治理时，举了一个例子，尽管该例子非常简单，但是却包含了整个Eureka服务治理基础架构的三个核心要素：服务注册中心、服务提供者、服务消费者。
服务注册中心，它是Eureka提供的服务端，提供服务注册与发现的功能，如前面实现的eureka-s ...
Eureka高可用注册中心
高可用注册中心高可用的必要性在微服务架构这样的分布式环境中，开发者需要充分考虑故障发生的情况，所以在生产环境中必须对各个组件进行高可用部署，对于微服务如此，对于服务注册中心也一样。在前面咋们使用的都是单节点的服务注册中心，这在生产环境中显然是不合适的，因此我们需要构建高可用的服务注册中心以增强系统的可用性。
Eureka Server从设计时就考虑了高可用的问题，在Eureka的服务治理设计中，所有的节点既是服务提供方，也是服务消费方，注册中心也不例外。在前面搭建单节点的配置中，我们设置过下面两个参数，用于禁止服务注册中心自己注册自己：
1234eureka: client: register-with-eureka: false fetch-registry: false
Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这样就可以形成一组互相注册的服务注册中心，以实现服务清单的互相同步，进而达到高可用的效果。
接下来尝试搭建高可用的服务注册中心集群，这里选择在前面实现的单节点服务注册中心的基础上进行扩展，使之变成一个双节点的服务注册 ...