为什么要统一管理微服务配置对于Spring Boot单体应用，在启动时指定spring.profiles.active={profile}来加载不同环境下的配置。 在微服务架构中，这种方式未必适用，微服务架构对配置管理有着更高的要求，如：

Spring Cloud中，Zuul默认已经整合了Hystrix，而Hystrix有隔离策略——THREAD及SEMAPHORE。 隔离策略 默认情况下，Zuul的隔离策略是SEMAPHORE 。 可设置zuul.ribbonIsolati

Spring Cloud中，Zuul默认已经整合了Hystrix。 Zuul回退编写Zuul回退类: @Component public class MyFallbackProvider implements FallbackProvide

过滤器类型与请求生命周期 PRE：这种过滤器在请求被路由之前调用。可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。 ROUTING：这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求，并使用Apach

为什么要用微服务网关如下图，外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与微服务通信会产生以下的问题： 客户端会多次请求不同的微服务，增加了客户端的复杂性。 存在跨域请求，在一定场景下处理比较复杂。 认证复杂

Hystrix的监控 为客户端添加spring-boot-starter-actuator依赖； 访问http://127.0.0.1:8010/hystrix.stream，就会不断刷新如下监控数据: ping: data: {"t

Hystrix的隔离策略有两种： 线程隔离 信号量隔离 THREAD(线程隔离)：使用该方式，HystrixCommand将会在单独的线程上执行，并发请求受线程池中线程数量的限制。Hystrix中默认并且推荐使用线程隔离。 SEMAPHO

Spring Cloud默认已经为Feign整合了Hystrix，要想打开Hystrix支持。 Feign使用Hystrix 配置文件添加: feign: hystrix: enabled: true 编写Feign接口:

实现容错的手段雪崩效应我们常把”基础服务故障”导致”级联故障”的现象称为雪崩效应。雪崩效应描述的是提供者不可用导致消费者不可用，并将不可用逐渐放大的过程。 如图所示，A 作为服务提供者(基础服务)，B 为 A 的服务消费者，C 和 D 是

Feign简介在负载均衡篇的示例中使用RestTemplate实现REST API调用: @GetMapping("/user/{id}") public User findById(@PathVariable Long id) {

Ribbon简介 Ribbon是Netflix发布的负载均衡器，它有助于控制 HTTP 和 TCP 的客户端的行为。为Ribbon配置服务提供者地址后，Ribbon就可基于某种负载均衡算法，自动地帮助服务消费者去请求。Ribbon默认为我们

Eureka简介 Eureka是Netflix开源的服务发现组件，本身是一个基于 REST 的服务。包含Server和Client两部分。Spring Cloud将它集成在子项目Spring Cloud Netflix中，从而实现微服务的注