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 等等。

不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。

有一个网关之后，还有很多