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

系统⾼可⽤需要考虑哪些⽅⾯
⽬录
⼀、背景：
在⼤部分系统中，特别是⾯向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、总结：
监控来说，主要是上⾯这些维度，当然也会有其他定制化的需求，总体就是这样的。

通过前⾯的监控 + 报警灯措施，尽可能保证系统的⾼可⽤，能够及时发现问题并且解决。