Fegin 和 Ribbon 客户端负载均衡 Hystrix熔断降级 zuul网关

微服务：
基于dubbo的微服务架构、基于Spring Cloud的微服务架构
1）Dubbo仅仅是一个RPC框架，实现Java程序的远程调用，实施服务化的中间件需要自己开发；
2）Spring Cloud restful是实施微服务的一系列套件，包括：服务注册与发现、断路器、服务状态监控、配置管理、智能路由、一次性令牌、全局锁、分布式会话管理、集群状态管理等。

服务间调用：
在Spring cloud 中服务之间通过restful方式调用有两种方式
- restTemplate+Ribbon
- feign

Ribbon
Ribbon 是一个基于 HTTP 和 TCP 客户端的负载均衡器
它可以在客户端配置 ribbonServerList（服务端列表），然后轮询请求以实现均衡负载，它在联合 Eureka 使用时
ribbonServerList 会被 DiscoveryEnabledNIWSServerList 重写，扩展成从 Eureka 注册中心获取服务端列表
同时它也会用 NIWSDiscoveryPing 来取代 IPing，它将职责委托给 Eureka 来确定服务端是否已经启动。

Feign
Spring Cloud Netflix 的微服务都是以 HTTP 接口的形式暴露的，所以可以用 Apache 的 HttpClient 或 Spring 的 RestTemplate 去調用
而 Feign 是一個使用起來更加方便的 HTTP 客戶端，就好像調用本地方法一樣，完全感覺不到是調用的遠程方法
总结起来就是：发布到注册中心的服务方接口，是 HTTP 的，也可以不用 Ribbon 或者 Feign，直接浏览器一样能够访问
只不过 Ribbon 或者 Feign 调用起来要方便一些，最重要的是：它俩都支持软负载均衡
注意：spring-cloud-starter-feign 里面已经包含了 spring-cloud-starter-ribbon（Feign 中也使用了 Ribbon）。

从实践上看，采用feign的方式更优雅（feign内部也使用了ribbon做负载均衡）。

zuul也有负载均衡的功能，针对外部请求做负载，ribbon客户端的负载均衡

客户端ribbon的负载均衡，解决的是服务发起方（在Eureka注册的服务）对被调用的服务的负载，比如我们查询商品服务要调用显示库存和商品明细服务，通过商品服务的接口将两个服务组合，可以减少外部应用的请求，比如手机App发起一次请求即可，可以节省网络带宽，也更省电。

ribbon是对服务之间调用做负载，是服务之间的负载均衡，zuul是可以对外部请求做负载均衡

Hystrix 熔断、降级
1）启动熔断器， @HystrixCommand(fallbackMethod ="" ) 出现错误是调用，防止雪崩
2）降级 api 接口中设置 @FeignClient(value = "微服务名称",fallbackFactory = 类.class) //指明服务关闭后，会返回方法的类的字节码 资源不够时调用。

zuul网关()
使用的是阻塞式的 API，不支持长连接，比如 websockets。底层是servlet，Zuul处理的是http请求
没有提供异步支持，流控等均由hystrix支持,依赖包spring-cloud-starter-netflix-zuul。

Gateway：
底层依然是servlet，但使用了webflux，多嵌套了一层框架
依赖spring-boot-starter-webflux和/ spring-cloud-starter-gateway
提供了异步支持，提供了抽象负载均衡，提供了抽象流控，并默认实现了RedisRateLimiter。

spring-webflux支持两种开发模式：
（1）类似于Spring WebMVC的基于注解（@Controller、@RequestMapping）的开发模式；
（2）Java 8 lambda风格的函数式开发模式。

2、WebFlux是基于响应式流的，可以用来建立异步、非阻塞、事件驱动的服务。默认采用Reactor作为响应式流的实现库，也提供对RxJava的支持。