SpringCloud的五⼤组件详解
⾸先看⼀张springCloud的图⽚:
⼆、简单介绍下什么是springCloud
“Spring Cloud为开发⼈员提供了快速构建分布式系统中⼀些常见模式的⼯具（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线）。分布式系统的协调导致了样板模式, 使⽤Spring Cloud开发⼈员可以快速地⽀持实现这些模式的服务和应⽤程序。他们将在任何分布式环境中运⾏良好，包括开发⼈员⾃⼰的笔记本电脑，裸机数据中⼼，以及Cloud Foundry等托管平台。” -----来⾃官⽹
三、为了⽅便理解假设⼀个业务场景
假设现在开发⼀个电商⽹站，要实现⽀付订单功能：流程如下–
1.创建⼀个订单后，如果⽤户⽴刻⽀付了这个订单，我们需要将这个订单状态更新为(已经⽀付)
2.扣减相对应的商品库存
3.通知仓储中⼼，进⾏发货
4.给⽤户这次购物怎加相对应的积分
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务，整个流程的⼤体思路如下：
1.⽤户针对⼀个订单完成⽀付后，就回去订单服务，更新订单状态
2.订单服务调⽤库存服务，完成相应的功能
3.订单服务调⽤仓储服务，完成相应的功能
4.订单服务调⽤积分服务，完成相应的功能
整个过程可以如下图所⽰:
四、SpringCloud核⼼组件Eureka（类似于zookeeper）
⾸先考虑⼀个问题，订单服务要调⽤库存服务、仓储服务、积分服务，如何调⽤呢？
答：订单服务根本不知道上述服务在哪台服务器上，所以没法调⽤，⽽Eureka的作⽤就是来告诉订单服务它想调⽤的服务在哪台服务器上，Eureka有客户端和服务端，每⼀个服务上⾯都有Eureka客户端，可以把本服务的相关信息注册到Eureka服务端上，那么我们的订单服务就可以就可以到库存服务、仓储服务、积分服务了
我们上述的业务使⽤Eureka后如下图：
总结：
Eurake客户端：负责将这个服务的信息注册到Eureka服务端中
Eureka服务端：相当于⼀个注册中⼼，⾥⾯有注册表，注册表中保存了各个服务所在的机器和端⼝号，可以通过Eureka服务端到各个服务
五、SpringCloud核⼼组件：Feign（类似于dubbo）
通过上⾯的Eureka，现在订单服务确实知道库存服务、积分服务、仓储服务在哪了，但是我们如何去调⽤这些服务呢，如果我们⾃⼰去写很多代码调⽤那就太⿇烦了，⽽SpringCloud已经为我们准备好了⼀个核⼼组件：Feign，接下来看如何通过Feign让订单服务调⽤库存服务，注意Feign也是⽤在消费者端的；
spring到底是干啥的订单服务：
库存服务：
没有底层的建⽴连接、构造请求、解析响应的代码，直接就是⽤注解定义⼀个 FeignClient接⼝，然后调⽤那个接⼝就可以了。⼈家Feign Client会在底层根据你的注解，跟你指定的服务建⽴连接、构造请求、发起靕求、获取响应、解析响应，等等。这⼀系列脏活累活，⼈家Feign全给你⼲了。
问题来了,Feign是如何做到的呢?其实Feign的⼀个机制就是使⽤了动态代理：
⾸先，如果你对某个接⼝定义了@FeignClient注解，Feign就会针对这个接⼝创建⼀个动态代理
接着你要是调⽤那个接⼝，本质就是会调⽤ Feign创建的动态代理，这是核⼼中的核⼼
Feign的动态代理会根据你在接⼝上的@RequestMapping等注解，来动态构造出你要请求的服务的地址
最后针对这个地址，发起请求、解析响应
六、springCloud核⼼组件:Ribbon
上⾯可以通过Eureka可以到服务，然后通过Feign去调⽤服务，但是如果有多台机器上⾯都部署了库存服务，我应该使⽤Feign去调⽤哪⼀台上⾯的服务呢，这个时候就需要Ribbon闪亮登场了，它在服务消费者端配置和使⽤，它的作⽤就是负载均衡，然后默认使⽤的负载均衡算法是轮询算法，Ribbon会从Eureka服务端中获取到对应的服务注册表，然后就知道相应服务的位置，然后Ribbon根据设计的负载均衡算法去选择⼀台机器，Feigin就会针对这些机器构造并发送请求
如下图所⽰：
七、SpringCloud的核⼼组件：Hystrix
在微服务架构⾥，⼀个系统会有多个服务，以本⽂的业务场景为例：订单服务在⼀个业务流程⾥需要调⽤三个服务，现在假设订单服务⾃⼰最多只有100个线程可以处理请求，如果积分服务出错，每次订单服务调⽤积分服务的时候，都会卡住⼏秒钟，然后抛出—个超时异常。
分析下这样会导致什么问题呢？如果系统在⾼并发的情况下，⼤量请求涌过来的时候，订单服务的100
个线程会卡在积分服务这块，导致订单服务没有⼀个多余的线程可以处理请求，这种问题就是微服务架构中恐怖的服务器雪崩问题，这么多的服务互相调⽤要是不做任何保护的话，某⼀个服务挂掉会引起连锁反应，导致别的服务挂掉
上述描述如下图所⽰：
但是我们想⼀下，即使积分服务挂了，那订单服务也不应该挂掉啊，我们只要让存储服务和仓储服务正常⼯作就可以了，⾄于积分服务我们后期可以⼿动给⽤户加上积分，这个时候就轮到Hystrix闪亮登场了，Hystrix是隔离、熔断以及降级的⼀个框架，说⽩了就是Hystrix会搞很多⼩线程池然后让这些⼩线程池去请求服务，返回结果，Hystrix相当于是个中间过滤区，如果我们的积分服务挂了，那我们请求积分服务直接就返回了，不需要等待超时时间结束抛出异常，这就是所谓的熔断，但是也不能啥都不⼲就返回啊，不然我们之后⼿动加积分咋整啊，那我们每次调⽤积分服务就在数据库⾥记录⼀条消息，这就是所谓的降级，Hystrix隔离、熔断和降级的全流程如下：
⼋、SpringCloud核⼼组件：zull（类似于服务器端的nginx）
该组件是负责⽹络路由的，假设你后台部署了⼏百个服务，现在有个前端兄弟，⼈家请求是直接从浏览器那⼉发过来的。打个⽐⽅：⼈家要

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。