cloud - CSDN

目录 
一、Spring Cloud Hystrix概述和设计目标 
（一）Spring Cloud Hystrix基本概述 
（二）Spring Cloud Hystrix概述设计目标 
二、Spring Cloud Hytrix解决的主要内容 
（一）隔离（线程池隔离和信号量隔离） 
1.线程和线程池 
线程隔离的好处： 
线程隔离的缺点 
2.信号量隔离（Semaphores） 
（二）优雅的降级机制 
（三）熔断 
（四）缓存 
1.Hystrix缓存策略的命令执行流程 
2.请求合并实现 
（五）支持实时监控、报警、控制（修改配置） 
三、Spring Cloud Hystrix工作流程介绍 
四、仪表盘讲解 
（一）监控单体应用 
（二）Turbine集群监控 
五、Spring Cloud Hystrix配置说明 
1.Execution相关的属性的配置： 
2.Fallback相关的属性 
3.Circuit Breaker相关的属性 
4.Metrics相关参数 
5.Request Context 相关参数 
6.Collapser Properties 相关参数 
7.ThreadPool 相关参数 
六、Spring Cloud Hystrix线程调整和计算 
七、Spring Cloud Hystrix源码分析 
注：以上所有只做理论性的总结与分析，相关实战代码会在后面的博客中和github中逐步增加。 
参考书籍、文献和资料： 

注：以上所有只做理论性的总结与分析，相关实战代码会在后面的博客中和github中逐步增加。 
一、Spring Cloud Hystrix概述和设计目标 
（一）Spring Cloud Hystrix基本概述 
在软件架构领域，容错特指容忍并防范局部错误，不让这种局部错误不断扩大。我们在识别风险领域，风险可以分为已知风险和未知风险，容错直接应对的就是已知风险，这就要求针对的场景是：系统之间调用延时超时、线程的数量急剧飙升导致CPU使用率升高、集群服务器磁盘被打满等等。面对容错，我们一般都会要求提供降级方案，而且强调不可进行暴力降级（比如把整个论坛功能降掉直接给用户展现一个大白板），而是将一部分数据缓存起来，也就是要有拖底数据。 
在一个分布式系统中，必然会有部分系统的调用会失败。Hystrix是一个通过添加超时容错和失败容错逻辑来帮助你控制这些分布式系统的交互。Hystrix通过隔离服务之间的访问，阻止他们之间的级联故障以及提供后背选项来实现进行丢底方案，从而提高系统的整体弹性。 
Hystrix对应的中文名字是“豪猪”，豪猪周身长满了刺，能保护自己不受天敌的伤害，代表了一种防御机制，Hystrix提供了熔断、隔离、Fallback、cache、监控等功能，能够在一个、或多个依赖同时出现问题时保证系统依然可用。 
查看Hytrix官网有如下描述： 
Introduction：
Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, 
services and 3rd party libraries, 
stop cascading failure and enable resilience in complex distributed systems where failure is inevitable. 
大意是：Hystrix是一个延迟和容错库，旨在隔离远程系统、服务和第三方库，阻止级联故障，在复杂的分布式系统中实现恢复能力。 
（二）Spring Cloud Hystrix概述设计目标 
查看Hystrix官网https://github.com/Netflix/Hystrix/wiki中对设计目标有如下描述： 
Hystrix is designed to do the following:
1.Give protection from and control over latency and failure from dependencies accessed 
(typically over the network) via third-party client libraries.
2.Stop cascading failures in a complex distributed system.
3.Fail fast and rapidly recover.
4.Fallback and gracefully degrade when possible.
5.Enable near real-time monitoring, alerting, and operational control. 
翻译如下： 
1.通过客户端库对延迟和故障进行保护和控制。
2.在一个复杂分布式系统中防止级联故障。
3.快速失败和迅速恢复。
4.在合理情况下回退和优雅降级。
5.开启近实时监控、告警和操作控制。
二、Spring Cloud Hystrix解决的主要内容 
（一）隔离（线程池隔离和信号量隔离） 
在微服务架构中，要求服务的容错隔离，以及对应的回退降级限流方案理论，我们在以下博客中已经初步提到： 
https://blog.csdn.net/xiaofeng10330111/article/details/86772740. 
隔离的基本要求是：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。Spring Cloud Hystrix下针对隔离主要指的是线程池隔离和信号量隔离。如下图所示，可以很明显的说明信号量隔离和线程池隔离的主要区别：线程池方式下，业务请求线程和执行依赖的服务线程不是同一个线程；信号量方式下业务请求线程和执行依赖的线程是同一个线程。 
 
1.线程和线程池 
线程隔离指每个服务都为一个个独立的线程组，当某个服务出现问题时，不会导致整个服务瘫痪。由于线程隔离会带来线程开销，有些场景（比如无网络请求场景）可能会因为用开销换隔离得不偿失，为此hystrix提供了信号量隔离，当服务的并发数大于信号量阈值时将进入fallback。 
如下图，客户端（第三方，网络调用等）依赖和请求线程运行在不同的线程上，可以将他们从调用线程隔离开来，这样调用者就可以从一个耗时太长的依赖中隔离，也可以为不同的请求开启不同的线程池，彼此之间不相互干扰。 
 
传统上，我们在实现线程池隔离的手段上，一般有以下两种方式： 
方式一：使用一个大的线程池，固定线程池的大小，比如1000，通过权重的思路为某个方法分配一个固定大小的线程数，比如为某个方法请求分配了10个线程，按照实现方式有“保守型”和“限制性”，具体见以后博客中和github中的代码举例。
方式二：利用ConcurrentHashMap来存储线程池，key是方法名，值是每个方法对应的一个ThreadPool。当请求到来的时候，我们获取方法名，然后直接从Map对象中取到响应的线程池去处理。
对于方法一而言，严格意义上讲，它并不属于线程池隔离，因为它只有一个公共的线程池，然后来让大家瓜分，不过也达到了隔离的效果。在Spring Cloud Hystrix的线程池隔离上，我们使用的是方式二。对于以上两种方式，线程池的粒度都是作用在方法上，我们可以结合实际情况也可以按组来分。 
线程隔离的好处 
整个应用在客户端调用失效的情况下也能健康的运行，线程池能够保证这个线程的失效不会影响应用的运行。当失效的客户端调用回复的时候，这个线程池也会被清理并且应用会立马回复健康，比tomcat那种长时间的恢复要好很多。简而言之，线程隔离能够允许在不引起中断的情况下优雅的处理第三方调用的各种问题。 
线程隔离的缺点 
主要缺点是增加了上下文切换的开销，每个执行都涉及到队列，调度和上下文切换。不过NetFix在设计这个系统的时候，已经决定接受这笔开销，以换取他的好处。对于不依赖网络访问的服务，比如只依赖内存缓存，就不适合用线程池隔离技术，而是采用信号量隔离。 
2.信号量隔离（Semaphores） 
可以使用信号量（或者计数器）来限制当前依赖调用的并发数，而不是使用线程池或者队列。如果客户端是可信的，且能快速返回，可以使用信号量来代替线程隔离，降低开销。信号量的大小可以动态调节，线程池却不行。 
HystrixCommand和HystrixObserverCommand提供信号量隔离在下面两个地方： 
Fallback：当Hystrix检索fallback的时候，他心总是调用tomcat线程上执行此操作
如果你设置execution.isolation.strategy为SEMAPHORE的时候，Hystrix会使用信号量代替线程池去限制当前调用Command的并发数。
对于不依赖网络访问的服务，就不适合使用线程池隔离，而是采用信号量隔离。 
（二）优雅的降级机制 
超时降级、资源不足时(线程或信号量)降级，降级总之是一种退而求其次的方式，所谓降级，就是指在Hystrix执行费核心链路功能失败的情况下，我们应该如何返回的问题，根据业务场景的不同，一般采用以下两种模式进行降级： 
第一种：（最常用）如果服务失败，则我们通过fallback进行降级，返回静态值。
第二种：调用备选方案
降级会退的方案有很多，以上只是初步的建议，具体降级回退方案如：Fail Fast（快速失败）、Fail Silent（无声失败）、Fallback:Static（返回默认值）、Fallback:Stubbed（自己组装一个值返回）、Fallback:Cache via Network（利用远程缓存）、Primary + Secondary with fallback（主次方式回退），其基本的实现在相关功能由介绍，建议进行扩展学习。 
这里需要注意回退处理方式不适合的场景，如以下三种场景我们不可以使用回退处理： 
写操作
批处理
计算
（三）熔断器 
当失败率达到阀值自动触发降级(如因网络故障/超时造成的失败率高)，熔断器触发的快速失败会进行快速恢复，类似于电闸。下图是基本源码中的一个处理流程图： 
 
