SpringCloud核心组件与作用_springcloud核心组件及其作用

1.具体结合业务场景详细说明SpringCloud核心组件与作用

1.1 假设现在开发一个电商网站，要实现支付订单功能，流程如下：创建一个订单后，如果用户完成支付，即：订单服务需要将订单状态更新为 “已支付”。接下来扣减相应的商品库存、通知仓储中心进行发货、给用户这次购物增加相应的积分。

1.2 针对上述流程，需要：订单服务、库存服务、仓储服务、积分服务。

2. SpringCloud核心组件

2.1 Eureka

2.1.1 针对上文业务问题：订单服务想要调库存服务、仓储服务、积分服务，如何调用？Eureka就是专门来解决该类问题，附图如下。

 2.1.2 如上图

A：库存服务、仓储服务、积分服务中分别有一个Eureka Client组件，这个组件的作用是专门将相应服务的信息注册到Eureka Server中。目的就是告诉Eureka Server自己在哪台服务器上，端口号是多少。Eureka Server实际是一个注册中心，里面有一个注册表，保存各个服务的服务器地址和端口号。

B：订单服务也有一个Eureka Client组件，这个组件会从Eureka Server的注册表中获取相关服务的信息到自己本地缓存起来。

C：如果订单服务想要调用库存服务，就向自己本地的Eureka Client获取库存服务的相关地址和端口号进行调用。

2.2 Feign

2.2.1 问题：根据前文描述目前知道如何调用各个服务了，但是如何与各个服务建立网络连接呢？针对每个接口构造HTTP请求，那要疯了。

2.2.2 如果针对某个接口使用@FeignClient注解，那么Feign就会针对这个接口创建一个动态代理，你要调哪个接口，Feign 的动态代理会根据你在接口上的@RequestMapping 等注解，来动态构造出你要请求的服务的地址，然后发起请求和响应解析，流程如图。

3. Ribbon

3.1 问题：如果库存服务部署在五台机器上，那么Feign怎么知道请求到哪台机器上呢？

3.2 Ribbon专门解决上述问题，它的作用是负载均衡，会在请求的时候选择一台机器，均匀的分发到各个机器上。Ribbon默认使用轮询算法。

3.3 Ribbon工作过程：Ribbon会从Eureka Client里获取到对应的服务注册表，也就知道了服务都部署在哪些服务器上，以及对应的端口号。然后Ribbon使用轮询算法，从中选择一台机器。如下图。

4. Hystrix

4.1 场景：假设订单服务自己最多只有100个线程可以处理请求，积分服务挂了。每次订单服务调用积分服务的时候，都会卡几秒钟，然后抛出一个超时异常。

4.2 上述导致问题：如果系统处于高并发场景下，大量请求涌进来的时候，订单服务的100个线程都会卡在请求积分服务这块。导致订单服务没有一个线程可以处理请求。这样就会导致别人请求订单服务的时候，发现订单服务也挂了，这就是微服务架构中的服务雪崩问题。

4.3 问题分析：积分服务挂了，订单服务也可以不用挂。结合具体业务，对于商城而言，支付订单的时候，只要把库存扣减，然后通知仓储服务发货成功就可以。而积分业务是拓展业务，可以等待积分服务恢复之后，人工补偿积分。

4.4 问题解决

4.4.1 Hystrix是隔离、熔断以及降级的一个框架。其实就是Hystrix会搞很多小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池仅仅用于请求对于的服务。

4.4.2 积分服务挂了场景：积分服务挂了，导致订单服务调积分服务卡住，但是库存服务和仓储服务线程池都是正常工作的，所以这两个服务不会有影响。

4.4.3 熔断：比如A服务的X功能依赖B服务的某个接口，当B服务接口响应很慢时，A服务X功能的响应也会被拖慢，进一步导致了A服务的线程都卡在了X功能上，A服务的其它功能也会卡主或拖慢。此时就需要熔断机制，即A服务不在请求B这个接口，而可以直接进行降级处理。

4.4.4 降级：每次调积分服务，在数据库里记录一条消息，给某用户增加多少积分日志。此时积分服务挂了，导致没有增加成功。那么等积分服务恢复后，手动进行积分补偿，如下图。

4.4.5 熔断与降级：熔断一般是下游服务故障导致的，而服务降级一般是从整体系统负荷考虑，由调用方控制。

4.4.5 自动降级：超时、失败次数、故障、限流。如下：1-配置好超时时间(异步机制探测回复情况)；2-不稳的的api调用次数达到一定数量进行降级(异步机制探测回复情况)；3-调用的远程服务出现故障(dns、http服务错误状态码、网络故障、Rpc服务异常)，直接进行降级。

5. Zuul

5.1 问题分析：假设后台部署了几百个服务，前端的请求是从浏览器发送。此时前端请求服务端，并不需要服务器的名字，以及部署了多少台机器，只需要一个域名即可。

5.2 问题解决：微服务架构，必然会设计一个网关，前端不会关系有多少服务器，只需要知道一个网关，所有请求都通过网关进行转发到各个服务端。网关的存在还有一个好处，即：在网关层进行统一降级、限流、认证等。

6.总结