浅谈微服务架构(四)——容错模式2

3. 限流模式

服务的容量和性能是有限的,在第3章中会介绍如何在架构设计过程中评估服务的最大性能和容量,然而,即使我们在设计阶段考虑到了性能压力的问题,并从设计和部署上解决了这些问题,但是业务量是随着时间的推移而增长的,突然上量对于一个飞速发展的平台来说是很常见的事情。

针对服务突然上量,我们必须有限流机制,限流机制一般会控制访问的并发量,例如每秒允许处理的并发用户数及查询量、请求量等。

有如下几种主流的方法实现限流。

1)计数器

通过原子变量计算单位时间内的访问次数,如果超出某个阈值,则拒绝后续的请求,等到下一个单位时间再重新计数。

在计数器的实现方法中通常定义了一个循环数组(见下图),例如:定义5个元素的环形数组,计数周期为1s,可以记录4s内的访问量,其中有1个元素为当前时间点的标志,通常来说每秒程序都会将前面3s的访问量打印到日志,供统计分析。

我们将时间的秒数除以数组元素的个数5,然后取模,映射到环形数组里的数据元素,假如当前时间是1 000 000 002s,那么对应当前时间的环形数组里的第3个元素,下标为2。

此时的数组元素的数据如下图所示。

在上图中,当前时间为1 000 000 002s,对应的计数器在第3个元素,下标为2,当前请求是在这个时间周期内的第1个访问请求,程序首先需要对后一个元素即第4个元素,也就是下标为3的元素清零;在1 000 000 002s内,任何一个请求如果发现下标为3的元素不为0,则都会将原子变量3清零,并记录清零的时间。

这时程序可以对第3个元素即下标为2的元素,进行累加并判断是否达到阈值,如果达到阈值,则拒绝请求,否则请求通过;同时,打印本次及之前3秒的数据访问量,打印结果如下。

当前:1次,前1s:302次,前2s:201次,前3s:518次

然而,如果当前秒一直没有请求量,下一秒的计数器始终不能清零,则下一秒的请求到达后要首先清零再使用,并更新清零时间。

在下一秒的请求到达后,若检查到当前秒对应的原子变量计数器不为0,而且最后的清零时间不是上一秒,则先对当前秒的计数器清零,再进行累加操作,这避免发生上一秒无请求的场景,或者上一秒的请求由于线程调度延迟而没有清零下一秒的场景,后面这种场景发生的概率较小。

另外一种实现计数器的简单方法是单独启动一个线程,每隔一定的时间间隔执行对下一秒的原子变量计数器清零操作,这个时间间隔必须小于计数时间间隔。

2)令牌筒

令牌筒是一个流行的实现限流的技术方案,它通过一个线程在单位时间内生产固定数量的令牌,然后把令牌放入队列,每次请求调用需要从桶中拿取一个令牌,拿到令牌后才有资格执行请求调用,否则只能等待拿到令牌再执行,或者直接丢弃。

令牌筒的结构如下图所示。

3)信号量

限流类似于生活中的漏洞,无论倒入多少油,下面有漏管的流量是有限的,实际上我们在应用层使用的信号量也可以实现限流。

4. 失效转移模式

若微服务架构中发生了熔断和限流,则该如何处理被拒绝的请求呢?解决这个问题的模式叫作失效转移模式,通常分为下面几种。

  • 采用快速失败的策略,直接返回使用方错误,让使用方知道发生了问题并自行决定后续处理。
  • 是否有备份服务,如果有备份服务,则迅速切换到备份服务。
  • 失败的服务有可能是某台机器有问题,而不是所有机器有问题,例如OOM问题,在这种情况下适合使用failover策略,采用重试的方法来解决,但是这种方法要求服务提供者的服务实现了幂等性。

转载博客:https://blog.csdn.net/kwame211/article/details/78015601

原文地址:https://www.cnblogs.com/wei-jing/p/11053092.html

时间: 2024-10-07 17:51:41

浅谈微服务架构(四)——容错模式2的相关文章

浅谈微服务架构与服务治理的Eureka和Dubbo

前言 本来计划周五+周末三天自驾游,谁知人算不如天算,周六恰逢台风来袭,湖州附近的景点全部关停,不得已只能周五玩完之后,于周六踩着台风的边缘逃回上海.周末过得如此艰难,这次就聊点务虚的话题,一是浅谈微服务的架构设计,二是聊聊微服务中广泛用于服务治理的Eureka与RPC框架Dubbo异同点. 一.微服务的架构设计 之所以想聊一下这个话题,主要有感于最近接触的两个新的微服务项目--两个项目的架构设计出自两个人之手,却不约而同的使用了相同的设计理念,项目结构非常类似.又想到就职于上家公司时接触到的项

浅谈微服务架构与.Net Core

微服务(microservice)这个概念是2012年出现的,2014年3月Martin Fowler在他的个人网站(https://martinfowler.com/articles/microservices.html)中是这样说到的: The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing softwar

浅谈微服务的来龙去脉

作者:王清培(Plen wang) 沪江 公共业务平台 应用架构师 转载至沪江技术学院微信公众号 背景介绍 最近一段时间公共业务平台在进行大面积的重构,对原来的技术栈进行迁移,逐渐往Java.Go.Node.js等开源.自由为主的技术体系中过度. 虽然这主要是替换技术框架,但也是我们应用系统进行重新设计.业务流程重新梳理的一个好机会,我们将利用这次机会来重构之前发现的一些问题. Martin Fowler大师<重构>一书中有说过一句话,大概意思就是,"每次对原有系统进行修改调整的时候

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

谈微服务架构(转)

时间 2016-03-22 11:38:33  人月神话的BLOG 原文  http://blog.sina.com.cn/s/blog_493a84550102w5x6.html 主题 微服务 其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是

SOA和微服务架构的区别?

知乎用户 289 人赞同了该回答 谢多人邀请,其实前面几位的回答已经差不多了,在这里仅谈下自己的简单总结. 微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身

SOA和微服务架构的区别

微服务架构强调的第一个重点就是业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用.这些小应用之间通过服务完成交互和集成.每个小应用从前端web ui,到控制层,逻辑层,数据库访问,数据库都完全是独立的一套.在这里我们不用组件而用小应用这个词更加合适,每个小应用除了完成自身本身的业务功能外,重点就是还需要消费外部其它应用暴露的服务,同时自身也将自身的能力朝外部发布为服务. 如果一句话来谈SOA和微服务的区别,即微服务不再强调传统SOA架构里面比较

微服务架构的进程间通信(IPC)

先抛出几个问题: 微服务架构的交互模式有哪些? 微服务常用的进程间通信技术有哪些? 如何处理部分请求失败? API的定义需要注意的事项有哪些 微服务的通信机制与SOA的通信机制之间的关系与区别 微服务架构的交互模式 一对一还是一对多? 一对一:每个客户端请求有一个服务实例来响应 一对多:每个客户端请求有多个服务实例来响应 同步还是异步? 同步模式:客户端请求需要服务端即时响应,甚至可能由于等待而阻塞 异步模式:客户端请求不会阻塞进程,服务端的响应可以是非即时的 一对一的交互模式有以下几种方式:

面向服务与微服务架构

背景 最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章 Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式--微服务,和我最近几年工作的实践比较相关感觉深受启发.本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构(SOA) 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.当时 java 企业应用领域 J2EE 依然是主流,应用程序被部署在庞大统一的符合 J2