断路器打开还是关闭的步骤如下 
1.假定请求的量超过预定的阈值（circuitBreakerRequestVolumeThreshold）
2.再假定错误百分比超过了设定的百分比（circuitBreakerErrorThresholdPercentage）
3.断路器会从close状态到open状态
4.当打开的状态，会短路所有针对该断路器的请求
5.过了一定时间（circuitBreakerSleepWindowInMilliseconds（短路超过一定时间会重新去请求）），下一个请求将通过，不会被短路（当前是half-open状态）。如果这个请求失败了，则断路器在睡眠窗口期间返回open状态，如果请求成功，则断路器返回close状态，并重新回到第一步逻辑判断。
（四）缓存 
提供了请求缓存、请求合并实现。 
1.Hystrix缓存策略的命令执行流程                        
 
2.请求合并实现 
为什么要进行请求合并？举个例子，有个矿山，每过一段时间都会生产一批矿产出来（质量为卡车载重量的1/100），卡车可以一等到矿产生产出来就马上运走矿产，也可以等到卡车装满再运走矿产， 
前者一次生产对应卡车一次往返，卡车需要往返100次，而后者只需要往返一次，可以大大减少卡车往返次数。显而易见，利用请求合并可以减少线程和网络连接，开发人员不必单独提供一个批量请求接口就可以完成批量请求。 
 在Hystrix中进行请求合并也是要付出一定代价的，请求合并会导致依赖服务的请求延迟增高，延迟的最大值是合并时间窗口的大小，默认为10ms，当然我们也可以通过hystrix.collapser.default.timerDelayInMilliseconds属性进行修改，如果请求一次依赖服务的平均响应时间是20ms，那么最坏情况下（合并窗口开始是请求加入等待队列）这次请求响应时间就会变成30ms。在Hystrix中对请求进行合并是否值得主要取决于Command本身，高并发度的接口通过请求合并可以极大提高系统吞吐量，从而基本可以忽略合并时间窗口的开销，反之，并发量较低，对延迟敏感的接口不建议使用请求合并。 
请求合并的流程图如下：                   
 
可以看出Hystrix会把多个Command放入Request队列中，一旦满足合并时间窗口周期大小，Hystrix会进行一次批量提交，进行一次依赖服务的调用，通过充写HystrixCollapser父类的mapResponseToRequests方法，将批量返回的请求分发到具体的每次请求中。 
（五）支持实时监控、报警、控制（修改配置） 
通过仪表盘等进行统计后，从而进行实时监控、报警、控制，最终依据这些来修改配置，得到最佳的选择。 
三、Spring Cloud Hystrix工作流程介绍 
基本流程图如下： 
 
1.创建HystrixCommand或者HystrixObservableCommand对象。用来表示对以来服务的请求操作。从命名就能看的出来，使用的是命令模式，其中HystrixCommand返回的是单个操作结果，HystrixObservableCommand返回多个结果
 2.命令执行，共有4中方法执行命令： 
execute():用户执行，从依赖的服务里返回单个结果或抛出异常
queue（）：异步执行，直接返回一个Future对象
observe（）：放回observable对象，代表了多个结果，是一个Hot Observable
toObservable（）：返回Observable对象，但是是一个 Cold Observable（Hystrix大量的使用了RxJava，想更容易的理解Hystrix的，请自行百度RxJava进行阅读。）
3.结果是否被缓存。如果已经启用了缓存功能，且被命中，那么缓存就会直接以Observable对象返回
 4.断路器是否已打开，没有命中缓存，在执行命令前会检查断路器是否已打开： 
断路器已打开，直接执行fallback
断路器关闭，继续往下执行
5.线程池And信号量Or请求队列是否已被占满    如果与该命令有关的线程池和请求队列，或者信号量已经被占满，就直接执行fallback
 6.执行HystrixObservableCommand.construct （） 或 HystrixCommand.run（）  方法。如果设置了当前执行时间超过了设置的timeout，则当前处理线程会抛出一个TimeoutyException，如果命令不在自身线程里执行，就会通过单独的计时线程来抛出异常，Hystrix会直接执行fallback逻辑，并忽略run或construct的返回值。
 7.计算断路器的健康值。
 8.fallback处理。
 9.返回成功的响应。 
四、仪表盘讲解 
Spring Cloud Hystrix Dashboard是一个可以监控HystrixCommand的可视化图形界面，由于某种原因，如网络延迟、服务故障等，这时候可以借助dashboard提供的可视化界面监控各个Hystrix执行的成功率、调用成功数、失败数量、最近十分钟的流量图等等，根据这些数据我们就可以进行错误排查以及进行服务的优化等。Hystrix Dashboard只能对单个服务进行监控，实际项目中，服务通常集群部署，这时候可以借助Turbine进行多个服务的监控。 
（一）监控单体应用 
不管是监控单体应用还是Turbine集群监控，我们都需要一个Hystrix Dashboard，当然我们可以在要监控的单体应用上继续添加功能，让它也具备仪表盘的功能，但是这样并不符合我们微服务的思想，所以，Hystrix仪表盘我还是单独创建一个新的工程专门用来做Hystrix Dashboard。Hystrix Dashboard仪表盘是根据系统一段时间内发生的请求情况来展示的可视化面板，这些信息时每个HystrixCommand执行过程中的信息，这些信息是一个指标集合和具体的系统运行情况。如Hystrix Dashboard界面图：        
 
输入相关数据，得到如下仪表盘：     
 
（二）Turbine集群监控 
在实际应用中，我们要监控的应用往往是一个集群，这个时候我们就得采取Turbine集群监控了。Turbine有一个重要的功能就是汇聚监控信息，并将汇聚到的监控信息提供给Hystrix Dashboard来集中展示和监控。 
 
在实际项目中，这种实时监控有点耗性能，通常采用消息中间件如RabbitMQ等，我们接口调用把Hystrix的一些信息收集到RabbitMQ中，然后Turbine从RabbitMQ中获取监控的数据。 
五、Spring Cloud Hystrix配置说明 
以下的属性都是spring cloud 1.5.9版本的。 
1.Execution相关的属性的配置： 
 hystrix.command.default.execution.isolation.strategy 隔离策略，默认是Thread, 可选Thread｜Semaphore
 
 hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds 命令执行超时时间，默认1000ms
 
