Spring Cloud 各个组件角色简介

概述

SpringCloud 是一个全家桶式的技术栈，包含了很多组件；包含 Eureka、Ribbon、Feign、Zuul 、Hystrix等。每个组件完成对应的功能

组件介绍

    - 服务发现 Eureka

- 服务路由 Ribbon

- RPC 调用 Feign

- 网络流量整形以及断路器

- Api 网关智能代理 zuul

- 配置中心 Spring Cloud Config

简单理解：

1、Eureka 服务发现

接入后，每个节点都是一个 Eureka Client，会将本节点对应的地址端口信息汇总注册到 Eureka Server，server 端缓存了所有的服务信息，供客户端调用。

调用服务族中的任何服务都是通过 Eureka Server 返回的信息确定。

2、Feign 远程调用

需要调用的其他服务接口时，通过 @FeignClient 注解动态代理生成对应的实现类，最终减少了调用代码的编写。

3、Ribbon 服务路由

步骤二中我们使用 @FeignClient 注解有一个name 属性，表示服务的唯一标识名，那么假如某一服务有多个节点，他是不知道该访问哪一个节点的。这个时候就需要一种路由机制，来确定最终为我们提供服务的节点。

路由策略默认是轮询策略。可以定义responseTime weight这种方式。

4、Hystrix 服务熔断/降级

服务之间相互调用，由于增加了中间网络的存在，肯定会出现服务不可用或相应缓慢的情况。

假如一个服务有问题，调用方的所有线程都阻塞在该服务上，导致调用方的服务也挂了，这是不应该的。

所以，Hystrix 是处理这种情况的。它会划分出一个个的线程池，每一个服务一个线程池，加入问题线程池满了，不会影响到其他服务的线程池的情况。这就是隔离机制。

更进一步，服务一致有问题，也就没有必要去调用了，所以可以设定一个机制，比如出问题后，5分钟内的调用都会直接返回。这就是熔断的机制。

那么直接返回也不是很优雅，我应该要做点什么来应对服务恢复的情况，比方说记录下请求的参数，以及目的。等待服务恢复之后，可以把这一段的业务恢复到原来的情况。这种机制就是服务降级。

5、Zuul 微服务网关

一般微服务架构中都必然会设计一个网关在里面，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。

而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。

总结：

最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：

Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务

ref:https://juejin.im/post/5be13b83f265da6116393fc7