请选择 进入手机版 | 继续访问电脑版

分布式系统及 SpringCloud学习日记Day3

[复制链接]
小小海 发表于 2021-1-2 19:00:28 | 显示全部楼层 |阅读模式 打印 上一主题 下一主题
负载平衡

根本概念:Load balancing,即负载平衡,用来在多个盘算机(盘算机集群)、网络毗连、CPU、磁盘驱动器或其他资源中分配负载,以到达最优化资源、最大化吞吐率、最小化响应时间、同时制止过载的目标
思想泉源(为什么需要负载平衡):
样例:我们在日常生活中经常不可制止需要去一些人多比力拥挤的地方,比如地铁站、火车站、影戏院、银行等。无论是买票,照旧列队入场,这些场所一般都会设置多个服务点大概入口。如果没有人加以引导的话,大多数情况下会发生:最近的入口处会挤满人而那些偏远的服务点大概入口就不太有人
显然这种情况下,会导致资源的浪费,因为如果可以把这些列队的人很好的分散到各个入口的话会大大缩短列队的时间。同理,网站的建立也是一样的。为了提升网站的服务本领,许多网站接纳集群摆设,就像话剧院有多个入口一样。这时候,就需要一个协调者,来平衡的分配这些用户的请求,可以让用户的可以匀称的分派到差别的服务器上。
实际应用:为了提升网站的各方面本领,我们一般会把多台呆板组成一个集群对外提供服务。然而,我们的网站对外提供的访问入口都是一个的,比如www.taobao.com。那么当用户在欣赏器输入www.taobao.com的时候如何将用户的请求分发到集群中差别的呆板上呢,这就是负载平衡在做的事情。
所谓负载平衡,也就是将负载(工作任务,访问请求)举行平衡、分摊到多个利用单元(服务器,组件)上举行执行。是管理高性能,单点故障(高可用),扩展性(水平伸缩)的终极管理方案。

服务调用

RPC(Remote Procedure Call)

远程方法调用,简朴的明白就是一个节点请求另一个节点提供的服务
RPC执行过程:

  • 首先客户端需要告诉服务器,需要调用的函数,这里函数和进程ID存在一个映射,客户端远程调用时,需要查一下函数,找到对应的ID,然后执行函数的代码。
  • 客户端需要把当地参数传给远程函数,当地调用的过程中,直接压栈即可,但是在远程调用过程中不再同一个内存里,无法直接通报函数的参数,因此需要客户端把参数转换成字节省,传给服务端,然后服务端将字节省转换成自身能读取的格式,是一个序列化和反序列化的过程。
  • 数据准备好了之后,网络传输层需要把调用的ID和序列化后的参数传给服务端,然后把盘算好的效果序列化传给客户端,因此TCP层即可完成上述过程,gRPC中接纳的是HTTP2协议。
gRPC与REST



  • REST通常以业务为导向,将业务对象上执行的利用映射到HTTP动词,格式非常简朴,可以使用欣赏器举行扩展和传输,通过JSON数据完成客户端和服务端之间的消息通信,直接支持请求/响应方式的通信。不需要中间的署理,简化了系统的架构,差别系统之间只需要对JSON举行剖析和序列化即可完成数据的通报。
  • REST也存在一些毛病,比如只支持请求/响应这种单一的通信方式,对象和字符串之间的序列化利用也会影响消息通报速度,客户端需要通过服务发现的方式,知道服务实例的位置,在单个请求获取多个资源时存在着挑战,而且有时候很难将所有的动作都映射到HTTP动词。
  • 因为REST面对一些问题,因此可以接纳gRPC作为一种替代方案,gRPC 是一种基于二进制流的消息协议,可以接纳基于Protocol Buffer的IDL界说grpc API,这是Google公司用于序列化布局化数据提供的一套语言中立的序列化机制,客户端和服务端使用HTTP/2以Protocol Buffer格式交换二进制消息。
  • gRPC的优势是,设计复杂更新利用的API非常简朴,具有高效紧凑的进程通信机制,在交换大量消息时效率高,远程过程调用和消息通报时可以接纳双向的流式消息方式,同时客户端和服务端支持多种语言编写,互利用性强;不外gRPC的缺点是不方便与JavaScript集成,某些防火墙不支持该协议。
  • 注册中心:作为服务与服务地点映射的中介,客户端通过服务向注册中心举行请求,注册中心返回给客户端相应的服务地点,客户端根据返回的地点和端口,去调用远程服务端的方法,执行完成之后将效果返回给客户端。这样在服务端加新功能的时候,客户端不需要直接感知服务端的方法,服务端将更新之后的效果在注册中心注册即可,而且当修改了服务端某些方法的时候,大概服务降级服务多机摆设想实现负载平衡的时候,我们只需要更新注册中心的服务群即可。