hystrix.command.default.execution.timeout.enabled 执行是否启用超时，默认启用true
hystrix.command.default.execution.isolation.thread.interruptOnTimeout 发生超时是是否中断，默认true
hystrix.command.default.execution.isolation.semaphore.maxConcurrentRequests 最大并发请求数，默认10，该参数当使用ExecutionIsolationStrategy.SEMAPHORE策略时才有效。如果达到最大并发请求数，请求会被拒绝。理论上选择semaphore size的原则和选择thread size一致，但选用semaphore时每次执行的单元要比较小且执行速度快（ms级别），否则的话应该用thread。
 semaphore应该占整个容器（tomcat）的线程池的一小部分。
2.Fallback相关的属性 
这些参数可以应用于Hystrix的THREAD和SEMAPHORE策略 
hystrix.command.default.fallback.isolation.semaphore.maxConcurrentRequests 如果并发数达到该设置值，请求会被拒绝和抛出异常并且fallback不会被调用。默认10
hystrix.command.default.fallback.enabled 当执行失败或者请求被拒绝，是否会尝试调用hystrixCommand.getFallback() 。默认true
3.Circuit Breaker相关的属性 
hystrix.command.default.circuitBreaker.enabled 用来跟踪circuit的健康性，如果未达标则让request短路。默认true。
hystrix.command.default.circuitBreaker.requestVolumeThreshold 一个rolling window内最小的请求数。如果设为20，那么当一个rolling window的时间内（比如说1个rolling window是10秒）收到19个请求，即使19个请求都失败，也不会触发circuit break。默认20。这个参数非常重要，熔断器是否打开首先要满足这个条件。
hystrix.command.default.circuitBreaker.sleepWindowInMilliseconds 触发短路的时间值，当该值设为5000时，则当触发circuit break后的5000毫秒内都会拒绝request，也就是5000毫秒后才会关闭circuit。默认5000
hystrix.command.default.circuitBreaker.errorThresholdPercentage错误比率阀值，如果错误率>=该值，circuit会被打开，并短路所有请求触发fallback。默认50
hystrix.command.default.circuitBreaker.forceOpen 强制打开熔断器，如果打开这个开关，那么拒绝所有request，默认false
hystrix.command.default.circuitBreaker.forceClosed 强制关闭熔断器 如果这个开关打开，circuit将一直关闭且忽略circuitBreaker.errorThresholdPercentage
4.Metrics相关参数 
hystrix.command.default.metrics.rollingStats.timeInMilliseconds 设置统计的时间窗口值的，毫秒值，circuit break 的打开会根据1个rolling window的统计来计算。若rolling window被设为10000毫秒，则rolling window会被分成n个buckets，每个bucket包含success，failure，timeout，rejection的次数的统计信息。默认10000
hystrix.command.default.metrics.rollingStats.numBuckets 设置一个rolling window被划分的数量，若numBuckets＝10，rolling window＝10000，那么一个bucket的时间即1秒。必须符合rolling window % numberBuckets == 0。默认10
hystrix.command.default.metrics.rollingPercentile.enabled 执行时是否enable指标的计算和跟踪，默认true
hystrix.command.default.metrics.rollingPercentile.timeInMilliseconds 设置rolling percentile window的时间，默认60000
hystrix.command.default.metrics.rollingPercentile.numBuckets 设置rolling percentile window的numberBuckets。逻辑同上。默认6
hystrix.command.default.metrics.rollingPercentile.bucketSize 如果bucket size＝100，window＝10s，若这10s里有500次执行，只有最后100次执行会被统计到bucket里去。增加该值会增加内存开销以及排序的开销。默认100
hystrix.command.default.metrics.healthSnapshot.intervalInMilliseconds 记录health 快照（用来统计成功和错误绿）的间隔，默认500ms
5.Request Context 相关参数 
hystrix.command.default.requestCache.enabled 默认true，需要重载getCacheKey()，返回null时不缓存
 hystrix.command.default.requestLog.enabled 记录日志到HystrixRequestLog，默认true 
6.Collapser Properties 相关参数 
hystrix.collapser.default.maxRequestsInBatch 单次批处理的最大请求数，达到该数量触发批处理，默认Integer.MAX_VALUE
 hystrix.collapser.default.timerDelayInMilliseconds 触发批处理的延迟，也可以为创建批处理的时间＋该值，默认10
 hystrix.collapser.default.requestCache.enabled 是否对HystrixCollapser.execute() and HystrixCollapser.queue()的cache，默认true 
7.ThreadPool 相关参数 
线程数默认值10适用于大部分情况（有时可以设置得更小），如果需要设置得更大，那有个基本得公式可以follow：
 requests per second at peak when healthy × 99th percentile latency in seconds + some breathing room
 每秒最大支撑的请求数 (99%平均响应时间 + 缓存值)
 比如：每秒能处理1000个请求，99%的请求响应时间是60ms，那么公式是：
 1000 （0.060+0.012） 
基本得原则时保持线程池尽可能小，他主要是为了释放压力，防止资源被阻塞。
 当一切都是正常的时候，线程池一般仅会有1到2个线程激活来提供服务 
hystrix.threadpool.default.coreSize 并发执行的最大线程数，默认10
hystrix.threadpool.default.maxQueueSize BlockingQueue的最大队列数，当设为－1，会使用SynchronousQueue，值为正时使用LinkedBlcokingQueue。该设置只会在初始化时有效，之后不能修改threadpool的queue size，除非reinitialising thread executor。默认－1。
hystrix.threadpool.default.queueSizeRejectionThreshold 即使maxQueueSize没有达到，达到queueSizeRejectionThreshold该值后，请求也会被拒绝。因为maxQueueSize不能被动态修改，这个参数将允许我们动态设置该值。if maxQueueSize == -1，该字段将不起作用
hystrix.threadpool.default.keepAliveTimeMinutes 如果corePoolSize和maxPoolSize设成一样（默认实现）该设置无效。如果通过plugin（https://github.com/Netflix/Hystrix/wiki/Plugins）使用自定义实现，该设置才有用，默认1.
hystrix.threadpool.default.metrics.rollingStats.timeInMilliseconds 线程池统计指标的时间，默认10000
hystrix.threadpool.default.metrics.rollingStats.numBuckets 将rolling window划分为n个buckets，默认10
六、Spring Cloud Hystrix线程调整和计算 
在实际使用过程中会涉及多个微服务，可能有些微服务使用的线程池过大，有些服务使用的线程池小，有些服务的超时时间长，有的短，所以Hystrix官方也提供了一些方法供我们来计算和调整这些配置，总的宗旨是，通过自我预判的配置先发布到生产或测试，然后查看它具体的运行情况，在调整为更符合业务的配置，通常做法有： 
1.超过时间默认为1000ms，如果业务明显超过1000ms，则根据自己的业务进行修改。 
2.线程池默认10，如果知道确实要使用更多时可以调整。 
3.金丝雀发布，如果成功则保持。 
4.在生产环境中运行超过24小时。 
5.如果系统有告警和监控，那么可以依靠他们捕捉问题。 
6.运行24小时后，通过延时百分位和流量来计算有意义的最低满足值。 
7.在生产或测试环境中实时修改值，然后用仪表盘监控。 
8.如果断路器产生变化和影响，则需要再次确认这个配置。                              
 
