赞
踩
SpringCloud是一系列框架的有序集合;它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发;springCloud没有重复造轮子,而是把把比较成熟的框架组合起来给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包;
优点:
各组件之间耦合度低,不影响其他模块的开发
减轻团队开发成本
配置简单
跨平台,可以用多种语言开发
组件丰富,功能齐全
缺点:
微服务过多,治理成本高,不利于维护系统
部署、性能监控、系统集成测试较麻烦
springcloud基于spingboot的简化配置,约定大于配置优雅简洁;由于单体结构的应用随着系统复杂度的增高,会暴露出各种各样的问题,微服务架构逐渐取代了单体架构,且这种趋势将会越来越流行
springboot专注于快速方便的开发单个个体微服务;springCloud关注全局的微服务协调整理治理框架,它将SpringBoot开发的一个个单体微服务整合并管理起来;
springboot可以离开SpringCloud独立使用开发项目, 但是SpringCloud离不开SpringBoot ,属于依赖的关系
springboot专注于快速、方便的开发单个微服务个体,SpringCloud关注全局的服务治理框架
与分布式系统相关的复杂性包括网络问题,延迟开销,带宽问题,安全问题
冗余-分布式系统中的冗余问题
负载平衡--负载平衡改善跨多个计算资源的工作负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布
性能-问题 由于各种运营开销导致的性能问题
部署复杂性
rest:是一种架构风格,指的是一组架构约束条件和原则(CRUD)
rpc:是一种进程间通信方式。允许像调用本地服务一样调用远程服务
rpc适用于内网服务调用,rest适合对外提供服务
rpc适用于IO密集的服务,rest适用于低频服务
rpc的通信协议一般使用tcp,rest的通信协议使用http
SpringCloud是一个微服务框架,dubbo是一个RPC调用框架;
SpringCloud大而全,dubbo侧重于服务调用;
dubbo服务调用性能高于SpringCloud
SpringCloud和dubbo可以结合起来一起使用
分布式属于微服务;微服务不一定是分布式;
区别:
1.微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中;分布式系统是若干独立计算机的集合
2.微服务是设计层面的东西,一般考虑如何将系统从逻辑上进行拆分,也就是垂直拆分;分布式是部署层面的东西,即强调物理层面的组成,即系统的各子系统部署在不同计算机上
3.微服务解决的是系统复杂度问题: 一般来说是业务问题;分布式解决的是系统性能问题: 即解决系统部署上单点的问题
4.微服务的应用可以部署在是同一个服务器,不一定是分散在多个服务器上;分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上
5.微服务相比分布式服务来说,它的粒度更小,服务之间耦合度更低,由于每个微服务都由独立的小团队负责,因此它敏捷性更高,分布式服务最后都会向微服务架构演化
微服务是一种架构概念,旨在通过将功能分解到各个离散的服务中从而降低系统的耦合性,并提供更加灵活的服务支持
Eureka作为SpringCloud的服务注册功能服务器,他是服务注册中心,系统中的其他服务使用Eureka的客户端将其连接到Eureka Service中,并且保持心跳,这样工作人员可以通过EurekaService来监控各个微服务是否运行正常
使用集群注册多台Eureka,然后把SpringCloud服务互相注册,客户端从Eureka获取信息时,按照Eureka的顺序来访问
默认情况下,如果Eureka Service在一定时间内没有接收到某个微服务的心跳,Eureka Service会进自我保护模式,在该模式下Eureka Service会保护服务注册表中的信息,不在删除注册表中的数据,当网络故障恢复后,Eureka Servic 节点会自动退出自我保护模式。
Eureka Client 会每隔 30 秒发送一次心跳来续约。 通过续约来告知 Eureka Server 该 Eureka Client 运行正常,没有出现问题。 默认情况下,如果 Eureka Server 在 90 秒内没有收到 Eureka Client 的续约,Server 端会将实例从其注册表中删除
提供方并不必定是正常下线,多是内存溢出,网络故障等缘由致使服务没法正常工做.EurekaServer会将这些失效的服务剔除服务列表.所以它会开启一个定时任务.每隔60秒会对失效的服务进行一次剔除
由于集群间的同步复制是通过HTTP的方式进行,基于网络的不可靠性,集群中的Eureka Server间的注册表信息难免存在不同步的时间节点,不满足CAP中的C(数据一致性)
Ribbon客户端组件提供一系列完善的配置项,如连接超时,重试等。简单的说,就是在配置文件中列出后面所有的机器,Ribbon会自动的帮助你基于某种规则(如简单轮询,随即连接等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法;主要功能是提供客户端的软件负载均衡算法
实现方法RestTemplate上添加注解@LoadBalanced,后直接使用服务名连接;启动类上添加:@RibbonClient注解
负载均衡的意义是指将负载的任务进行平衡、分摊到多个操作单元上进行运行,主要是用来避免单一应用由于并发等原因,导致应用宕机从而让系统整体无法使用、多负载同时工作,则使用负载均衡能够解决高并发的问题并实现服务的高可用
Ribbon使用discoveryClient从注册中心读取目标服务信息,对同一接口请求进行计数,使用%取余算法获取目标服务集群索引,返回获取到的目标服务信息。@LoadBalanced注解的作用开启客户端负载均衡
获取服务列表:为了减少服务的延迟,客户端会通过eureka指定的zone对服务列表进行过滤
负载均衡:通过负载均衡策略从服务列表中获得其中一台,默认是轮询策略,再对服务端进行调用
通过IPing检测实例,如果检测到某服务实例不存在/一定时间未响应,则会从持有服务列表中及时移除
保留zone的统计数据,ribbon可以避免可能访问失效的zone
随机策略:随机选择
轮询策略:按照顺序选择
重试策略:在配置时间内,当前选择不成功,一直尝试
最低并发策略:逐个考察,选择并发最低的
可用过滤策略:过滤掉失败的和高并发的
响应时间加权重策略:根据响应的时间分配权重,时间越长,权重越低
区域权重策略
Ribbon属于客户端负载,及在调用服务器以前,客户端自己根据策略,选择调用服务
Nginx属于服务端负载,服务只管调用负载地址即,负载会自己选择服务端调用
hystrix是一个延迟和容错库,旨在隔离对远程系统、服务和第三方库的访问点,停止级联故障,并在发生故障后快速恢复。
实现原理:
正常情况下,断路器关闭,服务消费者正常请求微服务
一段时间内,失败率达到一定的阈值,断路器将断开,而是快速失败的方法
断路器打开一段时间后,自动进入半开状态,允许一个请求通过,如果成功关闭断路器,否则继续打开
断路器保证局部错误不会扩展到整个系统
接口上添加注解@HystrixCommand(fallbackMethod = "方法名") //报错后调用的方法
启动类上添加熔断支持:@EnableCircuitBreaker
新建类,实现FallbackFactory接口,重写create()方法 //回调方法
在@FeignClient(value="服务名",fallbackFactory=类名.class) //回调类
配置文件yml中开启降级(feign.hystrix.enabled:true)
服务熔断在服务端,服务降级在客户端
服务熔断某个服务超时或异常时引起熔断;服务降级从整体网站请求负载考虑,当某个服务熔断或关闭之后服务将不再被调用
资源隔离
限流
熔断
降级
运维监控
阻止任何一个依赖服务耗尽所有的资源
避免请求排队和积压
提供 fallback 降级机制来应对故障
使用资源隔离技术来限制任何一个依赖服务的故障的影响
通过近实时的统计/监控/报警功能,来提高故障发现的速度
通过近实时的属性和配置热修改功能,来提高故障处理和恢复的速度
保护依赖服务调用的所有故障情况,而不仅仅只是网络故障情况
雪崩效应:大型项目的微服务之间的调用是互通的,当某个服务发生宕机时,调用这个服务的其他服务也会发生宕机,这样就会将服务的不可用逐步扩大到各个其他服务中,从而使整个项目的服务宕机崩溃
产生原因:
单个服务的代码存在bug
请求访问量激增
服务器的硬件故障
防止方式:
服务降级:接口调用失败就调用本地的方法返回一个空
服务熔断:接口调用失败就会进入调用接口提前定义好的一个熔断的方法,返回错误信息
服务隔离:隔离服务之间相互影响
服务监控:在服务发生调用时,会将每秒请求数、成功请求数等运行指标记录下来
服务降级:防止客户端一直等待,不会处理业务逻辑代码,直接返回一个友好的提示给客户端
服务熔断:请求直接走fallback方法,在设定时间后尝试恢复
服务隔离:为隔离的服务开启一个独立的线程池,这样在高并发的情况下不会影响其他服务
微服务名称(ribbon)
接口和注解(feign)
Feign是一个http客户端,只需要创建一个接口并添加一个注解就可以帮助我们更便捷的调用HTTP客户端。
添加maven依赖
接口上添加注解@FeignClient(value="服务名称")
启动类上添加注解@EnableFeignClients(basePackages = {com.lgcgk.***}):配置接口的扫描路径
将feign接口的代理类扫描到Spring容器中
为接口的方法创建RequestTemplate
发出请求
底层内置了Ribbon框架,并且使用了Ribbon的请求连接超时时间和请求处理超时时间作为其超时时间,而Ribbon默认的请求连接超时时间和请求处理超时时间都是 1s;
修改超时时间:
通过修改 Ribbon 的超时时间,被动的修改Feign 的超时时间(ribbon.ConnectTimeout、ribbon.ReadTimeout)
直接修改Feign 的超时时间(feign.client.config.default.ConnectTimeout、feign.client.config.default..ReadTimeout)
restful传参 @PathVariable() 将参数id以restful风格拼接到路径中
?传参 @RequestParam【拼接?形式的url】
@RequestBody 将user对象以json字符串的形式传参
开启feign日志
配置feign超时
http连接池
gzip压缩
网关相当于一个网络服务架构的入口,所有网络请求必须通过网关转发到具体的服务
统一管理微服务请求,权限控制、负载均衡、路由转发、监控、安全控制黑名单和白名单等
网关是对所有服务的请求进行分析过滤,过滤器是对单个服务而言
网关是路由加过滤器
Zuul是对SpringCloud提供的成熟对的路由方案,他会根据请求的路径不同,网关会定位到指定的微服务,并代理请求到不同的微服务接口,他对外隐蔽了微服务的真正接口地址。 三个重要概念:动态路由表,路由定位,反向代理。
态路由表:Zuul支持Eureka路由,手动配置路由,都支持自动更新
路由定位:根据请求路径,Zuul有自己的一套定位服务规则以及路由表达式匹配
反向代理:客户端请求到路由网关,网关受理之后,在对目标发送请求,拿到响应之后在给客户端
通过path配置拦截请求,通过ServiceId到配置中心获取转发的服务列表,Zuul内部使用Ribbon实现本地负载均衡和转发
使用Nginx的upstream设置Zuul服务集群,通过location拦截请求并转发到upstream,默认使用轮询机制对Zuul集群发送请求。
Zuul限流是通过引入spring-cloud-zuul-ratelimit依赖实现的
限流类型:
用户,根据认证用户或匿名用户限流
客户端IP地址,根据客户端IP地址限流
请求路径,根据请求URL限流
根据服务限流
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。