首页天道酬勤springcloud的五大组件,springcloud分布式事务

springcloud的五大组件,springcloud分布式事务

张世龙 05-06 06:45 36次浏览

目录一、先看springCloud的照片,二、什么是springCloud? 三、为便于理解,一个业务场景四、SpringCloud核心组件eureka (类似zookeeper )五、SpringCloud核心组件: Feign (类似dubbo )六、SpringCloud核心组件

一、请先看springCloud的照片

二、什么是斯普林云? “Spring Cloud为开发人员提供了在分布式系统中快速构建常见模式的工具,包括配置管理、服务发现、断路器、智能路由、微代理和控制总线。 分布式系统的协调创建了一个模板模型,开发人员可以使用Spring Cloud快速支持实现这些模型的服务和APP应用程序。 他们可以在任何分布式环境中正常工作,包括开发人员自己的笔记本电脑、裸机数据中心和主机平台(如Cloud Foundry )。 ”---来自官网

三、为了便于理解,假设一个业务场景,目前开发电子商务网站,实现支付订单功能:的流程如下。 -

1 .如果创建订单后用户立即支付了此订单,则我们需要将此订单的状态更新为(已支付)

2 .扣除对应商品库存

3 .通知仓库中心并发货

4 .用户在这次购物中如何加对应积分

上述流程需要订单服务、库存服务、仓库服务和积分服务。 整个过程的大致想法如下。

用户对一个订单支付完毕后,返回查找订单服务,更新订单情况订单服务调用库存服务,完成相应的功能订单服务调用仓库服务,完成相应的功能订单服务调用积分服务,相应的

四. SpringCloud核心组件的eureka (类似zookeeper ) )首先考虑一个问题,订单服务调用库存服务、仓库服务、积分服务,怎么调用呢

a )订单服务不知道上述服务位于哪个服务器上,无法调用。 但是,Eureka的作用是告诉订单服务哪个服务器上有想要调用的服务。 Eureka有客户端和服务端,每个服务都有Eureka客户端,如果可以在Eureka服务端注册有关本服务的信息,我们的订单服务就会找到库存服务、仓库服务和积分服务

我们的上述业务使用Eureka后如下图所示。

总结:

欧盟Eurake客户端:负责在Eureka服务器端注册此服务的信息

Eureka服务端:相当于注册中心,有注册表。 注册表存储每个服务所在的计算机和端口号,您可以在Eureka服务器端找到每个服务

五、SpringCloud的核心组件:通过feign (如dubbo )上的Eureka,现在订单服务确实知道库存服务、积分服务、仓储服务在哪里,但怎么做这些服务自己写很多代码调用很辛苦。 SpringCloud已经为我们准备了核心组件。 费英格云

订单服务:

库存服务:

没有用于建立基础连接、构建请求和分析响应的代码。 直接注释只需定义FeignClient接口并调用该接口即可。 人的Feign Client根据您的评论,建立与您指定服务的连接、构建请求、触发请求、获取响应和解析响应。 这一系列肮脏的工作,都是人Feign给我做的。

问题是,Feign是怎么做到的呢? 事实上,Feign的一个机制是使用动态代理:

首先,当您为某个接口定义@FeignClient注释时,Feign会为该接口创建动态代理,然后调用该接口,本质上就是调用Feign创建的动态代理这是因为作为核心中核心的Feign动态代理根据接口上的注释(如@RequestMapping )动态构建最后请求的服务的地址

六.可以在springCloud核心组件:Ribbon上的Eureka中找到服务,然后在Feign中调用服务。 但是,如果清单服务位于多台计算机上,我应该使用Feign调用哪个以上的服务呢? 这个时候,Ribbon需要闪亮登场。 那个在服务消费者方面配置使用。 其作用是负荷分散。 默认情况下使用的负载平衡算法是轮询算法,功能区从Eureka服务器端获取相应的服务注册表,并知道服务的位置。 功能区根据设计的负载平衡算法选择计算机,Feigin将为这些计算机创建并发送请求。 请参考下图。

七、SpringCloud的核心组件: Hystrix在微服务框架中,一个系统有多个服务。 以本文的业务场景为例,订单服务需要在一个业务流程中调用三种服务。 假设现在订单服务本身最多只能处理100个线程的请求,如果积分服务错误,订单服务每次调用积分服务就会受阻几秒钟,然后抛出,造成超时异常。

这会引起什么问题呢? 在系统高度并发的情况下,当大量请求蜂拥而至时,订单服务的100个线程将处于积分服务的领先地位

致订单服务没有一个多余的线程可以处理请求,这种问题就是微服务架构中恐怖的服务器雪崩问题,这么多的服务互相调用要是不做任何保护的话,某一个服务挂掉会引起连锁反应,导致别的服务挂掉,上述描述如下图所示:
但是我们想一下,即使积分服务挂了,那订单服务也不应该挂掉啊,我们只要让存储服务和仓储服务正常工作就可以了,至于积分服务我们后期可以手动给用户加上积分,这个时候就轮到Hystrix闪亮登场了,Hystrix是隔离、熔断以及降级的一个框架,说白了就是Hystrix会搞很多小线程池然后让这些小线程池去请求服务,返回结果,Hystrix相当于是个中间过滤区,如果我们的积分服务挂了,那我们请求积分服务直接就返回了,不需要等待超时时间结束抛出异常,这就是所谓的熔断,但是也不能啥都不干就返回啊,不然我们之后手动加积分咋整啊,那我们每次调用积分服务就在数据库里记录一条消息,这就是所谓的降级,Hystrix隔离、熔断和降级的全流程如下:

八、SpringCloud核心组件:zull(类似于服务器端的nginx)

该组件是负责网络路由的,假设你后台部署了几百个服务,现在有个前端兄弟,人家请求是直接从浏览器那儿发过来的。打个比方:人家要请求一下库存服务,你难道还让人家记着这服务的名字叫做inventory-service,并且部署在5台机器上,就算人家肯记住这一个,那你后台可有几百个服务的名称和地址呢?难不成人家请求一个,就得记住一个?哈哈哈

上面这种情况,压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关rrdct,像android、ios、pc前端、微信小程序、H5等等,不用去关心后端有几百个服务,就知道有一个网关,所有请求都往网关走,网关会根据请求中的一些特征,将请求转发给后端的各个服务。

九、简单总结

Eureka:
服务启动的时候,服务上的Eureka客户端会把自身注册到Eureka服务端,并且可以通过Eureka服务端知道其他注册的服务
Ribbon:
服务间发起请求的时候,服务消费者方基于Ribbon服务做到负载均衡,从服务提供者存储的多台机器中选择一台,如果一个服务只在一台机器上面,那就用不到Ribbon选择机器了,如果有多台机器,那就需要使用Ribbon选择之后再去使用
Feign:
Feign使用的时候会集成Ribbon,Ribbon去Eureka服务端中找到服务提供者的所在的服务器信息,然后根据随机策略选择一个,拼接Url地址后发起请求
Hystrix:
发起的请求是通过Hystrix的线程池去访问服务,不同的服务通过不同的线程池,实现了不同的服务调度隔离,如果服务出现故障,通过服务熔断,避免服务雪崩的问题 ,并且通过服务降级,保证可以手动实现服务正常功能
Zuul:
如果前端调用后台系统,统一走zull网关进入,通过zull网关转发请求给对应的服务
图片总结更清晰:

注意:想看SpringCloud Demo的同学可以看这篇文章:https://blog.csdn.net/qq_42449963/article/details/105197679

单体架构和分布式架构,扫黑除恶专项总览图