❶ SpringCloud微服务组件介绍
Spring Cloud是一系列框架的有序集合（框架集），他利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
SpringCloud利用SpringBoot的开发便利性巧妙地简化了分布式系统基础设施的开发，SpringCloud为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等，它们都可以用SpringBoot的开发风格做到一键启动和部署。
SpringCloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过SpringBoot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包
下面是Spring Cloud的整体架构图：
注册中心可以说是微服务架构中的“通讯录”，他记录了服务和服务地址的映射关系。在分布式架构中，服务会注册到这里，当服务需要调用其他服务时，就在这里找到对应服务的地址，进行调用。
注册中心的主要作用
Ribbon是Netflix发布的一个负载均衡，有助于控制HTTP和TCP客户端行为。在Spring Cloud中，Eureka一般配合Ribbon进行使用，Ribbon提供了客户端负载均衡的功能，Ribbon利用从Eureka中读取到的服务信息，在调用服务节点提供的服务时，会合理的进行负载。
在Spring Cloud中可以将注册中心和Ribbon配合使用，Ribbon自动的从注册中心中获取服务提供者的列表信息，并基于内置的负载均衡算法，请求服务。
Ribbon原理
几种负载均衡策略：
Hystrix是Netflix开源的一款容错框架，包含常用的容错方法。在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。Hystrix利用熔断、线程池隔离、信号量隔离、降级回退等方法来处理依赖隔离，使系统变得高可用。
Hystrix主要提供了以下几种容错方法：
Spring Cloud Gateway是Spring官方推出的服务网关的实现框架，相对于服务网关的概念有点类似于传统的反向代理服务器（如nginx），但反向代理一般都只是做业务无关的转发请求，而服务网关与服务的整合程度更高，可以看作也是整个服务体系的组成部分，通过过滤器等组件可以在网关中集成一些业务处理的操作（比如权限认证等）。
核心功能：
Spring Cloud Stream是一个用来为微服务应用构建消息驱动能力的框架。
特点：
屏蔽底层 MQ 实现细节，Spring Cloud Stream 的 API 是统一的。如果从 Kafka 切到 RocketMQ，可以直接修改配置。
与 Spring 生态整合更加方便。Spring Cloud Data Flow的流计算都是基于 Spring Cloud Stream；Spring Cloud Bus 消息总线内部也是用的 Spring Cloud Stream。
配置中心功能：
分布式链路追踪，就是将一次分布式请求还原成调用链路，进行日志记录，性能监控并将一次分布式请求的调用情况集中展示。比如各个服务节点上的耗时，请求具体到达哪台机器上、每个服务节点的请求状态等等。
分布式链路追踪方案：
❷ 生产级基于SpringCloud微服务架构性能优化实战，建议收藏
本文将从 Tomcat性能优化，SpringCloud开启重试机制，Zuul网关性能参数优化，Ribbon性能参数优化，Feign与Hystrix性能优化等 五个方面分享在生产环境如何做好SpringCloud性能优化。
一般基于SpringCloud的微服务能够脱离传统的tomcat，独立跑起来，SpringBoot功不可没，其原理是SpringBoot内嵌了tomcat（当然可以换成其他servlet容器，如jetty），能够以java -jar形式就能跑起来。
所以针对每个springboot服务，我们需要对tomcat的一些参数进行优化，以下是楼主项目组优化的tomcat参数配置，供大家参考。
tomcat参数说明：
maxThreads，acceptCount参数应用场景
场景一
场景二
场景三
maxThreads调优
一般说服务器性能要从两个方面说起：
1、cpu计算型指标
2、io密集型指标
所以大部分情况下，tomcat处理io型请求比较多，比如常见的连数据库查询数据进行接口调用。
另外，要考虑tomcat的并发请求量大的情况下，对于服务器系统参数优化，如虚拟机内存设置和linux的open file限制。
maxThreads设置多大合适？
我们知道线程过多，会导致cpu在线程切换时消耗的时间随着线程数量的增加越来越大；线程太少，服务器的请求响应吞吐量会急剧下降，所以maxThreads的配置绝对不是越大越好。
实际情况是设置maxThreads大小没有最优解，要根据具体的服务器配置，实际的应用场景不断的调整和优化。
acceptCount设置多大合适？
尽量与maxThreads的大小保持一致 ， 这个值应该是主要根据应用的访问峰值与平均值来权衡配置的。
当使用URL进行路由时，则需要对zuul.host.connect-timeout-millis和zuul.host.socket-timeout-millis参数控制超时时间。
请求连接的超时时间
请求处理的超时时间
对所有操作请求都进行重试
对当前实例的重试次数，针对同一个服务实例，最大重试次数（不包括首次调用）
对下个实例的重试次数，针同其它的服务实例，最大重试次数（不包括首次server）
注意Hystrix断路器的超时时间需要大于ribbon的超时时间，不然不会触发重试
Feign和Ribbon在整合了Hystrix后，首次调用失败的问题？
目前楼主的强烈做法是： 禁用Hystrix的超时时间，设为false
还有一种是官方提倡的是 设置超时时间。
在实际的项目中亲测，这种方式也有不好的地方， 如请求时间超过5s会出现请求数据时有时无的情况 ，给用户的感觉是 系统不稳定，要求整改 。
另外，禁用hystrix，官方不推荐 。
hystrix超时设置原则
问题：一个http请求，如果feign和ribbon都配置了重试机制，异常情况下一共会请求多少次？
请求总次数 n 为feignClient和ribbon配置参数的笛卡尔积：
n(请求总次数) = feign(默认5次) * (MaxAutoRetries+1) * (MaxAutoRetriesNextServer+1)
其中+1是代表ribbon本身默认的请求。
其实二者的重试机制相互独立，并无联系。但是因为用了feign肯定会用到ribbon，所以feign的重试机制相对来说比较鸡肋，一般会关闭该功能。ribbon的重试机制默认配置为0，也就是默认是去除重试机制的，建议不要修改。
❸ Spring Cloud微服务体系的组成
Netflix Eureka是Spring Cloud服务注册发现的基础组件
Eureka提供RESTful风格(HTTP协议)的服务注册与发现
Eureka采用C/S架构,Spring Cloud内置客户端
启用应用,访问 http://localhost:8761
Eureka客户端开发要点
maven依赖spring-cloud-starter-netflix-eureka-client application.yml
配置eureka.client.service-url.defaultZone
入口类增加@EnableEurekaClient
先启动注册中心,在启动客户端,访问 localhost:8761查看eureka注册中心,看到客户端注册
Eureka名词概念
Register - 服务注册, 向Eureka进行注册登记
Renew - 服务续约,30秒/次心跳包健康检查.90秒未收到剔除服务
Fetch Registries - 获取服务注册列表,获取其他微服务地址
Cancel - 服务下线, 某个微服务通知注册中心暂停服务
Eviction - 服务剔除,90秒未续约,从服务注册表进行剔除
Eureka自我保护机制
Eureka在运行期去统计心跳失败率在15分钟之内是否低于 85%
如果低于 85%，会将这些实例保护起来，让这些实例不会被剔除
关闭自我保护:eureka.服务实例.
enable-self-preservation: false
PS: 如非网络特别不稳定,建议关闭
Eureka高可用配置步骤
服务提供者defaultZone指向其他的Eureka
客户端添加所有Eureka 服务实例 URL
Actuator自动为微服务创建一系列的用于监控的端点
Actuator在SpringBoot自带，SpringCloud进行扩展
pom.xml依赖spring-boot-starter-actuator
RestTemplate + @LoadBalanced 显式调用
OpenFeign 隐藏微服务间通信细节
Ribbon是RestTemplate与OpenFeign的通信基础
Feign是一个开源声明式WebService客户端，用于简化服务通信
Feign采用“接口+注解”方式开发，屏蔽了网络通信的细节
OpenFeign是SpringCloud对Feign的增强，支持Spring MVC注解
1.新建Spring boot Web项目，application name 为 proct-service
在pom.xml中引入依赖
spring-cloud-starter-alibaba-nacos-discovery作用为向Nacos server注册服务。
spring-cloud-starter-openfeign作用为实现服务调用。
2.修改application.yml配置文件
3.在启动类上添加@EnableDiscoveryClient、@EnableFeignClients注解
4.编写OrderClient Interface
注：/api/v1/order/test 会在下面order-service声明。
OrderClient.java
5.编写Controller和service
ProctController.java
ProctService.java
1.OpenFeign开启通信日志
基于SpringBoot的logback输出,默认debug级别
设置项：feign.client.config.微服务id.loggerLevel
微服务id：default代表全局默认配置
2.通信日志输出格式
NONE: 不输出任何通信日志
BASIC: 只包含URL、请求方法、状态码、执行时间
HEADERS：在BASIC基础上，额外包含请求与响应头
FULL：包含请求与响应内容最完整的信息
3.OpenFeign日志配置项
LoggerLevel开启通信日志
ConnectionTimeout与ReadTimeout
利用httpclient或okhttp发送请求
1.OpenFeign通信组件
OpenFeign基于JDK原生URLConnection提供Http通信
OpenFeign支持Apache HttpClient与Square OkHttp
SpringCloud按条件自动加载应用通信组件
2.应用条件
Maven引入feign-okhttp或者feign-httpclient依赖
设置feign.[httpclient|okhttp].enabled=true
POST方式传递对象使用@RequestBody注解描述参数
GET方式将对象转换为Map后利用@RequestParam注解描述
雪崩效应:服务雪崩效应产生与服务堆积在同一个线程池中，因为所有的请求都是同一个线程池进行处理，这时候如果在高并发情况下，所有的请求全部访问同一个接口,这时候可能会导致其他服务没有线程进行接受请求，这就是服务雪崩效应效应。
服务熔断:熔断机制目的为了保护服务，在高并发的情况下，如果请求达到一定极限(可以自己设置阔值)如果流量超出了设置阈值，让后直接拒绝访问，保护当前服务。使用服务降级方式返回一个友好提示，服务熔断和服务降级一起使用。
1.Hystrix熔断器
Hystrix（豪猪）是Netflix开源的熔断器组件，用于为微服务提供熔断机制预防雪崩，保护整体微服务架构的健康
2.Hystrix功能
预防微服务由于故障，请求长时间等待导致Web容器线程崩溃
提供故障备选方案，通过回退（fallback)机制提供”服务降级”
提供监控仪表盘,实时监控运行状态
3.Hystrix 熔断器工作原理
服务的健康状况 = 请求失败数 / 请求总数.
熔断器开关由关闭到打开的状态转换是通过当前服务健康状况和设定阈值比较决定的.
当熔断器开关关闭时, 请求被允许通过熔断器. 如果当前健康状况高于设定阈值, 开关继续保持关闭. 如果当前健康状况低于
设定阈值, 开关则切换为打开状态.
当熔断器开关打开时, 请求被禁止通过.
当熔断器开关处于打开状态, 经过一段时间后, 熔断器会自动进入半开状态, 这时熔断器只允许一个请求通过. 当该请求调用
成功时, 熔断器恢复到关闭状态. 若该请求失败, 熔断器继续保持打开状态, 接下来的请求被禁止通过.
熔断器的开关能保证服务调用者在调用异常服务时, 快速返回结果, 避免大量的同步等待. 并且熔断器能在一段时间后继续侦测请求执行结果, 提供恢复服务调用的可能.
4.什么情况下会触发服务降级
FAILURE: 执行失败，抛出异常
TIMEOUT:执行超时（默认1秒）
SHORT_CIRCUITED:熔断器状态为Open
THREAD_POOL_REJECTED:线程池拒绝
SEMAPHORE_REJECTED:信号量拒绝
5.使用Hystrix步骤
1.引入pom文件依赖
6.OpenFeign与Hystrix整合
OpenFeign中使用Hystrix
OpenFeign内置Hystrix，feign.hystrix.enable开启即可
feign: hystrix: enabled: true
在@FeignClient增加fallback属性说明Fallback类
@FeignClient(name="message-service",fallback = MessageServiceFallback.class) public interface MessageService { @GetMapping("/sendsms") public CallbackResult sendSMS(@RequestParam("mobile") String mobile , @RequestParam("message") String message); }
Fallback类要实现相同接口，重写服务降级业务逻辑
@Component public class MessageServiceFallback implements MessageService { @Override public CallbackResult sendSMS(String mobile, String message) { return new CallbackResult("INVALID_SERVICE","消息服务暂时无法使用，短信发送失败"); } }
7.Hystrix超时设置
8.部署Hystrix Dashboard监控
Hystrix Client依赖hystrix-metrics-event-stream
Hystrix Client注册HystrixMetricsStreamServlet
监控微服务依赖spring-cloud-starter-netflix-hystrix-dashboard
监控微服务利用@EnableHystrixDashboard开启仪表盘
9.Hystrix熔断设置
产生熔断的条件:
当一个Rolling Window(滑动窗口）的时间内（默认：10秒），最近20次调用请求，请求错误率超过50%，则触发熔断5秒，期间快速失败。
TIPS: 如10秒内未累计到20次，则不会触发熔断
Hystrix熔断设置项:
统一访问出入口,微服务对前台透明
安全、过滤、流控等API管理功能
易于监控、方便管理
Netflix Zuul
Spring Cloud Gateway
Zuul 是Netflix开源的一个API网关, 核心实现是Servlet
Spring Cloud内置Zuul 1.x
Zuul 1.x 核心实现是Servlet，采用同步方式通信
Zuul 2.x 基于Netty Server，提供异步通信
认证和安全
性能监测
动态路由
负载卸载
静态资源处理
压力测试
Spring Cloud Gateway，是Spring“亲儿子”
Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式
Gateway基于Spring 5.0与Spring WebFlux开发，采用Reactor响应式设计
1.使用三部曲
依赖spring-cloud-starter-netflix-zuul
入口增加 @EnableZuulProxy
application.yml 增加微服务映射
2.微服务映射
Spring Cloud Zuul内置Hystrix
服务降级实现接口：FallbackProvider
1.微服务网关流量控制
微服务网关是应用入口，必须对入口流量进行控制
RateLimit是Spring Cloud Zuul的限流组件
https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit
RateLimit采用“令牌桶”算法实现限流
2.什么是令牌桶
1.Zuul的执行过程
2.Http请求生命周期
1.需要实现ZuulFilter接口
shouldFilter() - 是否启用该过滤器
filterOrder() - 设置过滤器执行次序
filterType() - 过滤器类型:pre|routing|post
run() - 过滤逻辑
2.Zuul内置过滤器
3.Zuul+JWT跨域身份验证
1.Spring Cloud Config
2.携程 Apollo
3.阿里巴巴Nacos
1.依赖"spring-cloud-starter-config"
2.删除application.yml,新建bootstrap.yml
3.配置"配置中心"服务地址与环境信息
1、微服务依赖"spring-boot-starter-actuator";
2、动态刷新类上增加@RefreshScope注解
3、通过/actuator/refresh刷新配置
1、通过加入重试机制、提高应用启动的可靠性;
2、重试触发条件1:配置中心无法与仓库正常通信
3、重试触发条件2:微服务无法配置中心正常通信
❹ Spring Cloud之Eureka源码分析2
本章主要介绍Eureka Client端源码分析。
客户端主要是向Server服务端发送Http请求，主要有注册，心跳续约，获取注册信息等功能
在分析源码之前，需要查看下客户端配置文件
application.yml
访问服务端localhost:8000的注册信息
自动配置类，首先要从依赖包的spring.factories文件看起
其中最重要的是EurekaClientAutoConfiguration类
只要类中存在EurekaClientConfig类所在的依赖包eureka-client-xx.jar就可以加载这个类
2、 用来开启定时任务
1、EurekaAutoServiceRegistration
实例化EurekaAutoServiceRegistration对象，并放到spring容器中
org.springframework.cloud.netflix.eureka.serviceregistry.EurekaAutoServiceRegistration
2、start
由于EurekaAutoServiceRegistration类实现了SmartLifecycle,SmartApplicationListener等接口，所以会在容器初始化完成之后调用EurekaAutoServiceRegistration#start方法。
调用ApplicationInfoManager应用信息管理设置实例初始化状态信息initialStatus
4、setInstanceStatus
com.netflix.appinfo.ApplicationInfoManager#setInstanceStatus
设置实例状态信息并调用监听器notify方法
com.netflix.discovery.DiscoveryClient#register
这里就到了注册客户端的地方
包括缓存更新与心跳续约，通过类开始初始化，并最终通过initScheledTasks方法开启定时调度器任务
EurekaClientAutoConfiguration.
这个类是程序实现定时刷新任务开始的地方，主要是通过new CloudEurekaClient()方法创建Cloud客户端类（CloudEurekaClient）
下面主要查看CloudEurekaClient的调用链
1、CloudEurekaClient#CloudEurekaClient
org.springframework.cloud.netflix.eureka.CloudEurekaClient#CloudEurekaClient
调用CloudEurekaClient类的父类，和对applicationInfoManager、publisher、eurekaTransportField等属性值赋值
2、DiscoveryClient#DiscoveryClient
com.netflix.discovery.DiscoveryClient#DiscoveryClient
4、DiscoveryClient#DiscoveryClient
定义调度器类、心跳执行器和缓存刷新执行器等的定义。
com.netflix.discovery.DiscoveryClient#DiscoveryClient
这个方法主要流程：
①、这个方法前半部分是初始化属性值。
②、根据客户端client配置文件，config.shouldFetchRegistry()是否获取注册表信息和
config.shouldRegisterWithEureka()是否注册到eureka上来对属性赋值，或直接返回
③、初始化调度器scheler、两个线程池执行器heartbeatExecutor（心跳续约）和cacheRefreshExecutor（缓存刷新，定时获取注册信息表）
④、在获取服务注册信息条件下，没有获取到信息或异常即fetchRegistry(false)返回false。可以从备用服务器获取调用fetchRegistryFromBackup()方法，内部实现方法调用备用服务器类的get方法backupRegistryProvider.get()
⑤、初始化调度器任务方法initScheledTasks()
调度器任务包括：
1、定时刷新缓存注册表信息，分为全量获取和增量获取
2、定时向服务端发送心跳续约
3、状态改变监听器执行
这里不仅包括这些定时任务，注册也是在这里调用状态改变监听器StatusChangeListener的notify方法
com.netflix.discovery.DiscoveryClient#initScheledTasks
1、initScheledTasks
com.netflix.discovery.DiscoveryClient#initScheledTasks
TimedSupervisorTask继承了TimerTask，TimerTask实现了Runnable
TimedSupervisorTask类的构造方法
2、HeartbeatThread
执行TimedSupervisorTask的task任务，在给定的间隔内执行心跳续约任务
com.netflix.discovery.DiscoveryClient.HeartbeatThread
3、renew
续约任务，续约成功更新参数。通过REST方式进行续订
com.netflix.discovery.DiscoveryClient#renew
服务端调用到renewLease方法续约，appName和id与客户端传过来的相同
com.netflix.eureka.resources.InstanceResource#renewLease
在定时刷新缓存实现获取注册信息，分为全量拉取和增量拉取
创建TimedSupervisorTask调度任务类，传入cacheRefreshExecutor执行器、CacheRefreshThread任务类、从服务端获取注册信息的时间间隔RegistryFetchIntervalSeconds等参数信息
全量拉取条件（任意一个）
①、disable-delta属性值是true 关闭增量拉取
②、registry-refresh-single-vip-address 属性vip地址的值不为空
③、forceFullRegistryFetch 为true 传过来的变量值
④、localRegionApps的applications是null 当前区域应用
⑤、applications的数量是0
⑥、applications的版本是-1
实现增量拉取的条件是不符合全量拉取，调用getAndUpdateDelta方法
com.netflix.discovery.DiscoveryClient#getAndUpdateDelta
这个方法实现了增量拉取的请求实现，及对拉取增量结果的处理
1、getDelta
eurekaTransport.queryClient.getDelta(remoteRegionsRef.get())的具体实现是通过类实现的
com.netflix.discovery.shared.transport.jersey.#getDelta
这个方法主要是遍历recentlyChangedQueue存在的数据放入到Applications对象中。所以recentlyChangedQueue队列中存在什么数据就很重要，因此我们需要了解最新更新队列recentlyChangedQueue是如何放入的及放入那些数据，及其的移除的原理。
在这个方法最后 apps.setAppsHashCode设置了当前服务端所有注册信息的HashCode，所以这个增量对象存储了最新的状态HashCode值。
7、客户端获取增量数据的处理
还是在getAndUpdateDelta方法内，对服务端传输过来数据，获取当前服务端的增量数据部分
com.netflix.discovery.DiscoveryClient#getAndUpdateDelta
这个方法的主要过程是：
如果增量数据部分为空，则执行全量拉取。
对当前服务的注册信息表执行updateDelta(delta)方法，对当前注册实例的增加删除或修改操作
当前更新后的服务注册表的HashCode值与增量对象存储的最新的状态HashCode值比较，如果不相等 则执行全量拉取
最新更新队列ConcurrentLinkedQueue<RecentlyChangedItem> recentlyChangedQueue
com.netflix.eureka.registry.AbstractInstanceRegistry#AbstractInstanceRegistry类在构建创建注册表时创建了recentlyChangedQueue队列，并创建了一个增量调度任务方法getDeltaRetentionTask方法
com.netflix.eureka.registry.AbstractInstanceRegistry#getDeltaRetentionTask
对recentlyChangedQueue队列中对最近改变的队列在一定时间范围retentionTimeInMSInDeltaQueue=180000ms(3分钟)外的进行定时清除(30s清除一次)
3、statusUpdate
4、deleteStatusOverride
getDeltaRetentionTask进行定时清除
全量拉取与增量拉取过程类似
全量拉取调用getAndStoreFullRegistry方法
1、getAndStoreFullRegistry
com.netflix.discovery.DiscoveryClient#getAndStoreFullRegistry
2、getApplications
com.netflix.discovery.shared.transport.EurekaHttpClient#getApplications
❺ SpringCloud升级之路2020.0.x版-29.SC OpenFeign 的解析(2)
在使用云原生的很多微服务中，比较小规模的可能直接依靠云服务中的负载均衡器进行内部域名与服务映射，通过 健康 检查接口判断实例 健康 状态，然后直接使用 OpenFeign 生成对应域名的 Feign Client。Spring Cloud 生态中，对 OpenFeign 进行了封装，其中的 Feign Client 的各个组件，也是做了一定的定制化，可以实现在 OpenFeign Client 中集成服务发现与负载均衡。在此基础上，我们还结合了 Resilience4J 组件，实现了微服务实例级别的线程隔离，微服务方法级别的断路器以及重试。
我们先来分析下 Spring Cloud OpenFeign
Spring Cloud 中的任何组件，都是基于 Spring Boot 而实现的。由于 Spring Boot 中已经有了 HTTP 编码解码器，就可以不用单独给 OpenFeign 单独再实现 HTTP 编码解码器了，而是考虑将 OpenFeign 的编码解码器接口用 Spring Boot 的 HTTP 编码解码器实现。
在 FeignClientsConfiguration 中，提供了默认的实现：
通过源码可以看出，默认的 Decoder 是经过几层包装的 Decoder，分别包括：
传入 SpringDecoder 的 HttpMessageConverters 对象，是 spring-web 的所有 HttpMessageConverter 集合。HttpMessageConverter 是 spring-web 中对于 HTTP 请求和响应的 body 进行编码解码的工具。其接口结构是：
spring boot 内置了很多 HttpMessageConverter，我们也可以实现自己的 HttpMessageConverter，去实现我们自定义 MediaType，例如我们这里定义一个 ：
之后，与前面类似，将其配置到 spring boot 兼容 MVC 配置中：
编写 Controller，测试：
使用 postman 类似的工具，指定 HTTP 请求头：
Body 是：
请求后，就会走到 的 read 解析成 Student 对象，之后响应的 student 也会被 的 write 写入响应 Body
由此可见， 由于 SpringEncoder 的存在，我们可以复用 Spring 内置的 HttpMessageConverter，同时也能扩展自定义我们自己的 HttpMessageConverter，非常方便 。
ResponseEntityDecoder 的代码比较简单，实现的效果就是解码的时候，忽略 HttpEntity 这个 spring-web 对于 HTTP 响应的包装类：
这个其实为了和 RestTemplate 的响应兼容，RestTemplate 可以返回 HttpEntity，但是底层 HTTP 请求返回的 body 其实并没有包装这个类型。
同理，JDK 中的 Optional 包装类，也需要做同样的事情，这个就是通过 OptionalDecoder 实现的。
SpringEncoder 编码器也非常简单，也是基于 spring 中的 HttpMessageConverter。这里我们就不再赘述。
❻ 微服务框架之Spring Cloud简介
在了解 Spring Cloud 之前先了解一下微服务架构需要考量的核心关键点，如下图：
对于以上等核心关键点的处理，不需要我们重复造车轮， Spring Cloud 已经帮我们集成了，它使用 Spring Boot 风格将一些比较成熟的微服务框架组合起来，屏蔽掉了复杂的配置和实现原理，为快速构建微服务架构的应用提供了一套基础设施工具和开发支持。
Spring Cloud 所提供的核心功能包含：
Spring Cloud架构图
Spring Cloud子项目
Spring Cloud 旗下的子项目大致可以分为两类：
如下：
1. Spring Cloud 与 Spring Boot
Spring Boot 可以说是微服务架构的核心技术之一。通过在 Spring Boot 应用中添加 Spring MVC 依赖，就可以快速实现基于 REST 架构的服务接口，并且可以提供对 HTTP 标准动作的支持。而且 Spring Boot 默认提供 JackJson 序列化支持，可以让服务接口输入、输出支持 JSON 等。因此，当使用 Spring Cloud 进行微服务架构开发时，使用 Spring Boot 是一条必经之路。
2. Spring Cloud 与服务治理( Eureka )
服务治理是 Spring Cloud 的核心，在实现上其提供了两个选择，即 Consul 和 Netflix 的 Eureka 。
Eureka 提供了服务注册中心、服务发现客户端，以及注册服务的 UI 界面应用。
在 Eureka 的实现中，节点之间相互平等，有部分注册中心“挂掉”也不会对整个应用造成影响，即使集群只剩一个节点存活，也可以正常地治理服务。即使所有服务注册节点都宕机， Eureka 客户端中所缓存的服务实例列表信息，也可让服务消费者能够正常工作，从而保障微服务之间互相调用的健壮性和应用的弹性。
3. Spring Cloud 与客户端负载均衡( Ribbon )
Ribbon 默认与 Eureak 进行无缝整合，当客户端启动的时候，从 Eureka 服务器中获取一份服务注册列表并维护在本地，当服务消费者需要调用服务时， Ribbon 就会根据负载均衡策略选择一个合适的服务提供者实例并进行访问。
Spring Cloud 通过集成 Netflix 的 Feign 项目，为开发者提供了声明式服务调用，从而简化了微服务之间的调用处理方式。并且默认 Feign 项目集成了 Ribbon ，使得声明式调用也支持客户端负载均衡功能。
4. Spring Cloud 与微服务容错、降级( Hystrix )
为了给微服务架构提供更大的弹性，在 Spring Cloud 中，通过集成 Netflix 下子项目 Hystrix ，通过所提供的 @HystrixCommand 注解可以轻松为我们所开发的微服务提供容错、回退、降级等功能。此外， Hystrix 也默认集成到 Feign 子项目中。
Hystrix 是根据“断路器”模式而创建。当 Hystrix 监控到某服务单元发生故障之后，就会进入服务熔断处理，并向调用方返回一个符合预期的服务降级处理（ fallback ），而不是长时间的等待或者抛出调用异常，从而保障服务调用方的线程不会被长时间、不必要地占用，避免故障在应用中的蔓延造成的雪崩效应。
而 Hystrix 的仪表盘项目（ Dashboard ）可以监控各个服务调用所消耗的时间、请求数、成功率等，通过这种近乎实时的监控和告警，可以及时发现系统中潜在问题并进行处理。
5. Spring Cloud 与服务网关( Zuul )
Spring Cloud 通过集成 Netflix 中的 Zuul 实现 API 服务网关功能，提供对请求的路由和过滤两个功能
路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础。
过滤器功能则负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。
通过 Zuul ，可以将细粒度的服务组合起来提供一个粗粒度的服务，所有请求都导入一个统一的入口，对外整个服务只需要暴露一个 API 接口，屏蔽了服务端的实现细节。通过 Zuul 的反向代理功能，可以实现路由寻址，将请求转发到后端的粗粒度服务上，并做一些通用的逻辑处理。此外， Zuul 默认会与 Eureka 服务器进行整合，自动从 Eureka 服务器中获取所有注册的服务并进行路由映射，实现 API 服务网关自动配置。
6. Spring Cloud 与消息中间件( Stream )
Spring Cloud 为简化基于消息的开发，提供了 Stream 子项目，通过建立消息应用抽象层，构建了消息收发、分组消费和消息分片等功能处理，将业务应用中的消息收发与具体消息中间件进行解耦，使微服务应用开发中可以非常方便地与 Kafka 和 RabbitMQ 等消息中间件进行集成。
Spring Cloud Bus 基于 Stream 进行扩展，可以作为微服务之间的事件、消息总线，用于服务集群中状态变化的传播。
比如 Spring Cloud Config 借助 Bus ，可以实现配置的动态刷新处理。
7. Spring Cloud 与分布式配置中心( Config )
针对微服务架构下的配置文件管理需求， Spring Cloud 提供了一个 Config 子项目。 Spring Cloud Config 具有中心化、版本控制、支持动态更新和语言独立等特性。
在 Config 子项目中将微服务应用分为两种角色：配置服务器（ Config Server ）和配置客户端（ Config Client ）。使用配置服务器集中地管理所有配置属性文件，配置服务中心可以将配置属性文件存储到 Git 、 SVN 等具有版本管理仓库中，也可以存放在文件系统中。默认采用 Git 的方式进行存储，因此可以很容易地对配置文件进行修改，并实现版本控制。
8. Spring Cloud 与微服务链路追踪( Sleuth )
Spring Cloud 中的 Sleuth 子项目为开发者提供了微服务之间调用的链路追踪。
Sleuth 核心思想就是通过一个全局的 ID 将分布在各微服务服务节点上的请求处理串联起来，还原了调用关系，并借助数据埋点，实现对微服务调用链路上的性能数据的采集。
因此，通过 Sleuth 可以很清楚地了解到一个用户请求经过了哪些服务、每个服务处理花费了多长时间，从而可以对用户的请求进行分析。此外，通过将采集的数据发送给 Zipkin 进行存储、统计和分析，从而可以实现可视化的分析和展示，帮助开发者对微服务实施优化处理。
9. Spring Cloud 与微服务安全( Security )
Spring Cloud Security 为我们提供了一个认证和鉴权的安全框架，实现了资源授权、令牌管理等功能，同时结合 Zuul 可以将认证信息在微服务调用过程中直接传递，简化了我们进行安全管控的开发。
Spring Cloud Security 默认支持 OAuth 2.0 认证协议，因此单点登录也可以非常容易实现，并且 OAuth2.0 所生成的令牌可以使用 JWT 的方式，进一步简化了微服务中的安全管理。
10. Spring Cloud 的其他子项目
❼ SpringCloud服务网关Zuul分析①分发
在SpringCloud中充当服务网关的角色，它包含了鉴权、流量转发、请求统计等等功能
Filter是Zuul的核心，用来实现对外服务的控制。Filter的生命周期有4个，分别是 “PRE”、“ROUTING”、“POST”、“ERROR” ，整个生命周期可以用下图来表示。
PRE： 这种过滤器在请求被路由之前调用。我们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
ROUTING： 这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apache HttpClient或Netfilx Ribbon请求微服务。
POST： 这种过滤器在路由到微服务以后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
ERROR： 在其他阶段发生错误时执行该过滤器。 除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。
根据场景需要,我们也可以自定义一些filter,穿插在整个过程的某个阶段,只需要继承ZuulFilter,并且覆盖里面的4个方法就可以了.
application.properties中配置:
# 禁用一些Filter的配置:
zuul.FormBodyWrapperFilter.pre.disable= true
# 路由的配置：
# 配置需要被跳转的地址，/user/**的网址将被分发
zuul.routes.user.path=/user/**
# 重定向的地址：
zuul.routes.user.url=http://127.0.0.1:8081/
❽ SpringCloud入门简述
微服务，是一个小型的服务，也是一种设计理念，将一个大型繁杂的系统拆分为多个小型的服务，进行独立部署，这些服务在独立进程中运行，通过特定的协议进行通信
优点：
缺点：
在服务通信性能上RPC更强，但是Rest更为灵活
SpringCloud是基于SpringBoot实现的微服务框架，为开发人员提供了很多快速构建分布式系统中常见模式的工具，包括配置管理、服务发现、断路器、智能路由、微代理，控制总线等。
Spring Cloud专注于为典型的用例提供良好的开箱即用体验，并为其他用例提供扩展性机制。
参考地址：
Eureka是Netflix开发的基于Rest的服务发现框架，SpringCloud基于此进行二次封装，实现服务的管理。
创建一个Eureka服务：https://www.cnblogs.com/william-m/p/15991511.html
如果没有Eureka，如何进行服务之间的调用?
使用Rest进行调用，先将RestTemplate注册到Bean，然后：
Eureka遵循的是AP原则，Eureka各个节点都是平等的，部分服务节点的下线不会影响正常服务的调用，只要该服务还剩下一个节点在线就可以进行正常的服务访问，即保证了服务可用，但是并不能保证查询到的信息是最新的。Zookeeper的CP原则与之不同，Zookeeper会有一个master节点来保证一致性，一旦master节点挂掉，剩余的节点会重新选举一个leader，而选择的过程需要时间，这期间会使得该服务瘫痪，所以需要满足高可用的话该情况是不能够容忍的。
Spring Cloud Ribbon是一个基于HTTP和TCP的 客户端负载均衡 工具，基于Netflix Ribbon实现，通过轮询、随机等算法选择一个可用服务。
目的：将用户的请求平摊的分配到多个服务上，实现高可用
最大区别：服务清单所存储的位置
客户端先发送请求到负载均衡服务器，然后由负载均衡服务器通过负载均衡算法，在众多可用的服务器之中选择一个来处理请求。
客户端自己维护一个可用服务器地址列表，在发送请求前先通过负载均衡算法选择一个将用来处理本次请求的服务器，然后再直接将请求发送至该服务器。
逻辑时序：RestTemplate发起请求 负载均衡器拦截器拦截 LoadBalanceClient获取ILoadBalance 获取服务列表 根据负载均衡器选择一个server 发起请求 记录调用信息
Ribbon基于HTTP和TCP客户端的负载均衡器可以自己构建HTTP请求，使用RestTemplate发送服务
Feign基于Ribbon进行改进，采用接口的方式，将需要调用的服务的方法定义成抽象方法
Consumer应用
启动类
为了调用Proct应用服务的接口类
Proct应用
controller
Hystrix是一个服务容错与保护的组件，用于 服务降级 、 服务熔断 、 服务限流 等等，能够保证在其中一个服务出现问题的时候，不会出现级联故障，防止雪崩，提高分布式服务的健壮性。
将某些服务停掉会i这不进行业务处理，释放资源来维持主要服务的功能。
应对服务雪崩的一种保险措施，是微服务的链路保护机制，是服务降级的一种特殊处理方式。
为了应对某个服务故障的情况，保证系统的整体可用性，熔断器会切断对该服务的请求，返回一个比较友好的错误响应，直到服务恢复正常
熔断机制的三种状态：
示例：
熔断：直接切断服务的调用
降级：牺牲非核心业务保证核心服务的正常
限流：服务访问量达到阈值后拒绝多余的调用
Zuul是一个微服务网关。网关：是一个网络系统的前置入口。也就是说要想访问一个有网关的网络系统请求相应的服务，需要先进入网关，然后路由到相应的服务。
通常是组成一个系统的微服务很多、或者有权限要求时需要用到网关。
Zuul提供一个过滤器，父类为ZuulFilter，用来过滤代理请求，提供额外的功能逻辑（这点类似于AOP），包括前置过滤、路由后过滤、后置过滤、异常过滤。
ZuulFilter包含的抽象方法：filterType、filterOrder、shouldFilter、run
当微服务众多的时候，想要管理各个服务的配置时过于繁杂，SpringCloud Config则可以用来对每个微服务的配置进行集中的管理。可以实现权限管控、灰度发布、版本管理、格式检验、安全配置等。
作用：
特点：
文章来自https://www.cnblogs.com/william-m/p/16153557.html
❾ 关于Spring Cloud Alibaba，看这篇文章就够了！（附教程资料）
首先我们需要了解一下Spring Cloud，然后再来了解Spring Cloud Alibaba；
源自官方描述：
Spring Cloud为开发人员提供了一些工具用来快速构建分布式系统中的一些常见模式和解决一些常见问题（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、群集状态）。分布式系统的协调导致了很多样板式的代码（很多固定套路的代码），使用Spring Cloud开发人员可以快速建立实现这些模式的服务和应用程序。它们在任何分布式环境中都能很好地运行，包括开发人员自己的笔记本电脑、裸机数据中心和云计算等托管平台；
Spring Cloud为分布式系统开发的典型应用场景提供良好的开箱即用的功能:
Spring Cloud Alibaba是Spring Cloud下的一个子项目，Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案，它包含开发分布式应用程序所需的所有组件，使您可以轻松地使用Spring Cloud开发应用程序，使用Spring Cloud Alibaba，您只需要添加一些注解和少量配置即可将Spring Cloud应用程序连接到Alibaba的分布式解决方案，并使用Alibaba中间件构建分布式应用程序系统；
Spring Cloud Alibaba 是阿里巴巴开源中间件跟 Spring Cloud 体系的融合:
动力节点的Spring Cloud Alibaba学习教程，将带你深入掌握基于Spring Cloud Alibaba技术栈的微服务开发技术，包括nacos、sentinel、seata、gateway、skywalking等，培养独立进行企业微服务项目架构的能力;
Spring Cloud Alibaba视频教程
https://www.bilibili.com/video/BV1nK4y
Spring Cloud Alibaba资料下载
http://www.bjpowernode.com/?toutiao
•001.视频导读
•002.Spring家族产品梳理
•003.What is Spring-Cloud-Alibaba？
•004.Nacos运行环境部署
•005.向Nacos注册中心注册服务
•006.从Nacos发现服务并负载均衡调用
•007.从Nacos发现服务并负载均衡调用
•008.Nacos客户端信息缓存
•009.Nacos客户端信息缓存
•010.Nacos Config配置中心启动读取外部配置
•011.Nacos Config配置中心自动刷新
•012.Nacos Config配置中心yaml配置
•013.Nacos Config配置中心多环境配置
•014.问答交流
•015.内容回顾-配置中心数据模型
•016.配置中心三层结构数据配置隔离
•017.配置中心三层结构数据配置隔离
•018.配置版本回滚-服务注册分组
•019.Nacos管控台用户权限管理
•020.Nacos数据持久化
•021.Nacos数据持久化
•022.Nacos集群环境部署
•023.Nacos集群环境测试
•024.Nacos集群统一入口Nginx
•025.快速回顾
•026.RestTemplate无参数Get调用返回String
•027.RestTemplate无参数Get调用返回User
•028.RestTemplate有参数Get调用返回User
•029.RestTemplate有参数Get调用返回User
•030.RestTemplate有参数Post调用返回User
•031.RestTemplate有参数Post调用返回User
•032.RestTemplate传输User对象参数Post调用返回User
•033.RestTemplate传输JSON参数Post调用返回User
•034.RestTemplate有参数Put调用
•035.RestTemplate有参数Delete调用
•036.RestTemplate方法调用梳理总结
•037.RestTemplate结合Ribbon实现负载均衡
•038.RestTemplate结合Ribbon实现负载均衡
•039.Ribbon负载均衡实现策略
•040.自定义Ribbon负载均衡实现策略
•041.更改Ribbon负载均衡实现策略
•042.Ribbon的核心接口组成
•043.Ribbon负载均衡策略个性化配置
•044.Ribbon结合Nacos实现权重负载均衡策略
•045.Ribbon结合Nacos负载均衡策优先调用同名集群
•046.Ribbon结合Nacos基于版本负载均衡策略
•047.Ribbon结合Nacos基于命名空间负载均衡策略
•048.What is Feign？
•049.Spring Cloud Alibaba基于Feign的远程调用
•050.Spring Cloud Alibaba基于Feign+Ribbon负载均衡远程调用
•051.Spring Cloud Alibaba基于Feign的相关配置
•052.脱离Ribbon的Feign的远程调用
•054.微服务的级联故障服务雪崩
•055.Spring Cloud Alibaba集成Sentinel
•056.Spring Cloud Alibaba基于Sentinel管理后台数据测试
•057.Spring Cloud Alibaba基于Sentinel实现限流
•058.Spring Cloud Alibaba基于Sentinel实现限流自定义返回结果
•059.Spring Cloud Alibaba基于Sentinel实现限流自定义跳转页面
•060.Spring Cloud Alibaba基于Sentinel线程数限流
•061.Spring Cloud Alibaba基于Sentinel资源关联限流
•062.Spring Cloud Alibaba基于Sentinel流控规则和流控效果
•063.问答交流
•064.快速回顾和演示环境预备
•065.Spring Cloud Alibaba Sentinel 服务降级RT
•066.Spring Cloud Alibaba Sentinel 服务降级异常比例和异常数
•067.Spring Cloud Alibaba Sentinel 热点参数规则
•068.Spring Cloud Alibaba Sentinel 热点参数规则小细节
•069.Spring Cloud Alibaba Sentinel 系统保护规则
•070.Spring Cloud Alibaba Sentinel 授权规则
•071.Spring Cloud Alibaba Sentinel Dashboard控制台通信原理
•072.Spring Cloud Alibaba Sentinel 对Controller请求url埋点
•073.Spring Cloud Alibaba Sentinel 手写代码实现埋点
•074.Spring Cloud Alibaba Sentinel 采用注解实现埋点
•075.Spring Cloud Alibaba Sentinel 对RestTemplate流控和熔断
•076.Spring Cloud Alibaba Sentinel 对Feign流控和熔断
•077.问答交流
•078.Sentinel规则持久化-拉模式持久化到本地文件
•079.Sentinel规则持久化-拉模式持久化到本地文件
•080.Sentinel规则持久化-推模式持久化到Nacos
•081.Sentinel规则持久化-推模式持久化到Nacos
•082.Spring Cloud Gateway 网关功能特性
•083.Spring Cloud Gateway 网关搭建
•084.Spring Cloud Gateway 网关服务调用
•085.Spring Cloud Gateway 网关谓词
•086.Spring Cloud Gateway 网关谓词
•087.Spring Cloud Gateway 网关谓词
•088.Spring Cloud Gateway 网关过滤器
•089.Spring Cloud Gateway 问答交流
•090.Spring Cloud Gateway自定义谓词
•091.Spring Cloud Gateway自定义谓词
•092.Spring Cloud Gateway自定义谓词不匹配404页面
•093.Spring Cloud Gateway自定义过滤器
•094.Spring Cloud Gateway全局过滤器
•095.Spring Cloud Gateway自定义全局过滤器
•096.Spring Cloud Gateway集成Ribbon实现负载均衡
•097.Spring Cloud Gateway集成Sentinel限流
•098.Spring Cloud Gateway集成Sentinel限流自定义错误页
•099.Spring Cloud Gateway集成Sentinel规则持久化到文件
•100.Spring Cloud Gateway集成Sentinel规则持久化到Nacos
•101.Spring Cloud Gateway内部执行流程源码分析
•102.Spring Cloud Gateway小结
•103.快速回顾
•104.Spring Cloud Gateway跨域CORS请求
•105.Spring Cloud Gateway跨域CORS请求
•106.What is SkyWalking？
•107.Skywalking运行环境部署
•108.SkyWalking Agent对微服务的链路追踪
•109.SkyWalking Agent对微服务链路追踪
•110.SkyWalking Agent加入IDEA中对微服务链路追踪
•111.SkyWalking 监控告警通知
•112.SkyWalking 监控告警通知
•113.SkyWalking 微服务链路追踪数据持久化MySQL
•114.SkyWalking 问答交流
•115.Skywalking持久化跟踪数据elasticsearch
•116.Skywalking持久化跟踪数据elasticsearch
•117.Skywalking对多个跨服务的链路跟踪
•118.Skywalking对多个跨服务的链路跟踪
•119.Skywalking自定义链路跟踪
•120.Skywalking集成logback输出traceId日志
•121.Skywalking UI界面-仪表盘
•122.Skywalking UI界面-拓扑图-追踪-性能剖析-告警
•123.Skywalking 基于nacos集群
•124.Skywalking 基于nacos集群
•125.Skywalking 基于nacos集群
•126.Skywalking 问答交流
•127.What is Seata？
•128.Seata分布式事务生命周期
•129.Seata TC Server运行环境部署
•130.Seata基于AT事务模式单体应用多数据源分布式事务
•131.Seata基于AT事务模式单体应用多数据源分布式事务
•132.Seata基于AT事务模式单体应用多数据源分布式事务
•133.Seata基于AT事务模式多个微服务分布式事务
•134.Seata基于AT事务模式多个微服务分布式事务
•135.Seata基于AT事务模式多个微服务分布式事务
•136.Seata基于AT事务模式执行机制
•137.Seata AT事务模式
•138.Seata AT事务模式写数据隔离
•139.Seata AT事务模式写数据隔离
•140.Seata AT事务模式读数据隔离
•141.Seata AT事务模式读数据隔离
•142.Seata TC Server集群环境部署
•143.Seata TC Server集群环境部署
•144.Seata TC Server集群环境集成测试
•145.Seata TC Server集群环境集成测试
•146.Seata TCC事务模式的运行机制
•147.Seata TCC事务模式SpringBoot单体应用案例
•148.Seata TCC事务模式SpringBoot单体应用案例
•149.Seata TCC事务模式SpringCloudAlibab微服务应用案例
•150.Seata TCC事务模式SpringCloudAlibab微服务应用案例
•151.What is Spring Cloud Stream
•152.Spring Cloud Stream的核心概念
•153.Spring Cloud Stream集成RocketMQ配置
•154.Spring Cloud Stream集成RocketMQ发送消息
•155.Spring Cloud Stream集成RocketMQ接收消息
•156.Spring Cloud Stream集成RocketMQ监听接收消息
•157.Spring Cloud Stream集成RocketMQ多种发送消息方式
•158.Spring Cloud Stream Starter代码分析
•159.Spring Cloud Stream集成RocketMQ发送事务消息
•160.Spring Cloud Stream集成RocketMQ对象标签消息
•161.Spring Cloud Stream问答交流
❿ Spring Cloud
本文中我们主要介绍微服务开发框架——Spring Cloud。尽管Spring Cloud带有"Cloud"的字样，但它并不是云计算解决方案，而是Spring Boot的基础上构建的，用于快速构建分布式系统的通用模式的工具集。
Spring Cloud有以下特点:
由上图可知，Spring Cloud是以 英文单词+SR+数字 的形式命名版本号的。那么英文单词和SR分别表示什么呢？
因为Spring Cloud是一个综合项目，它包含很多子项目。由于子项目也维护着自己的版本号，Spring Cloud采用了这种命名方式，从而避免与子项目的版本混淆。其中英文单词如Edware是伦敦某地铁站名，它们按照字母顺序发行，可以将其理解为主版本的演进。SR表示"Service Release"，一般表示Bug修复。
版本兼容性如下
版本内容
可参考官方文档： https://spring.io/projects/spring-cloud#overview
我的上一篇博客(微服务理论篇)中谈到，对单体应用进行服务拆分得到各个微服务，而这些服务又是相互独立的，那么我们如何知道各个微服务的健康状态、如何知道某个微服务的存在呢？由此、一个拥有服务发现的框架显得尤为重要。这也就是Eureka诞生的原因。
综上，Eureka通过心跳检查、客户端缓存等机制，确保了系统的高可用性、灵活性和可伸缩性。
通过使用Eureka已经实现了微服务的注册与发现。启动各个微服务时，Eureka Client会把自己的网络信息注册到Eureka Server上。似乎一切更美好了一些。然而，这样的架构依然有一些问题，如负载均衡。一般来说，各个微服务都会部署多个实例。那么服务消费者要如何将请求分摊到多个服务提供实例上呢？
如果服务提供者相应非常慢，那么消费者对提供者的请求就会被强制等待，知道提供者响应或超时。在高负载场景下，如果不作任何处理，此类问题可能会导致服务消费者的资源耗竭甚至整个系统崩溃。
微服务架构的应用系统通常包含多个服务层。微服务之间通过网络进行通信，从而支撑起整个应用系统，因此，微服务之间难免存在依赖关系。而这种由于"基础服务故障"导致"级联故障"的现象称为雪崩效应。
如图所示，A最为服务提供者（基础服务），B为A的服务消费者，C和D是B的服务消费者。当A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
那么Hystrix是如何容错的呢？
以下对该图做个简单讲解：
Zuul作为微服务架构中的微服务网关。微服务架构经过前几个组件的组合，已经有了基本的雏形了，那么我们为什么还要使用微服务网关呢？我们可以想象，一般情况下我们一个业务并不是只调用一个接口就可以完成一个业务需求。
如果让客户端直接与各个微服务通信，会有以下问题：
如图，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务接口。同时，还有以下优点：
为什么要同一管理微服务配置？
对于传统的单体应用，常常使用配置文件管理所有配置。例如一个Spring Boot 项目开发的单体应用，可以将配置内容放到application.yml文件中。如果需要切换环境，可以设置多个Profile,并在启用应用时指定spring.profile.active={profile}。
而在微服务架构中，微服务的配置管理一般有以下需求：