使用RPC远程服务调用方式与传统http接口直接调用方式的差别在于:

  • 从使用上来看:Http接口只关注服务端,对于客户端怎么调用、调用方式并不关心,通常情况下,客户端使用Http方式举行调用时,只要将内容举行传输即可,这样客户端在使用时,需要更关注网络方面的传输,比力不适用与业务方面的开发;
    而RPC服务则需要客户端接口与服务端保持一致,服务端提供一个方法,客户端通过接口直接发起调用,业务开发人员仅需要关注业务方法的调用即可,不再关注网络传输的细节,在开发上更为高效。(PRC是服务端提供好方法给客户端调用。定位到类,然后通过类去调用方法。)
  • 性能上来看:虽然使用Http时,Http自己提供了丰富的状态功能与扩展功能,但也正由于Http提供的功能过多,导致在网络传输时,需要携带的信息更多,从性能角度上讲,较为低效;
    而RPC服务网络传输上仅传输与业务内容相关的数据,传输数据更小,性能更高。
  • 从运维角度看,使用Http接口时,经常使用一个前端署理,来举行Http转发署理请求的利用,需要举行扩容时,则需要去修改署理服务器的设置,较为繁琐,也容易堕落;
    而使用RPC方式的微服务,则只要增加一个服务节点即可,注册中心可自动感知到节点的变革,通知调用客户端举行负载的动态控制,更为智能,省去运维的利用。


  • 实现技能方案:比力原始的方案是,接纳Socket通信、动态署理与反射与Java原生的序列化。
  • RPC框架架构:1.服务提供者(服务器端),提供服务接口界说与服务实现类。 2. 服务中心(服务器端),负责将当地服务发布成远程服务,管理远程服务,提供给服务消费者使用。3. 服务消费者(客户端),通过远程署理对象调用远程服务。
RPC:所谓的远程过程调用(面向方法)
REST:(面向资源)
服务网关

根本概念:服务网关 = 路由器 + 过滤器
1、吸收一切外界请求,转发到后端的微服务上去;
2、在服务网关中可以完成一系列的横切功能,比方权限校验、限流以及监控等
这些都可以通过过滤器完成(实在路由转发也是通过过滤器实现的)
思想泉源(为什么需要服务网关):
以上所述的横切功能(以权限校验为例),可以写在三个位置:

  • 每个服务自己实现一遍
  • 写到一个公共的服务中,然后其他所有服务都依赖这个服务
  • 写到服务网关的前置过滤器中,所有请求过来举行权限校验
第一种,缺点太过显着,根本不接纳;
第二种,相较于第一种来说,代码开发不会冗余,但会有两个缺点:
由于每个服务引入了这个公共服务,那么相当于在每个服务中都引入了相同的权限校验的代码,使得每个服务的jar包巨细无故增加了一些,尤其是对于使用docker镜像举行摆设的场景,jar越小越好;
由于每个服务都引入了这个公共服务,那么我们后续升级这个服务大概就比力困难,而且公共服务的功能越多,升级就越难,而且假设我们改变了公共服务中的权限校验的方式,想让所有的服务都去使用新的权限校验方式,我们就需要将之前所有的服务都重新引包,编译摆设。
而第三种服务网关恰好可以管理这样的问题:
将权限校验的逻辑写在网关的过滤器中,后端服务不需要关注权限校验的代码,所以服务的jar包中也不会引入权限校验的逻辑,不会增加jar包巨细;
如果想修改权限校验的逻辑,只需要修改网关中的权限校验过滤器即可,而不需要升级所有已存在的微服务。
服务网关的根本功能:

  • 智能路由:吸收外部一切请求,并转发到后端的对外服务open-service上去;(注意:只转发请求)
  • 权限校验:只校验用户向open-service服务的请求,不校验服务内部的请求;
  • API监控:只监控颠末网关的请求,以及网关自己的一些性能指标(比方,gc等);
  • 限流:与监控共同,举行限流利用;
  • API日志统一收集:类似于一个aspect切面,记录接口的进入和出去时的相关日志

