SpringCloud基本使用与nacos

一 、什么是SpringCloud

1、业务场景介绍：

开发一个电商网站 , 要实现支付订单的功能 , 流程如下：
·创建一个订单之后 , 如果用户立刻支付了这个订单 , 我们需要将订单状态更新为 “ 已支付 ”
·扣减相应的商品库存
·通知仓储中心 , 进行发货
·给用户的这次购物增加相应的积分
服务分析
订单服务、库存服务、仓储服务、积分服务
流程调用
·用户针对一个订单完成支付之后，就会去找订单服务，更新订单状态
·订单服务调用库存服务，完成相应功能
·订单服务调用仓储服务，完成相应功能
·订单服务调用积分服务，完成相应功能

2、 SpringCloud

①、SpringCloud核心组件：Eureka 

Eureka是微服务架构中的注册中心，专门负责服务的注册与发现。
订单服务想要调用库存服务、仓储服务，或者是积分服务，怎么调用？
订单服务压根儿就不知道人家库存服务在哪台机器上啊！他就算想要发起一个请求，都不知道发送给谁，有心无力！

 

Eureka Client：负责将这个服务的信息注册到 Eureka Server 中
Eureka Server ：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号

②、Spring Cloud核心组件：Feign
现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。
但是新问题又来了：如何从订单服务跟其他服务建立网络连接，接着发送请求过去。

③、Spring Cloud核心组件：Ribbon  

集群服务：库存服务部署在了 5 台机器上
·192.168.169:9000
·192.168.170:9000
·192.168.171:9000
·192.168.172:9000
·192.168.173:9000
Ribbon 就是专门解决这个问题的。它的作用是 负载均衡 ，会帮你在每次请求时选择一台机器，均匀的把 请求分发到各个机器上
·首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表，也就知道了所有的服务都部署     在了哪 些机器上，在监听哪些端口号。
·然后 Ribbon 就可以使用默认的 Round Robin 算法，从中选择一台机器
·Feign 就会针对这台机器，构造并发起请求。

④、Spring Cloud核心组件：Hystrix 

在微服务架构里，一个系统会有很多的服务。
以上面的业务场景为例：订单服务在一个业务流程里需要调用三个服务。
现在假设订单服务自己最多只有 100 个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出— 个超时异常
出现问题：微服务架构中的服务雪崩问题

·如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的 100 个线程都会卡在请求积分服务这块。导致订单服务没有一个线程可以处理请求
·然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了
Hystrix 是隔离、熔断以及降级的一个框架。
比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。
每个线程池里的线程就仅仅用于请求那个服务。
积分服务挂了
会导致订单服务里的那个用来调用积分服务的线程都卡死不能工作！
但是由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到
任何影响。

这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。

只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟！
所以我们直接对积分服务熔断不就得了，比如在 5 分钟内请求积分服务直接就返回了，不要去走网络请求
卡住几秒钟，这个过程，就是所谓的熔断！

 ⑤、Spring Cloud核心组件：Zuul
这个组件是 负责网络路由 的。
一般微服务架构中都必然会设计一个 网关 在里面，像 android 、 ios 、 pc 前端、微信小程序、 H5 等等。
不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。
有一个网关之后，还有很多好处，比如可以做统一的 降级、限流、认证授权、安全 等等。

3、组件总和

Eureka ：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka           Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
Ribbon ：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign ：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix ：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不          同服务调用的隔离，避免了服务雪崩的问题
Zuul ：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对        应的服务
流程
1. 请求统一通过 API 网关（ Zuul ）来访问内部服务 .
2. 网关接收到请求后，从注册中心（ Eureka ）获取可用服务
3. 由 Ribbon 进行均衡负载后，分发到后端具体实例
4. 微服务之间通过 Feign 进行通信处理业务
5. Hystrix 负责处理服务超时熔断