会在某些时间内突然增加?
我们现在的系统,最开始只面向内网系统,这种情况下,访问量都不是特别的大并且比较平稳,最近开始接了一些互联网区的系统,访问量一下子上来了,所以也不得不考虑这方面的问题。
首先要说明,我们公司虽然也号称上了云,但是基本上还是基础的IasS这个级别,并没有PasS,也没有容器管理平台什么的,所以网上说的那些自动的流量监控、自动扩容缩容什么的,我们并没有使用过;所以针对这种情况,基本上还是一些土办法。
流量估算什么系统会调用?这些系统的使用用户是谁?每日调用量是多少?高峰期预计是多少?
每个公司的情况可能不太一样,我们公司也成了好多年了,这些数据参考之前的产品/活动/需求基本上可以评估个大概范围,比如一个业务场景下,每天大概会有10万的调用量,在开发、压力测试和生产资源申请的过程中,就按照(评估数量*N)的一个值进行估量。
如果是小公司的话,或者某个业务场景是第一次上,那么这个数量是比较难估计的,这时候只能猜一个数量,不过就算是猜的,也比没有强。
缓存请求过来,基本的过程就是解析入参、查询DB、加工处理、返回参数,需要使用的资源包括:网络带宽、CPU、内存、磁盘IO等;如果请求量增加,总会有一个资源会遇到瓶颈,通常来看,最容易产生瓶颈的是磁盘IO,基本上是数据库的磁盘IO。
使用缓存,就是为了减少数据库的压力,避免在请求量突然增多的时候,数据库崩掉从而导致整个项目的瘫痪。
缓存也可以分成多级,包括客户端(浏览器)缓存、CDN、服务器级别的缓存(内存式缓存、分布式缓存);
限流限制用户的请求流量,例如使用计数器、页面设置多次提交的间隔时间、滴漏、请求排队等。
我们系统本身没有做什么限流措施,完全是依赖于API Gateway来做这些功能的;
有些项目甚至是这样做的,一个接口ABC三个系统都要调用,AB系统比较关键并且调用量稳定,C系统要求没那么高但是调用量比较大,那么接口被部署成两套环境,一套给AB系统使用,一套给C系统使用(数据库也使用备库),前者保证其稳定性,后者嘛...也会保证其稳定性,但是如果万一挂掉的话,至少不会影响到AB系统的使用。
服务降级我认为这种方法在真实的业务场景中,是比较难实现的,不是说技术上不好做,而是业务上比较难操作。
通常服务降级不是IT说降就降的,这得业务(用户)说了算才行;就算是降级,也只能降那些不太重要的功能(接口),降级后页面显示成什么样子,接口返回什么内容,这些都是要提前设计好的;如果是关键性的功能(接口),是没有降级可能的。
希望我的回答,能够帮助到你!我将持续分享Java开发、架构设计、程序员职业发展等方面的见解,希望能得到你的关注。Copyright © 广州京杭网络科技有限公司 2005-2025 版权所有 粤ICP备16019765号
广州京杭网络科技有限公司 版权所有