官方例子如图，Threadpool的大小为10，如下计算公式： 
每秒请求的峰值 X 99%的延迟百分比（请求响应的时间）+ 预留缓存的值 
即 30 x 0.2s  = 6 + 预留缓存的值 = 10 ，这里预留了4个线程数。 
Thread Timeout：预留了一个足够的时间，250ms，然后加上重试一次的中位数值。 
Connect Timeout & Read Timeout：100ms和250ms，这两个值的设置方法远高于中位数值，以适应大多数请求。 
在实际的生产测试过程中，配置每个服务时可以根据官方推荐的这些方法来测试自己的业务需要的数值，这样产生最合适的配置。 
七、Spring Cloud Hystrix源码分析 
Spring Cloud Hystrix的使用：  
1.启动类添加@EnableHystrix注解。 
2.方法上添加@HystrixCommand注解，并指定fallback的方法。
查看@EnableHystrix注解 
/**
 * Convenience annotation for clients to enable Hystrix circuit breakers (specifically).
 * Use this (optionally) in case you want discovery and know for sure that it is Hystrix
 * you want. All it does is turn on circuit breakers and let the autoconfiguration find
 * the Hystrix classes if they are available (i.e. you need Hystrix on the classpath as
 * well).
 *
 * @author Dave Syer
 * @author Spencer Gibb
 */
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Inherited
@EnableCircuitBreaker
public @interface EnableHystrix {
} 
这个注解的功能就是开启Hystrix。这个注解还引入了@EnableCircuitBreaker注解。 
在代码同一级目录下，还可以看到两个配置类：HystrixAutoConfiguration和HystrixCircuitBreakerConfiguration。 
 下面是HystrixAutoConfiguration配置类的配置： 
@Configuration
@ConditionalOnClass({ Hystrix.class, HealthIndicator.class })
@AutoConfigureAfter({ HealthIndicatorAutoConfiguration.class })
public class HystrixAutoConfiguration {

    @Bean
    @ConditionalOnEnabledHealthIndicator("hystrix")
    public HystrixHealthIndicator hystrixHealthIndicator() {
        return new HystrixHealthIndicator();
    }
} 
从代码中可以看到，HystrixAutoConfiguration这个配置类主要是hystrix的健康检查的配置。再看下HystrixCircuitBreakerConfiguration这个类，这个类里面就配置了很多内容。 
@Bean
public HystrixCommandAspect hystrixCommandAspect() {
    return new HystrixCommandAspect();
} 
这里返回了HystrixCommandAspect的bean，这个切面中定义了Pointcut： 
@Pointcut("@annotation(com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand)")
public void hystrixCommandAnnotationPointcut() {
}

@Pointcut("@annotation(com.netflix.hystrix.contrib.javanica.annotation.HystrixCollapser)")
public void hystrixCollapserAnnotationPointcut() {
} 
所以，这个Aspect就是利用AOP切面对 HystrixCommand 、 HystrixCollapser 两种注解的方法进行扩展处理。 
 我们在方法上添加@HystrixCommand注解，就会经过这个切面，这个切面中定义了@Around(…)拦截所有请求。 
下面看下这个方法： 
@Around("hystrixCommandAnnotationPointcut() || hystrixCollapserAnnotationPointcut()")
public Object methodsAnnotatedWithHystrixCommand(final ProceedingJoinPoint joinPoint) throws Throwable {
    Method method = getMethodFromTarget(joinPoint);
    Validate.notNull(method, "failed to get method from joinPoint: %s", joinPoint);
    if (method.isAnnotationPresent(HystrixCommand.class) && method.isAnnotationPresent(HystrixCollapser.class)) {
        throw new IllegalStateException("method cannot be annotated with HystrixCommand and HystrixCollapser " +
                "annotations at the same time");
    }
    MetaHolderFactory metaHolderFactory = META_HOLDER_FACTORY_MAP.get(HystrixPointcutType.of(method));
    MetaHolder metaHolder = metaHolderFactory.create(joinPoint);
    HystrixInvokable invokable = HystrixCommandFactory.getInstance().create(metaHolder);
    ExecutionType executionType = metaHolder.isCollapserAnnotationPresent() ?
            metaHolder.getCollapserExecutionType() : metaHolder.getExecutionType();
    Object result;
    try {
        result = CommandExecutor.execute(invokable, executionType, metaHolder);
    } catch (HystrixBadRequestException e) {
        throw e.getCause();
    }
    return result;
} 
这个方法中，一开始先获取拦截的Method，然后判断，如果方法上同时加了@HystrixCommand和@HystrixCollapser两个注解的话，就抛异常。 
 在创建MetaHolder的时候，调用了MetaHolderFactory的create方法，MetaHolderFactory有两个子类，CollapserMetaHolderFactory和CommandMetaHolderFactory，最终执行的是子类的create方法，下面是CommandMetaHolderFactory中的create方法： 
private static class CommandMetaHolderFactory extends MetaHolderFactory {
    @Override
    public MetaHolder create(Object proxy, Method method, Object obj, Object[] args, final ProceedingJoinPoint joinPoint) {
        HystrixCommand hystrixCommand = method.getAnnotation(HystrixCommand.class);
        ExecutionType executionType = ExecutionType.getExecutionType(method.getReturnType());
        MetaHolder.Builder builder = metaHolderBuilder(proxy, method, obj, args, joinPoint);
        return builder.defaultCommandKey(method.getName())
                        .hystrixCommand(hystrixCommand)
                        .observableExecutionMode(hystrixCommand.observableExecutionMode())
                        .executionType(executionType)
                        .observable(ExecutionType.OBSERVABLE == executionType)
                        .build();
    }
} 
MetaHolder.Builder metaHolderBuilder(Object proxy, Method method, Object obj, Object[] args, final ProceedingJoinPoint joinPoint) {
    MetaHolder.Builder builder = MetaHolder.builder()
            .args(args).method(method).obj(obj).proxyObj(proxy)
            .defaultGroupKey(obj.getClass().getSimpleName())
            .joinPoint(joinPoint);
    if (isCompileWeaving()) {
        builder.ajcMethod(getAjcMethodFromTarget(joinPoint));
    }

    FallbackMethod fallbackMethod = MethodProvider.getInstance().getFallbackMethod(obj.getClass(), method);
    if (fallbackMethod.isPresent()) {
        fallbackMethod.validateReturnType(method);
        builder
                .fallbackMethod(fallbackMethod.getMethod())
                .fallbackExecutionType(ExecutionType.getExecutionType(fallbackMethod.getMethod().getReturnType()));
    }
    return builder;
} 
在创建MetaHolder的过程中，就会指定fallback方法。 
 创建完MetaHolder之后，就会根据MetaHolder创建HystrixInvokable。 
public HystrixInvokable create(MetaHolder metaHolder) {
    HystrixInvokable executable;
    if (metaHolder.isCollapserAnnotationPresent()) {
        executable = new CommandCollapser(metaHolder);
    } else if (metaHolder.isObservable()) {
        executable = new GenericObservableCommand(HystrixCommandBuilderFactory.getInstance().create(metaHolder));
    } else {
        executable = new GenericCommand(HystrixCommandBuilderFactory.getInstance().create(metaHolder));
    }
    return executable;
} 
这段代码里定义了后续真正执行HystrixCommand的GenericCommand实例 
方法最终会去执行CommandExecutor.execute方法： 
public static Object execute(HystrixInvokable invokable, ExecutionType executionType, MetaHolder metaHolder) throws RuntimeException {
    Validate.notNull(invokable);
    Validate.notNull(metaHolder);

    switch (executionType) {
        case SYNCHRONOUS: {
            return castToExecutable(invokable, executionType).execute();
        }
        case ASYNCHRONOUS: {
            HystrixExecutable executable = castToExecutable(invokable, executionType);
            if (metaHolder.hasFallbackMethodCommand()
                    && ExecutionType.ASYNCHRONOUS == metaHolder.getFallbackExecutionType()) {
                return new FutureDecorator(executable.queue());
            }
            return executable.queue();
        }
        case OBSERVABLE: {
            HystrixObservable observable = castToObservable(invokable);
            return ObservableExecutionMode.EAGER == metaHolder.getObservableExecutionMode() ? observable.observe() : observable.toObservable();
        }
        default:
            throw new RuntimeException("unsupported execution type: " + executionType);
    }
} 
这里会分成同步和异步的场景，进入execute方法看下： 
/**
 * Used for synchronous execution of command.
 * 
 * @return R
 *         Result of {@link #run()} execution or a fallback from {@link #getFallback()} if the command fails for any reason.
 * @throws HystrixRuntimeException
 *             if a failure occurs and a fallback cannot be retrieved
 * @throws HystrixBadRequestException
 *             if invalid arguments or state were used representing a user failure, not a system failure
 * @throws IllegalStateException
 *             if invoked more than once
 */
public R execute() {
    try {
        return queue().get();
    } catch (Exception e) {
        throw decomposeException(e);
    }
} 
这个方法的注释中说明了返回值，可以返回请求的结果，当失败的时候，则会通过getFallback()方法来执行一个回退操作，由于是GenericCommand实例，那就看下这个实例中的getFallback()方法： 
@Override
protected Object getFallback() {
    if (getFallbackAction() != null) {
        final CommandAction commandAction = getFallbackAction();
        try {
            return process(new Action() {
                @Override
                Object execute() {
                    MetaHolder metaHolder = commandAction.getMetaHolder();
                    Object[] args = createArgsForFallback(metaHolder, getExecutionException());
                    return commandAction.executeWithArgs(commandAction.getMetaHolder().getFallbackExecutionType(), args);
                }
            });
        } catch (Throwable e) {
            LOGGER.error(FallbackErrorMessageBuilder.create()
                    .append(commandAction, e).build());
            throw new FallbackInvocationException(e.getCause());
        }
    } else {
        return super.getFallback();
    }
} 
大体的一个流程也就知道了，就是通过HystrixCommandAspect，请求成功返回接口的结果，请求失败执行fallback的逻辑。 
参考书籍、文献和资料： 
【1】徐进，叶志远，钟尊发，蔡波斯等. 重新定义Spring Cloud. 北京：机械工业出版社. 2018. 
【2】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018. 
【3】王新栋.架构修炼之道.北京：电子工业出版社，2019. 
【4】https://blog.csdn.net/hzq472583006/article/details/81110443. 
【5】https://www.cnblogs.com/niechen/p/8513597.html. 
【6】https://blog.csdn.net/lij231/article/details/82956455. 
【7】https://blog.csdn.net/chayangdz/article/details/82561158. 
【8】https://segmentfault.com/a/1190000011478978?utm_source=tag-newest. 
【9】https://blog.csdn.net/Weixiaohuai/article/details/82699125. 
【10】https://www.cnblogs.com/huangjuncong/p/9043844.html. 
【11】https://blog.csdn.net/chengqiuming/article/details/81151734. 
【12】https://www.cnblogs.com/huangjuncong/p/9043844.html.

收起

展开全文

Spring Cloud面试题（2020最新版）

万次阅读 多人点赞 2020-02-19 17:51:59

文章目录为什么需要学习Spring Cloud什么是Spring Cloud设计目标与优缺点设计目标优缺点Spring Cloud发展前景整体架构主要项目Spring Cloud ConfigSpring Cloud NetflixSpring Cloud BusSpring Cloud ConsulSpring ...

Java面试总结（2021优化版）已发布在个人微信公众号【技术人成长之路】，优化版首先修正了读者反馈的部分答案存在的错误，同时根据最新面试总结，删除了低频问题，添加了一些常见面试题，对文章进行了精简优化，欢迎大家关注！😊😊

【技术人成长之路】，助力技术人成长！更多精彩文章第一时间在公众号发布哦！

文章目录

Java面试总结汇总，整理了包括Java基础知识，集合容器，并发编程，JVM，常用开源框架Spring，MyBatis，数据库，中间件等，包含了作为一个Java工程师在面试中需要用到或者可能用到的绝大部分知识。欢迎大家阅读，本人见识有限，写的博客难免有错误或者疏忽的地方，还望各位大佬指点，在此表示感激不尽。文章持续更新中…

序号	内容	链接地址
1	Java基础知识面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104390612
2	Java集合容器面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104588551
3	Java异常面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104390689
4	并发编程面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104863992
5	JVM面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104390752
6	Spring面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397516
7	Spring MVC面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397427
8	Spring Boot面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397299
9	Spring Cloud面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397367
10	MyBatis面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/101292950
11	Redis面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/103522351
12	MySQL数据库面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104778621
13	消息中间件MQ与RabbitMQ面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104588612
14	Dubbo面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104390006
15	Linux面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104588679
16	Tomcat面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397665
17	ZooKeeper面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104397719
18	Netty面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/104391081
19	架构设计&分布式&数据结构与算法面试题（2020最新版）	https://thinkwon.blog.csdn.net/article/details/105870730

为什么需要学习Spring Cloud

不论是商业应用还是用户应用，在业务初期都很简单，我们通常会把它实现为单体结构的应用。但是，随着业务逐渐发展，产品思想会变得越来越复杂，单体结构的应用也会越来越复杂。这就会给应用带来如下的几个问题：

代码结构混乱：业务复杂，导致代码量很大，管理会越来越困难。同时，这也会给业务的快速迭代带来巨大挑战；
开发效率变低：开发人员同时开发一套代码，很难避免代码冲突。开发过程会伴随着不断解决冲突的过程，这会严重的影响开发效率；
排查解决问题成本高：线上业务发现 bug，修复 bug 的过程可能很简单。但是，由于只有一套代码，需要重新编译、打包、上线，成本很高。

由于单体结构的应用随着系统复杂度的增高，会暴露出各种各样的问题。近些年来，微服务架构逐渐取代了单体架构，且这种趋势将会越来越流行。Spring Cloud是目前最常用的微服务开发框架，已经在企业级开发中大量的应用。

什么是Spring Cloud

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、智能路由、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring Cloud并没有重复制造轮子，它只是将各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

设计目标与优缺点

设计目标

协调各个微服务，简化分布式系统开发。

优缺点

微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？

优点：

产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完善
组件丰富，功能齐全。Spring Cloud 为微服务架构提供了非常完整的支持。例如、配置管理、服务发现、断路器、微服务网关等；
Spring Cloud 社区活跃度很高，教程很丰富，遇到问题很容易找到解决方案
服务拆分粒度更细，耦合度比较低，有利于资源重复利用，有利于提高开发效率
可以更精准的制定优化服务方案，提高系统的可维护性
减轻团队的成本，可以并行开发，不用关注其他人怎么开发，先关注自己的开发
微服务可以是跨平台的，可以用任何一种语言开发
适于互联网时代，产品迭代周期更短

缺点：

微服务过多，治理成本高，不利于维护系统
分布式系统开发的成本高（容错，分布式事务等）对团队挑战大

总的来说优点大过于缺点，目前看来Spring Cloud是一套非常完善的分布式框架，目前很多企业开始用微服务、Spring Cloud的优势是显而易见的。因此对于想研究微服务架构的同学来说，学习Spring Cloud是一个不错的选择。

Spring Cloud发展前景

Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年微服务架构和Docker容器概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在五花八门的分布式解决方案中提供了标准化的、全站式的技术方案，意义可能会堪比当年Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。

整体架构

主要项目

Spring Cloud的子项目，大致可分成两类，一类是对现有成熟框架"Spring Boot化"的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色。

Spring Cloud Config

集中配置管理工具，分布式系统中统一的外部配置管理，默认使用Git来存储配置，可以支持客户端配置的刷新及加密、解密操作。

Spring Cloud Netflix

Netflix OSS 开源组件集成，包括Eureka、Hystrix、Ribbon、Feign、Zuul等核心组件。

Eureka：服务治理组件，包括服务端的注册中心和客户端的服务发现机制；
Ribbon：负载均衡的服务调用组件，具有多种负载均衡调用策略；
Hystrix：服务容错组件，实现了断路器模式，为依赖服务的出错和延迟提供了容错能力；
Feign：基于Ribbon和Hystrix的声明式服务调用组件；
Zuul：API网关组件，对请求提供路由及过滤功能。

Spring Cloud Bus

用于传播集群状态变化的消息总线，使用轻量级消息代理链接分布式系统中的节点，可以用来动态刷新集群中的服务配置。

Spring Cloud Consul

基于Hashicorp Consul的服务治理组件。

Spring Cloud Security

安全工具包，对Zuul代理中的负载均衡OAuth2客户端及登录认证进行支持。

Spring Cloud Sleuth

Spring Cloud应用程序的分布式请求链路跟踪，支持使用Zipkin、HTrace和基于日志（例如ELK）的跟踪。

Spring Cloud Stream

轻量级事件驱动微服务框架，可以使用简单的声明式模型来发送及接收消息，主要实现为Apache Kafka及RabbitMQ。

Spring Cloud Task

用于快速构建短暂、有限数据处理任务的微服务框架，用于向应用中添加功能性和非功能性的特性。

Spring Cloud Zookeeper

基于Apache Zookeeper的服务治理组件。

Spring Cloud Gateway

API网关组件，对请求提供路由及过滤功能。

Spring Cloud OpenFeign

基于Ribbon和Hystrix的声明式服务调用组件，可以动态创建基于Spring MVC注解的接口实现用于服务调用，在Spring Cloud 2.0中已经取代Feign成为了一等公民。

Spring Cloud的版本关系

Spring Cloud是一个由许多子项目组成的综合项目，各子项目有不同的发布节奏。为了管理Spring Cloud与各子项目的版本依赖关系，发布了一个清单，其中包括了某个Spring Cloud版本对应的子项目版本。为了避免Spring Cloud版本号与子项目版本号混淆，Spring Cloud版本采用了名称而非版本号的命名，这些版本的名字采用了伦敦地铁站的名字，根据字母表的顺序来对应版本时间顺序，例如Angel是第一个版本，Brixton是第二个版本。当Spring Cloud的发布内容积累到临界点或者一个重大BUG被解决后，会发布一个"service releases"版本，简称SRX版本，比如Greenwich.SR2就是Spring Cloud发布的Greenwich版本的第2个SRX版本。目前Spring Cloud的最新版本是Hoxton。

Spring Cloud和SpringBoot版本对应关系

Spring Cloud Version	SpringBoot Version
Hoxton	2.2.x
Greenwich	2.1.x
Finchley	2.0.x
Edgware	1.5.x
Dalston	1.5.x

Spring Cloud和各子项目版本对应关系

Component	Edgware.SR6	Greenwich.SR2
spring-cloud-bus	1.3.4.RELEASE	2.1.2.RELEASE
spring-cloud-commons	1.3.6.RELEASE	2.1.2.RELEASE
spring-cloud-config	1.4.7.RELEASE	2.1.3.RELEASE
spring-cloud-netflix	1.4.7.RELEASE	2.1.2.RELEASE
spring-cloud-security	1.2.4.RELEASE	2.1.3.RELEASE
spring-cloud-consul	1.3.6.RELEASE	2.1.2.RELEASE
spring-cloud-sleuth	1.3.6.RELEASE	2.1.1.RELEASE
spring-cloud-stream	Ditmars.SR5	Fishtown.SR3
spring-cloud-zookeeper	1.2.3.RELEASE	2.1.2.RELEASE
spring-boot	1.5.21.RELEASE	2.1.5.RELEASE
spring-cloud-task	1.2.4.RELEASE	2.1.2.RELEASE
spring-cloud-gateway	1.0.3.RELEASE	2.1.2.RELEASE
spring-cloud-openfeign	暂无	2.1.2.RELEASE

注意：Hoxton版本是基于SpringBoot 2.2.x版本构建的，不适用于1.5.x版本。随着2019年8月SpringBoot 1.5.x版本停止维护，Edgware版本也将停止维护。

SpringBoot和SpringCloud的区别？

SpringBoot专注于快速方便的开发单个个体微服务。

SpringCloud是关注全局的微服务协调整理治理框架，它将SpringBoot开发的一个个单体微服务整合并管理起来，

为各个微服务之间提供，配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等集成服务

SpringBoot可以离开SpringCloud独立使用开发项目，但是SpringCloud离不开SpringBoot ，属于依赖的关系

SpringBoot专注于快速、方便的开发单个微服务个体，SpringCloud关注全局的服务治理框架。

使用 Spring Boot 开发分布式微服务时，我们面临以下问题

（1）与分布式系统相关的复杂性-这种开销包括网络问题，延迟开销，带宽问题，安全问题。

（2）服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录，在该目录中注册服务，然后能够查找并连接到该目录中的服务。

（3）冗余-分布式系统中的冗余问题。

（4）负载平衡 --负载平衡改善跨多个计算资源的工作负荷，诸如计算机，计算机集群，网络链路，中央处理单元，或磁盘驱动器的分布。

（5）性能-问题由于各种运营开销导致的性能问题。

（6）部署复杂性-Devops 技能的要求。

服务注册和发现是什么意思？Spring Cloud 如何实现？

当我们开始一个项目时，我们通常在属性文件中进行所有的配置。随着越来越多的服务开发和部署，添加和修改这些属性变得更加复杂。有些服务可能会下降，而某些位置可能会发生变化。手动更改属性可能会产生问题。 Eureka 服务注册和发现可以在这种情况下提供帮助。由于所有服务都在 Eureka 服务器上注册并通过调用 Eureka 服务器完成查找，因此无需处理服务地点的任何更改和处理。

Spring Cloud 和dubbo区别?

（1）服务调用方式 dubbo是RPC springcloud Rest Api

（2）注册中心,dubbo 是zookeeper springcloud是eureka，也可以是zookeeper

（3）服务网关,dubbo本身没有实现，只能通过其他第三方技术整合，springcloud有Zuul路由网关，作为路由服务器，进行消费者的请求分发,springcloud支持断路器，与git完美集成配置文件支持版本控制，事物总线实现配置文件的更新与服务自动装配等等一系列的微服务架构要素。

负载平衡的意义什么？

在计算中，负载平衡可以改善跨计算机，计算机集群，网络链接，中央处理单元或磁盘驱动器等多种计算资源的工作负载分布。负载平衡旨在优化资源使用，最大化吞吐量，最小化响应时间并避免任何单一资源的过载。使用多个组件进行负载平衡而不是单个组件可能会通过冗余来提高可靠性和可用性。负载平衡通常涉及专用软件或硬件，例如多层交换机或域名系统服务器进程。

什么是 Hystrix？它如何实现容错？

Hystrix 是一个延迟和容错库，旨在隔离远程系统，服务和第三方库的访问点，当出现故障是不可避免的故障时，停止级联故障并在复杂的分布式系统中实现弹性。

