Spring Cloud 各个组件角色简介

概述

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

组件介绍

- 服务发现 Eureka
- 服务路由 Ribbon
- RPC 调用 Feign
- 网络流量整形以及断路器 
- Api 网关智能代理 zuul
- 配置中心 Spring Cloud Config

简单理解：

一、Eureka 服务发现
接入后，每一个节点都是一个 Eureka Client，会将本节点对应的地址端口信息汇总注册到 Eureka Server，server 端缓存了全部的服务信息，供客户端调用。
调用服务族中的任何服务都是经过 Eureka Server 返回的信息肯定。

二、Feign 远程调用
须要调用的其余服务接口时，经过 @FeignClient 注解动态代理生成对应的实现类，最终减小了调用代码的编写。

三、Ribbon 服务路由
步骤二中咱们使用 @FeignClient 注解有一个name 属性，表示服务的惟一标识名，那么假如某一服务有多个节点，他是不知道该访问哪个节点的。这个时候就须要一种路由机制，来肯定最终为咱们提供服务的节点。
路由策略默认是 轮询策略。能够定义responseTime weight这种方式。

四、Hystrix 服务熔断/降级
服务之间相互调用，因为增长了中间网络的存在，确定会出现服务不可用或相应缓慢的状况。
假如一个服务有问题，调用方的全部线程都阻塞在该服务上，致使调用方的服务也挂了，这是不该该的。
因此，Hystrix 是处理这种状况的。它会划分出一个个的线程池，每个服务一个线程池，加入问题线程池满了，不会影响到其余服务的线程池的状况。这就是隔离机制。
更进一步，服务一致有问题，也就没有必要去调用了，因此能够设定一个机制，好比出问题后，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