[分布式服务]海量互联网服务设计之降级设计

目录

  • 降级一致性

    • 缓存的使用
    • 流程异步化
    • 行为聚集化
  • 体验降级
    • 简化流程
    • 分级体验
  • 降级服务要点

上周在 [分布式服务]海量互联网服务设计的有损价值观 这篇文章中提到,与金融行业服务要求的强一致性不同,海量互联网服务要求的是能够扛住更高的qps,服务降级研究的问题是在服务器资源有限的情况下,如何提供更大的访问量,并保证系统稳定运行。

最近我搬了个房子,房东还没来得及上面装宽带,所以在家里我是用手机热点上网的。热点网速有限,看视频的时候,为了视频流程的播放,我将视频从蓝光调整到270P,虽然视频清晰度很低,但是可以流畅播放,也基本满足的需求。这就是降级。与此类似,我们的系统在应对一些突发情况的时候,也需要这样的降级。

为此必须放弃掉某些东西,比如:

  • 数据的一致性,无需绝对的一致性,而保障最终一致即可;
  • 系统功能的降级,例如把一些不重要的功能,或是非关键路径的功能暂时关闭;
  • 用户体验降级,分多种方案给用户不同的体验

降级一致性

缓存的使用

在数据库之上,添加一层缓存是降低一致性的一种做法。

缓存的访问速度、包括可承载的访问qps都要远远高于数据库。用户请求到达时优先访问缓存,如果缓存命中,则直接返回缓存中的数据。如果缓存为空,则查询数据库,并且进行缓存的更新。使用缓存要注意的问题是:

  • 缓存的更新机制,是失效过期被动更新,还是主动refresh,策略如何选择;
  • 缓存过期时间。缓存最长可以保存多长的时间?
  • 热点问题,例如“商品库存”这个值,在每次查询商品列表的时候都会进行查询,很容易就会成为热点key。热点key会造成redis集群的流量倾斜。解决热点key,可以将缓存key进行hash打散。或是在缓存之上再构建一层本地内存cache,例如使用Guava cache来做本地缓存。
  • 缓存击穿问题,当数据在数据库中不存在时,如何避免用户的请求每次都穿过缓存打到数据库上。
  • 添加缓存开关,当缓存的数据有问题时,有没有手段快速让缓存失效 或是 临时关闭缓存。
  • ...

除了在数据库之上添加缓存之外,对下游的接口也可以添加缓存。

例如某个接口提供了查询数据的功能,这些数据并不会经常改变;或是业务上对数据变动的敏感度并不高,那么这时候可以牺牲一点数据变动同步的要求,在对下游接口调用上增加一层缓存。

上述的关于缓存的问题,一些缓存框架都提供了方便快捷的使用方式,例如JetCache框架。

流程异步化

通过将流程异步化,将结果延迟给用户,也能够让系统扛住更大的请求。

举个例子,在打款这样的环节中,如果所有的步骤都是同步的,那么整个流程会非常长,并且通常来说,打款接口对qps都有限制, 例如限制一个平台每秒只能有200的转账打款的qps。如果整个转账业务逻辑都是同步的,很有可能因为这些下游接口的限制(尤其是支付环节)导致流程中止,无法继续往下走。

因此,当类似的场景有高qps出现时,就可以将流程中的同步逻辑用异步来实现。例如告知用户正在打款中,到账信息请等待通知等。用户的请求可以使用消息队列先缓存起来,再根据系统的消费能力慢慢消化掉。

行为聚集化

同样是利用异步的思想,在某些特殊的场景下可以将用户的请求聚合起来进行更新。

这个思想在很多中间件中都有,例如kafka中为了减少网络带来的系统开销,可以通过batch.size这个参数来设置批量提交的数据大小,当积压的消息达到这个值的时候就会统一发送。

也可以将这种思维使用在业务上。例如像一款在线种菜的游戏,用户有多块土地可以种植作物,作物统一收成为积分。一般用户在收获的时候会点击多块土地同时进行收获,用户积分账户属于重要数据,可以每次收获时都进行累计。但是其他关注用户累计积分的非关键分支,则可以进行聚合后再统一累计。例如下游有一个任务服务,专门负责收集用户的收集积分行为,让用户达成某个成就完成任务,这个服务也关心用户积分的累计行为。这种情况下,可以不必用户的每次行为都去调用任务服务,而是上游做聚集后统一发送。