通常对于使用微服务架构开发的系统，涉及到许多微服务。这些微服务彼此协作。

思考以下微服务

假设如果上图中的微服务 9 失败了，那么使用传统方法我们将传播一个异常。但这仍然会导致整个系统崩溃。

随着微服务数量的增加，这个问题变得更加复杂。微服务的数量可以高达 1000.这是 hystrix 出现的地方我们将使用 Hystrix 在这种情况下的 Fallback 方法功能。我们有两个服务 employee-consumer 使用由 employee-consumer 公开的服务。

简化图如下所示

现在假设由于某种原因，employee-producer 公开的服务会抛出异常。我们在这种情况下使用 Hystrix 定义了一个回退方法。这种后备方法应该具有与公开服务相同的返回类型。如果暴露服务中出现异常，则回退方法将返回一些值。

什么是 Hystrix 断路器？我们需要它吗？

由于某些原因，employee-consumer 公开服务会引发异常。在这种情况下使用Hystrix 我们定义了一个回退方法。如果在公开服务中发生异常，则回退方法返回一些默认值。

如果 firstPage method() 中的异常继续发生，则 Hystrix 电路将中断，并且员工使用者将一起跳过 firtsPage 方法，并直接调用回退方法。断路器的目的是给第一页方法或第一页方法可能调用的其他方法留出时间，并导致异常恢复。可能发生的情况是，在负载较小的情况下，导致异常的问题有更好的恢复机会。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nMSJX6ml-1582105816943)(https://user-gold-cdn.xitu.io/2019/12/30/16f55fbfd4e33ae7?imageView2/0/w/1280/h/960/format/webp/ignore-error/1)]

什么是 Netflix Feign？它的优点是什么？

Feign 是受到 Retrofit，JAXRS-2.0 和 WebSocket 启发的 java 客户端联编程序。

Feign 的第一个目标是将约束分母的复杂性统一到 http apis，而不考虑其稳定性。

在 employee-consumer 的例子中，我们使用了 employee-producer 使用 REST模板公开的 REST 服务。

但是我们必须编写大量代码才能执行以下步骤

（1）使用功能区进行负载平衡。

（2）获取服务实例，然后获取基本 URL。

（3）利用 REST 模板来使用服务。前面的代码如下

@Controller
public class ConsumerControllerClient {
@Autowired
private LoadBalancerClient loadBalancer;
public void getEmployee() throws RestClientException, IOException {
	ServiceInstance serviceInstance=loadBalancer.choose("employee-producer");
	System.out.println(serviceInstance.getUri());
	String baseUrl=serviceInstance.getUri().toString();
	baseUrl=baseUrl+"/employee";
	RestTemplate restTemplate = new RestTemplate();
	ResponseEntity<String> response=null;
	try{
		response=restTemplate.exchange(baseUrl,
					HttpMethod.GET, getHeaders(),String.class);
	}
	catch (Exception ex)
		{
		System.out.println(ex);
	}
	System.out.println(response.getBody());
}

之前的代码，有像 NullPointer 这样的例外的机会，并不是最优的。我们将看到如何使用 Netflix Feign 使呼叫变得更加轻松和清洁。如果 Netflix Ribbon 依赖关系也在类路径中，那么 Feign 默认也会负责负载平衡。

什么是 Spring Cloud Bus？我们需要它吗？

考虑以下情况：我们有多个应用程序使用 Spring Cloud Config 读取属性，而Spring Cloud Config 从 GIT 读取这些属性。

下面的例子中多个员工生产者模块从 Employee Config Module 获取 Eureka 注册的财产。

如果假设 GIT 中的 Eureka 注册属性更改为指向另一台 Eureka 服务器，会发生什么情况。在这种情况下，我们将不得不重新启动服务以获取更新的属性。

还有另一种使用执行器端点/刷新的方式。但是我们将不得不为每个模块单独调用这个 url。例如，如果 Employee Producer1 部署在端口 8080 上，则调用 http：// localhost：8080 / refresh。同样对于 Employee Producer2 http：//localhost：8081 / refresh 等等。这又很麻烦。这就是 Spring Cloud Bus 发挥作用的地方。

Spring Cloud Bus 提供了跨多个实例刷新配置的功能。因此，在上面的示例中，如果我们刷新 Employee Producer1，则会自动刷新所有其他必需的模块。如果我们有多个微服务启动并运行，这特别有用。这是通过将所有微服务连接到单个消息代理来实现的。无论何时刷新实例，此事件都会订阅到侦听此代理的所有微服务，并且它们也会刷新。可以通过使用端点/总线/刷新来实现对任何单个实例的刷新。

Spring Cloud断路器的作用

当一个服务调用另一个服务由于网络原因或自身原因出现问题，调用者就会等待被调用者的响应当更多的服务请求到这些资源导致更多的请求等待，发生连锁效应（雪崩效应）

断路器有完全打开状态:一段时间内达到一定的次数无法调用并且多次监测没有恢复的迹象断路器完全打开那么下次请求就不会请求到该服务

半开:短时间内有恢复迹象断路器会将部分请求发给该服务，正常调用时断路器关闭

关闭：当服务一直处于正常状态能正常调用

什么是Spring Cloud Config?

在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要分布式配置中心组件。在Spring Cloud中，有分布式配置中心组件spring cloud config ，它支持配置服务放在配置服务的内存中（即本地），也支持放在远程Git仓库中。在spring cloud config 组件中，分两个角色，一是config server，二是config client。

使用：

（1）添加pom依赖

（2）配置文件添加相关配置

（3）启动类添加注解@EnableConfigServer

什么是Spring Cloud Gateway?

Spring Cloud Gateway是Spring Cloud官方推出的第二代网关框架，取代Zuul网关。网关作为流量的，在微服务系统中有着非常作用，网关常见的功能有路由转发、权限校验、限流控制等作用。

使用了一个RouteLocatorBuilder的bean去创建路由，除了创建路由RouteLocatorBuilder可以让你添加各种predicates和filters，predicates断言的意思，顾名思义就是根据具体的请求的规则，由具体的route去处理，filters是各种过滤器，用来对请求做各种判断和修改。

收起

展开全文

史上最简单的 SpringCloud 教程 | 第一篇：服务的注册与发现（Eureka）
万次阅读 多人点赞 2017-04-08 18:16:57
spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。另外说明...
收起
java 分布式 spring
史上最简单的SpringCloud教程 | 第六篇: 分布式配置中心(Spring Cloud Config)
万次阅读 多人点赞 2017-04-10 21:18:06
简介在分布式系统中，spring cloud config 提供一个服务端和客户端去提供可扩展的配置服务。我们可用用配置服务中心区集中的管理所有的服务的各种环境配置文件。配置服务中心采用git的方式存储配置文件，因此我们很...
收起
java 微服务分布式 spring
史上最简单的 SpringCloud 教程 | 第一篇：服务的注册与发现Eureka(Finchley版本)
万次阅读 多人点赞 2018-07-14 10:04:27
转载请标明出处： ... 本文出自方志朋的博客 ...鉴于《史上最简单的Spring Cloud教程》很受读者欢迎，再次我特意升级了一下版本，目前支持的版本为Spring Boot版本2.0.3.RELEASE,Spring Cloud版本为F...
收起
SpringCloud从入门到精通教程/SpringCloud Alibaba从入门到精通教程
万次阅读 多人点赞 2019-08-01 19:40:58
对于SpringCloud，很多小伙伴问到了我的研究学习资料来源，除官方文档外，特例完整整理一下自己的平时参考学习其他资料，以及分享实战项目源码和代码资源，供大家参考学习主要教程：SpringCloud教程 Spring ...
收起
微服务教程
史上最简单的SpringCloud教程 | 第八篇: 消息总线(Spring Cloud Bus)
万次阅读 多人点赞 2017-04-12 22:15:48
Spring Cloud Bus 将分布式的节点和轻量的消息代理连接起来。这可以用于广播配置文件的更改或者其他的管理工作。一个关键的思想就是，消息总线可以为微服务做监控，也可以作为应用程序之间相互通讯。本文要讲述的是...
收起
spring java 微服务分布式
Spring Cloud原理详解
万次阅读 多人点赞 2018-11-07 18:41:01
毫无疑问，Spring Cloud是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。不过大多数讲解还停留在对Spring Cloud功能使用的层面，其底层的很多原理，很多人可能并不知晓。因此本文将通过大量的手绘图，...
收起
SpringCloud Alibaba完整使用
万次阅读 多人点赞 2019-09-18 15:05:40
搭建AlibabaCloud 首先搭建几个环境全部在Linux下 1、nacos 注册中心 2、sentinel 流量控制，断路 3、apache-skywalking-apm-bin 监控接口的速度、效率等等 4、Rocketmq 的使用项目如下在这里插入代码片首先...
收起
java后端微服务
SpringBoot与SpringCloud的版本对应详细版
万次阅读 多人点赞 2019-04-18 11:50:50
初学spring cloud的朋友可能不知道，其实SpringBoot与SpringCloud需要版本对应，否则可能会造成很多意料之外的错误，比如eureka注册了结果找不到服务类啊，比如某些jar导入不进来啊，等等这些错误。下面列出来...
收起
Spring cloud多模块开发下Feign的使用，以及@FeignClient注入bean找不到异常解决
万次阅读 多人点赞 2018-08-19 23:17:07
在微服务架构开发是，我们常常会在一个项目中调用其他服务，其实使用Spring Cloud Rbbon就能实现这个需求，利用RestTemplate 的请求拦截来实现对依赖服务的接口调用，但是实际项目中对服务依赖的调用可能不止于一 ...
收起
Spring Feign 多模块异常
SpringCloud详细教程(下)
万次阅读 多人点赞 2018-11-16 19:11:00
SpringCloud详细教程，springcloud完全教程。Springcloud微服务教程（上）的姊妹篇:介绍了其它SpringCloud组件。
收起
Spring Cloud入门-十分钟了解Spring Cloud
万次阅读 多人点赞 2019-12-26 14:42:06
文章目录为什么需要学习Spring Cloud什么是Spring Cloud设计目标与优缺点设计目标优缺点Spring Cloud发展前景整体架构主要项目Spring Cloud ConfigSpring Cloud NetflixSpring Cloud BusSpring Cloud ConsulSpring ...
收起
史上最简单的SpringCloud教程 | 第九篇: 服务链路追踪(Spring Cloud Sleuth)
万次阅读 多人点赞 2017-04-13 21:03:29
这篇文章主要讲述服务追踪组件zipkin，Spring Cloud Sleuth集成了zipkin组件。
收起
spring 应用 maven gradle
Spring Cloud - 2 (Spring Cloud Config Server)
万次阅读 2019-07-21 20:42:56
构建Spring Cloud配置服务器实现步骤： 1. 在Configuration Class标记@EnableConfigServer 2. 配置文件目录（基于git） cloud.properties(默认) //默认环境，跟随代码仓库 cloud-dev.properties(proflie=...
收起
spring restful
史上最简单的SpringCloud教程 | 第六篇: 分布式配置中心(Spring Cloud Config)(Finchley版本)
万次阅读 多人点赞 2018-07-14 10:13:10
转载请标明出处： ... 本文出自方志朋的博客在上一篇文章讲述zuul的时候，已经...它就是Spring Cloud Config。一、简介在分布式系统中，由于服务数量巨多，为了方便服务配置文件统一管理，实时更新，所以需要...
收起
Spring Cloud Gateway初体验
万次阅读 多人点赞 2018-11-06 18:55:37
转载请标明出处： https://www.fangzhipeng.com/springcloud/2018/11/06/sc-f-gateway1/ 本文出自方志朋的博客这篇文章讲述了如何简单地使用Spring Cloud Gateway，来源于Spring Cloud官方案例，...Spring Cloud G...
收起
史上最简单的SpringCloud教程 | 第七篇: 高可用的分布式配置中心(Spring Cloud Config)
万次阅读 多人点赞 2017-04-10 21:24:15
在其pom.xml文件引入Eureka的起步依赖spring-cloud-starter-eureka-server，代码如下: xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> ...
收起
java 微服务分布式 spring
springcloud依赖，持续更新
万次阅读 2020-09-21 03:03:15
parent依赖  <properties>  <spring-boot-dependencies.version>...spring-cloud-alibaba-dependencies.version>.../spring-cloud-
收起
Spring Cloud版本与Spring Boot版本之间匹配关系
万次阅读 2018-06-30 11:38:03
很多人在使用springboot和springcloud，但是对于这两者之间的版本关系不是很清楚，特别是在面临升级的时候不知道该如何操作。本文简要摘录的官方文档的部分内容作为依据，供广大同行参考。问题的提出，我现在使用...
收起
springboot java 升级
SpringCloud面试题(一)
万次阅读 多人点赞 2019-04-24 22:16:30
SpringCloud面试题(一) 大家好，我是酷酷的韩~下面提供一些整理的springcloud面试题一.微服务的优点缺点?说下开发项目中遇到的坑? 优点: 1.每个服务直接足够内聚，代码容易理解 2.开发效率高，一个服务只做一件事...
收起
面试题
史上最简单的SpringCloud教程 | 第四篇:断路器（Hystrix）
万次阅读 多人点赞 2017-04-09 21:14:05
在微服务架构中，根据业务来拆分成一个个的服务，服务与服务之间可以相互调用（RPC），在Spring Cloud可以用RestTemplate+Ribbon和Feign来调用。为了保证其高可用，单个服务通常会集群部署。由于网络原因或者自身的...
收起
java 微服务 hystrix
Spring Cloud - 7 (Spring Cloud Zuul)
万次阅读 2019-07-28 18:45:44
Zuul基本使用 @EnableEurekaClient ...Spring Cloud 学习技巧：善于定位应用：Feign、ConfigServer、Eureka、Zuul、Ribbon定位应用，配置方式是不同增加@EnableZuulProxy @SpringBootApp...
收起
spring java
原史上最简单的SpringCloud教程 | 第八篇: 消息总线(Spring Cloud Bus)(Finchley版本)
万次阅读 多人点赞 2018-07-14 10:15:06
转载请标明出处： ... 本文出自方志朋的博客转载请标明出处： Spring Cloud Bus 将分布式的节点用轻量的消息代理连接起来。它可以用于广播配置文件的更改...本文要讲述的是用Spring Cloud Bus实现通知微服务...
收起
基于springCloud的分布式架构体系
万次阅读 多人点赞 2017-11-09 19:22:58
Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方面面，之前也写过一些关于Spring Cloud文章，主要偏重各组件的使用，本次分享主要解答这两个问题：Spring Cloud在微服务的架构中都做了哪些事情...
收起
Spring Cloud入门操作手册(Hoxton)
import org.springframework.cloud.client.SpringCloudApplication; import org.springframework.cloud.openfeign.EnableFeignClients; //@EnableDiscoveryClient //@SpringBootApplication @EnableFeignClients @...
收起
java