浅谈SpringCloud五⼤组件
spring cloud五⼤组件分别为：
服务发现--Netflix Eureka
客户端负载均衡--Netflix Ribbon
断路器--Netflix Hystrix
服务⽹关--Netflix Zuul
分布式配置--Spring Cloud Config
业务场景介绍：
先来给⼤家说⼀个业务场景，假设咱们现在开发⼀个电商⽹站，要实现⽀付订单的功能，流程如下：
创建⼀个订单之后，如果⽤户⽴刻⽀付了这个订单，我们需要将订单状态更新为“已⽀付”
扣减相应的商品库存
通知仓储中⼼，进⾏发货
给⽤户的这次购物增加相应的积分
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的⼤体思路如下：
⽤户针对⼀个订单完成⽀付之后，就会去订单服务，更新订单状态
订单服务调⽤库存服务，完成相应功能
订单服务调⽤仓储服务，完成相应功能
订单服务调⽤积分服务，完成相应功能
⾄此，整个⽀付订单的业务流程结束
1. 核⼼组件Eureke（服务发现）：
是微服务架构中的注册中⼼，由Eureka Client和Eureka Server两部分组成，前者负责将各个服务的信息注册到Eureka Server中。后者为注册中⼼，⾥⾯有⼀个注册表，保存了各个服务所在的机器和端⼝号；
2. 核⼼组件Feign(动态代理)：
使⽤了动态代理的机制，⽤注解定义⼀个FeignClient接⼝，向指定的服务建⽴连接、发起请求、获取响应，解析响应等等。
Feign的动态代理机制：
⾸先，对某个接⼝定义了@FeignClient注解，Feign就会针对这个接⼝创建⼀个动态代理
接着你要是调⽤这个接⼝，本质就会调⽤Feign创建的动态代理，这是核⼼中的核⼼；
Feign的动态代理会根据你接⼝上的@RequestMapping等注解，来动态构造出你要请求的服务地址；
最后针对这个地址，发起请求，解析响应；
3. 核⼼组件Ribbon（客户端负载均衡）：
Ribbon的作⽤是负载均衡，当我们要请求的服务部署在多台机器上时，Feign就不知道该请求哪台机器。此时具有负载均衡作⽤的Ribbon就会帮你在每次请求时选择⼀台机器，均匀的把请求分发到各台机器上。
Ribbon的负载均衡使⽤的是最经典的Round Robin轮询算法。简单说就是对多台机器进⾏轮流请求，然循环；
此外Ribbon是和Feign以及Eureka紧密协作的，具体如下：
⾸先Ribbon会从Eureka Client⾥获取到对应的服务注册表，知道所有的服务都部署在了哪些机器上，在监听哪些端⼝号。
然后Ribbon就使⽤默认的Round Robin轮询算法，从中选择⼀台机器；
最后Feign就会针对这台机器，构造并发起请求。
4. 核⼼组件Hystrix（断路器）
业务背景：
假设⼀个业务场景：订单服务在⼀个业务流程⾥需要调⽤三个服务。现在假设订单服务⾃⼰最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调⽤积分服务的时候，都会卡住⼏秒钟，然后抛出—个超时异常。这也是雪崩问题的雏形所在；
在上⾯的业务场景下，如果系统处于⾼并发状态，⼤量的请求涌过来的时候。订单服务的100个线程都会卡在请求积分服务这块⼉。导致订单服务没有⼀个线程可以处理请求。然后就会导致别⼈请求订单服务的时候，发现订单服务也挂了，不响应任何请求了————这个，就是微服务架构中恐怖的服务雪崩问题。
这边插⼊⼀个思考：就算积分服务挂了，订单服务也可以不挂啊？为什么？
(1). 结合业务来看：⽀付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了。
(2). 如过积分服务挂了，⼤不了等他回复之后，慢慢⼈⾁⼿⼯恢复数据！为啥⼀定要因为⼀个积分服务挂了，就直接导致订单服务也挂
了呢？
分析了这么多，就是为了引出我们的Hystrix
Hystrix是隔离、熔断以及降级的⼀个框架。Hystrix会为每个服务搞⼀个⼩⼩的线程池。
下⾯来说说，当有Hystrix参与时，积分服务挂了会是啥样的：
因为上⾯说了，Hystrix会为各个服务搞⼀个线程池，当积分服务挂了时，订单服务那⾥⽤来调⽤积分服务的线程会都卡死不能⼯作。
但是，订单服务调⽤库存服务和仓储服务的这两个线程池都能正常⼯作，所以这两个服务不会受到任何影响。
熔断————这个时候如果别⼈调⽤订单服务，订单服务还可以正常调⽤库存服务扣减库存，调⽤仓储服务通知发货。当调⽤积分服务时每次都会报错。但是既然积分服务挂了，每次调⽤都会卡⼏秒，这样显然是没有意义的。这⾥就要⽤到所谓的熔断：⽐如在五分钟内请求积分服务直接就返回了，不要⾛⽹络请求卡住⼏秒钟。
降级————上⾯说了，积分服务挂了我们就熔断然后直接返回，这显然不是最好的解决⽅法。这个时候就要⽤到降级处理：每次调⽤积分服务时，就在数据库⾥记录⼀条消息，说给某某⽤户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，就可以根据这些记录⼿⼯加⼀下积分。这就是所谓的降级处理。
⼩结：针对微服务框架的服务雪崩问题，我们会⽤到Hystrix组件，然后进⾏隔离、熔断、降级处理。
微服务网关和注册中心区别5. 核⼼组件Zuul（服务⽹关）
Zuul就是微服务⽹关。这个组件是负责⽹络路由。
如果不懂⽹络路由，那我们来看看，没有Zuul的⼯作会是怎么样的：
假设你后台部署了⼏百个服务，现在有个前端兄弟，⼈家请求是直接从浏览器那⼉发过来的。⽐如：⼈家要请求⼀下库存服务，你难道要让⼈家记住这个服务的名字叫什么什么？部署在⼏台机器上？但是后
台可能有⼏百个服务的名称和地址，这显然不能靠记；
上⾯这种情况压根⼉是⾏不通的。所以⼀般微服务架构中都必然会设计⼀个⽹关在⾥⾯，像Android、iOS、PC前端、⼩程序、H5等等，不⽤去关⼼后端有⼏百个服务，就知道有⼀个⽹关，所有的请求都⾛⽹关，⽹关会根据请求中的⼀些特征，将请求转发给后端各个服务；⽽且有了⽹关之后还可以做统⼀的降级、限流、认证授权、安全，等等；
总结：
Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉去注册表，从⽽知道其他服务在哪⾥；
（在spring cloud中，除了可以使⽤eureka作为注册中⼼外，还可以使⽤zookeeper、Consul作为注册中⼼。）
Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从⼀个服务的多台机器中选择⼀台；
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求的URL地址，发起请求；
Hystrix：发起请求是通过Hystrix的线程池来⾛的，不同的服务⾛不同的线程池，实现了不同服务调⽤的隔离，避免了服务雪崩的问题；
（Sentinel可以很好的替代Hystrix）
Zuul：如果前端、移动端要调⽤后端系统，统⼀从Zuul⽹关进⼊，由Zuul⽹关转发请求给对应的服务；
（Gateway可以很好的替代Zuul）
下⾯通过⼀张图来将Spring Cloud五组件联系起来，直观了解其底层的架构原理：
（⽹络资源）