API网关

根本概念:统一管理API的一个网络关口、通道,是整个微服务平台所有请求的唯一入口,所有的客户端和消费端都通过统一的网关接入微服务,在网关层处理惩罚所有的非业务功能。
API网关的作用:为微服务云平台提供统一的入口是API网关最主要的用途,除此之外,网关还可负担认证授权、访问控制、路由、负载平衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等非业务性的功能。
API网关核心功能:
1)负载平衡
微服务架构一般都有一个注册中心,后端服务启动时候会将自己的服务地点注册到注册中心,并和注册中心保持心跳,网关用过监听注册中心来举行服务的发现,并根据一定的负载平衡算法(随机、轮询、权重、hash等)将客户端的请求只管平衡地转发到后端的各个服务中。
2)服务熔断、重试及路由切换
和微服务的熔断原理一样,为了防止服务的雪崩效应,当检测到服务不可用时,需要举行快速失败。当某服务在短时间内多次发生调用失败,服务消费方的断路器会被断开。开路的断路器就像电路跳闸一样,阻止消费方向故障服务发送请求,直接返回失败大概执行消费方的降级逻辑。断路器通常在一定时间后关闭,在这期间可以为底层服务提供足够的空间来规复。
3)限流
限流的主要目标是防止类似DDos的恶意攻击导致服务器短时间内收到大量请求而造成的服务瘫痪。因此需要在接口层面做流量的控制,API网关统计一个时间窗口内针对某服务的请求数量,如果高出一定的阈值,则应拒绝继承转发请求到后端服务。时间窗口是滑动窗口,下一个时间窗口到来时,计数器清零。可以使用Redis的单线程模子和高性能的并发性来包管高并发下计数器计数准确。
4)认证鉴权
在微服务架构下,服务被拆分成多个实例,单体应用中的模式就很难试用,于是需要把鉴权的业务从各服务中抽离出来,单独创建一个权限认证服务,使用API网关入口作为切面拦截。网关拦截用户请求,获取请求中附带的用户身份信息,调用认证授权中心的服务,对请求者做身份认证,即确认当前访问者确实是其所声称的身份,查抄该用户是否有访问该背景服务的权限。
5)灰度发布
灰度发布是服务发布时比力好的一种升级方式,它可以根据客户端的实际情况(版本、IP端等)举行请求分流,将一小部分测试者的请求切到新版本服务上,万一有问题也能实时定位修复,且不影响线上老版本的使用。
springcloud体系下的技能选型:zuul、spring cloud gateway
参考博客:
https://developer.51cto.com/art/201906/597961.htm
https://www.jianshu.com/p/7d6853140e13
https://www.cnblogs.com/fanBlog/p/10936190.html
https://blog.csdn.net/u014590757/article/details/80233901
https://blog.csdn.net/qq_41699100/article/details/90606458
https://blog.csdn.net/weixin_33816946/article/details/86122380?utm_medium=distribute.pc_relevant.none-task-blog-searchFromBaidu-1.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-searchFromBaidu-1.control
https://blog.csdn.net/nsxqf/article/details/90679742

来源:https://blog.csdn.net/qq_45429238/article/details/112061181
免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则


专注素材教程免费分享
全国免费热线电话

18768367769

周一至周日9:00-23:00

反馈建议

27428564@qq.com 在线QQ咨询

扫描二维码关注我们

Powered by Discuz! X3.4© 2001-2013 Comsenz Inc.( 蜀ICP备2021001884号-1 )