spring cloud五大组件分别为：
-
服务发现--Netflix Eureka
-
客户端负载均衡--Netflix Ribbon
-
断路器--Netflix Hystrix
-
服务网关--Netflix Zuul
-
分布式配置--Spring Cloud Config
业务场景介绍：
先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下： -
创建一个订单之后，如果用户立刻支付了这个订单，我们需要将订单状态更新为“已支付”
-
扣减相应的商品库存
-
通知仓储中心，进行发货
-
给用户的这次购物增加相应的积分
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：
-
用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态
-
订单服务调用库存服务，完成相应功能
-
订单服务调用仓储服务，完成相应功能
-
订单服务调用积分服务，完成相应功能
至此，整个支付订单的业务流程结束
-
核心组件Eureke（服务发现）：
是微服务架构中的注册中心，由Eureka Client和Eureka Server两部分组成，前者负责将各个服务的信息注册到Eureka Server中。后者为注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号； -
核心组件Feign(动态代理)：
使用了动态代理的机制，用注解定义一个FeignClient接口，向指定的服务建立连接、发起请求、获取响应，解析响应等等。
Feign的动态代理机制：
- 首先，对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理
- 接着你要是调用这个接口，本质就会调用Feign创建的动态代理，这是核心中的核心；
- Feign的动态代理会根据你接口上的@RequestMapping等注解，来动态构造出你要请求的服务地址；
- 最后针对这个地址，发起请求，解析响应；
- 核心组件Ribbon（客户端负载均衡）：
- Ribbon的作用是负载均衡，当我们要请求的服务部署在多台机器上时，Feign就不知道该请求哪台机器。此时具有负载均衡作用的Ribbon就会帮你在每次请求时选择一台机器，均匀的把请求分发到各台机器上。
- Ribbon的负载均衡使用的是最经典的Round Robin轮询算法。简单说就是对多台机器进行轮流请求，然循环；
- 此外Ribbon是和Feign以及Eureka紧密协作的，具体如下：
- 首先Ribbon会从Eureka Client里获取到对应的服务注册表，知道所有的服务都部署在了哪些机器上，在监听哪些端口号。
- 然后Ribbon就使用默认的Round Robin轮询算法，从中选择一台机器；
- 最后Feign就会针对这台机器，构造并发起请求。
- 核心组件Hystrix（断路器）
业务背景：
- 假设一个业务场景：订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。这也是雪崩问题的雏形所在；
- 在上面的业务场景下，如果系统处于高并发状态，大量的请求涌过来的时候。订单服务的100个线程都会卡在请求积分服务这块儿。导致订单服务没有一个线程可以处理请求。然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了————这个，就是微服务架构中恐怖的服务雪崩问题。
这边插入一个思考：就算积分服务挂了，订单服务也可以不挂啊？为什么？
(1). 结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了。
(2). 如过积分服务挂了，大不了等他回复之后，慢慢人肉手工恢复数据！为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢？
分析了这么多，就是为了引出我们的Hystrix
- Hystrix是隔离、熔断以及降级的一个框架。Hystrix会为每个服务搞一个小小的线程池。
下面来说说，当有Hystrix参与时，积分服务挂了会是啥样的： - 因为上面说了，Hystrix会为各个服务搞一个线程池，当积分服务挂了时，订单服务那里用来调用积分服务的线程会都卡死不能工作。但是，订单服务调用库存服务和仓储服务的这两个线程池都能正常工作，所以这两个服务不会受到任何影响。
- 熔断————这个时候如果别人调用订单服务，订单服务还可以正常调用库存服务扣减库存，调用仓储服务通知发货。当调用积分服务时每次都会报错。但是既然积分服务挂了，每次调用都会卡几秒，这样显然是没有意义的。这里就要用到所谓的熔断：比如在五分钟内请求积分服务直接就返回了，不要走网络请求卡住几秒钟。
- 降级————上面说了，积分服务挂了我们就熔断然后直接返回，这显然不是最好的解决方法。这个时候就要用到降级处理：每次调用积分服务时，就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，就可以根据这些记录手工加一下积分。这就是所谓的降级处理。
小结：针对微服务框架的服务雪崩问题，我们会用到Hystrix组件，然后进行隔离、熔断、降级处理。
- 核心组件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五组件联系起来，直观了解其底层的架构原理：
（网络资源）
