系统接口的请求量,会在某些时间内突然增加,有什么应对措施么?

低调的牛肉


我们现在的系统,最开始只面向内网系统,这种情况下,访问量都不是特别的大并且比较平稳,最近开始接了一些互联网区的系统,访问量一下子上来了,所以也不得不考虑这方面的问题。

首先要说明,我们公司虽然也号称上了云,但是基本上还是基础的IasS这个级别,并没有PasS,也没有容器管理平台什么的,所以网上说的那些自动的流量监控、自动扩容缩容什么的,我们并没有使用过;所以针对这种情况,基本上还是一些土办法。

流量估算

什么系统会调用?这些系统的使用用户是谁?每日调用量是多少?高峰期预计是多少?

每个公司的情况可能不太一样,我们公司也成了好多年了,这些数据参考之前的产品/活动/需求基本上可以评估个大概范围,比如一个业务场景下,每天大概会有10万的调用量,在开发、压力测试和生产资源申请的过程中,就按照(评估数量*N)的一个值进行估量。

如果是小公司的话,或者某个业务场景是第一次上,那么这个数量是比较难估计的,这时候只能猜一个数量,不过就算是猜的,也比没有强。

缓存

请求过来,基本的过程就是解析入参、查询DB、加工处理、返回参数,需要使用的资源包括:网络带宽、CPU、内存、磁盘IO等;如果请求量增加,总会有一个资源会遇到瓶颈,通常来看,最容易产生瓶颈的是磁盘IO,基本上是数据库的磁盘IO。

使用缓存,就是为了减少数据库的压力,避免在请求量突然增多的时候,数据库崩掉从而导致整个项目的瘫痪。

缓存也可以分成多级,包括客户端(浏览器)缓存、CDN、服务器级别的缓存(内存式缓存、分布式缓存);

限流

限制用户的请求流量,例如使用计数器、页面设置多次提交的间隔时间、滴漏、请求排队等。

我们系统本身没有做什么限流措施,完全是依赖于API Gateway来做这些功能的;

有些项目甚至是这样做的,一个接口ABC三个系统都要调用,AB系统比较关键并且调用量稳定,C系统要求没那么高但是调用量比较大,那么接口被部署成两套环境,一套给AB系统使用,一套给C系统使用(数据库也使用备库),前者保证其稳定性,后者嘛...也会保证其稳定性,但是如果万一挂掉的话,至少不会影响到AB系统的使用。

服务降级

我认为这种方法在真实的业务场景中,是比较难实现的,不是说技术上不好做,而是业务上比较难操作。

通常服务降级不是IT说降就降的,这得业务(用户)说了算才行;就算是降级,也只能降那些不太重要的功能(接口),降级后页面显示成什么样子,接口返回什么内容,这些都是要提前设计好的;如果是关键性的功能(接口),是没有降级可能的。

希望我的回答,能够帮助到你!我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。


会点代码的大叔


对于软件系统而言,若特定时间段内流量暴增,那软件系统及相关API的性能瓶颈立马就会表现出来,服务器资源被占满,随之导致服务及系统不可用。所以我们要在系统架构时充分考虑到洪峰带来的性能压力,以达到“三高架构”。

什么是“三高架构”

架构领域所说的“三高”是指:

  • 高并发:并行处理的请求越多则代表并发越高;

  • 高性能:服务性能好,响应处理速度快;

  • 高可用:服务不可用的时间短、或基本没有。

API接口如何应对暴增的流量?

如何使我们的API达到“三高”呢?可以通过一些技术方案来实现,我这里整理了一些以供大家参考:

1、合理的缓存设计

在API层提缓存,很多人就觉得API不应该加缓存,因为大多数接口数据对实时性都是有要求的,但这里说的缓存主要是指借助内存来缓解DB层的查询(因为内存读写速度比硬盘读写速度快得多)。

要知道,API的数据来源主要是从数据库中查询出来的,所以在流量洪峰时,所有的流量都会打到DB层,这样数据库的查询压力很大。我们建议在用Redis等NoSQL产品来同步一份热点数据,API直接从Redis中取数据,取不到数据再从DB层查询。

2、数据库主从同步、读写分离

单一的数据节点在高并发场景下是抗不住的,所以需要做主从同步+读写分离。读从库,写主库,能有效避免主服务器出现性能瓶颈、降低阻塞、并发能力提升。

3、服务限流

当系统资源无法应对大量请求时,为保证有限资源能正常使用,我们就需要就需要按照一定策略对服务做限流处理。

其实很好理解,举例说明一下:每逢假期热门景点就是人山人海,所以这些景区的门票都会做限制,防止人员过多导致隐患发生。

服务限流有很多种模式,在架构领域常见的有:

  • 熔断:当服务出现问题若短时间内无法修复,则开启熔断,拒绝访问,避免大流量请求对后端造成的过载压力;然后系统能实时监测服务的修复情况,一旦服务正常后,就自动关闭熔断,恢复服务。

  • 服务降级:一个大型系统会涉及很多服务,有些重要,有些不重要。当服务器负载严重时,可以对不重要的服务进行降级处理(即:停止服务),将资源回收提供给核心业务去使用。像电商平台每次做活动时,一些非核心业务都会临时关闭,这就是服务降级。

  • 队列处理:我们可以将所有的请求放置在一个“队列池”里,后端服务从这个“队列池”中依次取出请求进行处理,这种排队机制很大程度缓解了后端服务器的压力,只不过它也带来一些延迟。

4、动态扩容

以硬件的扩容来应对大流量冲击,像现在的容器化部署都可以做到弹性扩容,当资源不够时秒级扩容。

以上就是我的观点,对于这个问题大家是怎么看待的呢?欢迎在下方评论区交流 ~ 我是科技领域创作者,十年互联网从业经验,欢迎关注我了解更多科技知识!

网络圈


对于开发人员来说,在开发接口时是需要考虑高并发的情况的,在开发时要尽量优化代码提升接口性能,采用缓存机制以降低对数据库的操作;接口需要进行压力测试,并且将测试结果作为接口指标,在实际业务场景中,可以通过日常检测提前预估接口的访问情况,及时对服务器作出调整和扩容,以应对高并发的情况。

对于突然性的并发访问,可以采用流量限制的方式,通过对线程、数据库连接数等进行限制从而降低服务器的压力,如果是在分布系统中,也可以采用消息队列的模式,通过消息队列作为缓冲削弱访问压力;或者采用页面静态化的方式,将一些信息动态生成html页面,通过访问html页面降低对数据库的访问、提升效率;也可以搭建服务器集群,通过集群的图片分离、负载均衡等方式来分散访问压力,提升访问效率。


分享到:


相關文章: