系统高可用需要考虑哪些方面

一、背景:

在大部分系统中,特别是面向C端的应用,都会遇到一个问题,就是如保证系统的高可用,总不能经常挂,那用户肯定不愿意用了,在这个过程,就需要考虑很多方面。

PS:这里假设系统架构及部署是合理的。

二、限流:

限流通常是第一步,假如系统能够承载的并发是1k,但是突然打过来的流量有3k,不做限流的话,系统肯定直接打挂了。

那么,就需要通过压测知道系统的并发负载能力。

1、压测:

在公司内部,通常由测试人员使用压测平台或工具(或者使用类似jmeter这样的压测工具)进行压测,测试会写一些测试脚本。

大促之前的压测通常由测试、研发、运维、DBA、中间件组等共同支持,对核心接口同时进行压测,观察CPU、线程等机器运行情况,以及数据库和中间件的情况。

在保证各方面参数正常的情况下,最终得到并发负载的阈值。

举个栗子:

我们主要关注TPS、TP99、错误率这些核心参数。

互联网业务的接口,TP99通常在200ms以内较好。

2、压测最主要解决的问题:

很明显,能通过扩容机器解决的问题几乎都不是问题,加机器谁不会呢。

压测最主要目的是找到扩容机器无法解决的问题,例如数据库连接不足。

3、压测之后:

压测之后,需要根据这些参数进行分析,错误率太高什么原因,并发太低又是因为什么?

我们发现这个接口的并发很低,怎么查看原因呢,可以通过skywalking查看整个调用链路,到底是哪个环节比较慢。

从整个追踪链路可以查看哪个环节最耗时,是否可以优化,怎么优化。

4、如何限流:

通常公司会有自己的服务治理平台,无论是自研还是三方开源(如:阿里Sentinel),也可以在网关层做限流。

上图是我司的限流配置,给sentinel套了个壳子,支持集群限流。

三、熔断:

通常就是后端的依赖出了问题,如依赖的服务、MySQL或者Redis很慢甚至挂了等类似的场景,这时候整个接口响应就很慢。

在一定时间内错误达到阈值,这时候开启熔断,对应时间窗口直接拒绝请求,之后再尝试处理请求。

1、为什么需要熔断:

RPC接口调用肯定会设置timeout时间,正常情况下,很少有超时的,用来保证接口响应,不可能一直阻塞等待。

如果没有熔断,可能会出现大量线程阻塞等待,最终把服务拖垮。

亦或者是被依赖的服务,这时候负载比较大,开启熔断,说不定就缓过来了。

2、使用场景:

出于安全和性能考虑,并发高的接口都可以设置熔断。

3、实现:

通过类似Hystrix的三方工具就可以实现熔断。(Resilience4j)

四、降级:

降级是在熔断的后面,如果熔断器开启,就谈不上主动降级。

降级主要分为两种大方向:

1、系统向外提供服务,肯定区分核心接口(功能)和非核心接口,当我们服务器负载过大,超过预设的阈值,可以通过在网关层设置开关将非核心接口暂停提供服务,从而尽量保证核心接口一定可用。

2、例如一个查询接口,本来要查询MySQL的,但是MySQL挂了,触发降级,从本地缓存中读取少量数据或历史数据,然后将结果返回。

1、实现降级:

1、在网关层开发规则开关,能够实时生效,快速处理紧急的问题。

2、如果是第二种场景,可以通过Hystrix实现。

五、资源隔离:

隔离就想轮船一样,会有很多货舱,相互隔离,即使某个货舱出了问题,也不会影响整个轮船。

解决的问题:当系统某个接口调用别的服务出现问题,请求一直阻塞在这里。如果并发高的话,会导致越来越多的线程资源被占用阻塞,最终可能就拖垮整个服务了。

通过设置资源隔离,例如这个接口设置最多占用20个线程。

1、对比:

资源隔离和熔断有一部分功能是重合的。例如依赖的服务负载很高,响应超级慢。

无论是哪一种解决方式都可以解决,亦或者两种都用上,只是哪个先生效的问题。

在调用MySQL或者Redis等中间件时候,这时候更倾向于用熔断器,例如查询MySQL一直报错,这时候开启熔断,直接返回了,减少资源浪费,等待MySQL恢复。

六、报警:

监控报警特别重要,即使前面的各种措施都做了(何况大部分系统也可能都做了),系统还是可能出问题,如果没有监控报警,可能需要用户报障或者系统炸了你才知道。

常见的监控报警大概分为几方面:应用告警、业务告警、微服务指标告警、慢SQL告警、中间件告警等。

1、应用告警:

应用报警包含了服务级别、日志告警、接口级别告警等。

告警参数及标准在对应平台设置好。

2、业务告警:

主要推送业务方面的告警信息,例如是核心接口,某些数据校验未通过这种。

3、微服务指标告警:

微服务级别的告警是很重要的,通常都是线程数、CPU使用率太高等类似问题,可能就需要研发人员排查解决问题的。

系统直接将机器情况、jvm(jstack、jstat)等情况打印到文件中,直接可以下载定位问题。

4、慢SQL告警:

慢SQL告警的话,也是需要研发做优化,修改SQL,加索引,定时统计,大数据部门支持等处理方案。

七、监控:

1、业务数据看板:

有句话说得好,没有数据支持都是白扯,一切以数据为导向。

数据才能提现你做一个需求真正的价值。

我司通常都会将核心功能及流程做可视化数据看板展示,不仅仅为了让研发能够看到数据效果,还能及时发现是否有突发状况导致核心流程异常,特别是刚上线的时候,如果有bug,从看板上可以很快知道。

通过Grafana或者其他组件实现的数据统计及展示。

2、应用监控:

包含了提供的接口、依赖的接口、Redis、MQ等监控。

3、系统指标:

4、JVM指标:

5、集成业务大盘:

前面的监控指标都比较分散,需要一个个点击加载查看,相对麻烦,可以直接将需要的指标做成一个大盘,包含机器运行、jvm、核心接口等监控。

6、总结:

监控来说,主要是上面这些维度,当然也会有其他定制化的需求,总体就是这样的。

通过前面的监控 + 报警灯措施,尽可能保证系统的高可用,能够及时发现问题并且解决。

posted @ 2022-02-08 20:55  Diamond-Shine  阅读(379)  评论(0编辑  收藏  举报