具体做法 可以使用类似kafka延时队列的组件,在用户第一次收集积分时,上游服务便发送一个延时2秒的消息出去。上游服务本身会消费这个延时消息,消费后将延时期间的累计值再传给下游的任务服务。虽然用户的成就累计会延迟2秒,但这种聚集行为的做法,会大大降低下游服务的压力。

体验降级

简化流程

功能降级在不得已的一些情况下也可以使用,例如某个流程有非常多的校验逻辑,举个例子,还是使用上面QQ农场的例子。QQ农场用户是可以互相偷菜的,偷菜的时候是否要去校验偷取与被偷取用户之间是否是好友关系。当好友关系校验服务成为一个瓶颈时,能否将好友关系校验去掉?而为了避免这样做带来的风险,可以同时启用一个限制,就是限制在降级的期间,每个用户仅能偷取其他用户1次,避免有黑产用户不断偷取其他用户的菜。

分级体验

当流量过大时,甚至可以只保留种、偷、收的基本功能,其他的模块暂时屏蔽掉入口,例如成就系统、任务系统等暂时下线。又如电商系统,在拉取商品列表的时候,将商品推荐模块移除掉,商品推荐属于锦上添花的东西,去掉了也不影响用户的正常使用。又如在拉取评论列表时,可以只拉取用户的首次评论,追评信息不再拉取,等等。

在类似相册这种场景下,可以将体验细分为正常访问图片、不预拉取图片、用中图代替大图、用默认图代替大图、只允许访问小图或封面、不允许访问相册等多个层级,根据不同的资源状况和场景为不同的用户提供差异化服务。依据不同的服务压力切换到不同的用户体验级别上。

降级服务要点

首先要明确的是降级达到的目的是什么,有些降级是降低对下游的压力,有些降级是降低读压力,有些则是降低写压力。例如上文提到的加缓存是降低读压力,行为聚集、异步是降低写压力。不同的降级方案所针对的场景应该要明确。

第二是进行业务上的梳理,哪些是必须有的基本功能,例如农场的种菜;哪些是锦上添花的功能,例如商品详情页的“好物推荐”;哪些是可以牺牲的体验,例如相册的多个体验分级,这些简化达到的目的都需要梳理出来。

降级的时间段,有些系统存在流量尖刺的情况,例如商品兑换系统,0点可能是更新库存的时候,用户来兑换商品的请求会形成一个流量高峰。又例如QQ相册,可能在晚上20:00 - 21:00是用户浏览的一个高峰时间段。在不同的时间段,可以选择不同的降级方案。

降级也要注意和前端的配合,例如商品抢购列表 高峰时间段降级,不展示具体的剩余数量,只展示“商品抢购中”的文案,需要前端配合一起做降级。

降级可以做到自动化、半自动化、或完全的手动。应该预留手动调整的能力,避免系统会误判,紧急情况下可以人工介入操作。因为降级的功能不总是会真正进行,所以方案都要事先预演好。

原文地址:https://www.cnblogs.com/QG-whz/p/12588746.html

时间: 2024-11-05 23:35:01

[分布式服务]海量互联网服务设计之降级设计的相关文章

RSF 分布式服务框架设计

是时候设计一个分布式服务框架了.我先将它定名为 Hasor-RSF,"RSF"为 Remote Service Framework 的缩写. RSF的目的是为了提供一种高效的远程服务访问方式,例如"A机器访问在B机器上的一个服务".当然首先它是运行在Java上的,但是我并不希望 Java 成为 RSF的唯一平台. 它应该是分布式的,就是说服务 A 可能会分布在若干台机器内. 当我的应用打算调用这个服务时我应该可以在这若干服务提供的机器上随机调用.这样做的好处是有助于

分布式发布订阅消息系统 Kafka 架构设计[转]

分布式发布订阅消息系统 Kafka 架构设计 转自:http://www.oschina.net/translate/kafka-design 我们为什么要搭建该系统 Kafka是一个消息系统,原本开发自LinkedIn,用作LinkedIn的活动流(activity stream)和运营数据处理管道(pipeline)的基础.现在它已为多家不同类型的公司 作为多种类型的数据管道(data pipeline)和消息系统使用. 活动流数据是所有站点在对其网站使用情况做报表时要用到的数据中最常规的部

微服务开发中的数据架构设计

本文来自作者 陈伟荣 在 GitChat 分享的文章[微服务开发中的数据架构设计] 前言 微服务是当前非常流行的技术框架,通过服务的小型化.原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合.业务的灵活调整组合以及系统的高可用性.为业务创新和业务持续提供了一个良好的基础平台.本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容. 微服务技术框架中的多层数据架构设计 数据架构设计中的要点 要点1:数据易用性 要点2:主.副数据及数据解耦 要点3:分库分表

ylbtech-KeFuYunWei(服务运维考核系统)-数据库设计

ylbtech-DatabaseDesgin:ylbtech-KeFuYunWei(服务运维考核系统)-数据库设计 DatabaseName:KEFUYUNWEI Model:Admin 用户后台管理数据设计 Type:管理软件 Url: 1.A,数据库关系图(Database Diagram) 返回顶部 1.B,数据库设计脚本(Database Design Script)返回顶部 use master go -- =======================================

微服务架构设计基础之领域驱动设计

DDD早于微服务「出道」十年,这两个「忘年交」的软件设计哲学是如何相爱相杀的? 背景 微服务现在可以说是软件研发领域无人不提的话题,然而业界流行的对比多数都是所谓的Monolithic(单体应用),而大量的系统在十几年前都已经是以SOA(面向服务架构)为基础的分布式系统了,那么微服务作为新的架构标准与SOA有什么差异点呢?其本质区别在于设计原理,微服务是去中心化设计,SOA是「集成」形成中心设计: 另外,笔者认为以下几点并不是微服务和SOA的区别点: CI/CD:持续集成.持续部署本身与敏捷.D

分布式服务框架下,如何做到服务化最佳实践?

“升级服务框架后,性能.可靠性等问题日益明显.服务化之后面临的诸多挑战,怎样分析才能给出实践最优解? 在服务化之前,业务通常都是本地API调用,本地方法调用性能损耗较小.服务化之后,服务提供者和消费者之间采用远程网络通信,增加了额外的性能损耗,业务调用的时延将增大,同时由于网络闪断等原因,分布式调用失败的风险也增大.如果服务框架没有足够的容错能力,业务失败率将会大幅提升. 除了性能.可靠性等问题,跨节点的事务一致性问题.分布式调用带来的故障定界困难.海量微服务运维成本增加等也是分布式服务框架必须

阿里巴巴分布式服务框架Dubbo介绍(1)主要特色

引言 互联网服务和BS架构的传统企业软件相比,系统规模上产生了量级的差距.例如 传统BS企业内部门户只需要考虑数百人以及几千人的访问压力,而大型互联网服务有时需要考虑的是千万甚至上亿的用户: 传统企业管理系统管理的物料信息等,可能只有数万或数十万条记录,而一个大型B2C网站的商品SKU动辄千万,考虑到商品信息更新的历史记录,商品订单记录等数据,更是天文数字. 原始的SSH+DB的BS开发模式,显然已经无法满足现代互联网服务的需要.随着企业软件不断地向云端迁移的趋势越来越明显,最终中小型企业软件系

基于mogileFS搭建分布式文件系统--海量小文件的存储利器

一.分布式文件系统    1.简介 分布式文件系统(Distributed File System)是指文件系统管理的物理存储资源不一定直接连接在本地节点上,而是通过计算机网络与节点相连.分布式文件系统的设计基于客户机/服务器模式.一个典型的网络可能包括多个供多用户访问的服务器.另外,对等特性允许一些系统扮演客户机和服务器的双重角色.例如,用户可以"发表"一个允许其他客户机访问的目录,一旦被访问,这个目录对客户机来说就像使用本地驱动器一样. 当下我们处在一个互联网飞速发展的信息社会,在

【转】阿里巴巴分布式服务框架 Dubbo 团队成员梁飞专访

原文链接:http://www.iteye.com/magazines/103 Dubbo是阿里巴巴内部的SOA服务化治理方案的核心框架,每天为2000+ 个服务提供3,000,000,000+ 次访问量支持,并被广泛应用于阿里巴巴集团的各成员站点.Dubbo自2011年开源后,已被许多非阿里系公司使用. 项目主页:http://alibaba.github.io/dubbo-doc-static/Home-zh.htm 为了使大家对该框架有一个深入的了解,本期我们采访了Dubbo团队主要开发人