高可用业务系统你必须知道的点 _必须

归志宁无五亩园，读书本意在元元。这篇文章主要讲述高可用业务系统你必须知道的点相关的知识，希望能为你提供帮助。

大家好，我是小六六，好久没给大家分享一些东西了，今天给大家带来关于我们互联网行业业务中最看重的一点性能指标，??高可用??的关键的一些点，刚好目前小六六做的是支付，那支付是所有业务的基石，支付对可用性的标准则是会更加重要，所以，我根据自身系统给大家总结了下面的点，分享给大家。

可用性的度量与考核网站不可用时间（故障时间） = 故障修复时间点 - 故障发现（报告）时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间） * 100%

其实通过这张图你可以发现，一个九和两个九的可用性是很容易达到的，只要没有蓝翔技校的铲车搞破坏，基本上可以通过人肉运维的方式实现。
三个九之后，系统的年故障时间从 3 天锐减到 8 小时。到了四个九之后，年故障时间缩减到 1 小时之内。在这个级别的可用性下，你可能需要建立完善的运维值班体系、故障处理流程和业务变更流程。你可能还需要在系统设计上有更多的考虑。比如，在开发中你要考虑，如果发生故障，是否不用人工介入就能自动恢复。当然了，在工具建设方面，你也需要多加完善，以便快速排查故障原因，让系统快速恢复。
到达五个九之后，故障就不能靠人力恢复了。想象一下，从故障发生到你接收报警，再到你打开电脑登录服务器处理问题，时间可能早就过了十分钟了。所以这个级别的可用性考察的是系统的容灾和自动恢复的能力，让机器来处理故障，才会让可用性指标提升一个档次。
一般来说，我们的核心业务系统的可用性，需要达到四个九，非核心系统的可用性最多容忍到三个九。在实际工作中，你可能听到过类似的说法，只是不同级别，不同业务场景的系统对于可用性要求是不一样的。
系统模块化，微服务化在之前我们一个系统的后端提供的服务都放在一个服务里面，比如商品，订单，支付等等，但是这里会有一个问题，就是如果我们其中一个服务挂了，会导致所有的服务不可用，
所以随着系统的发展，技术的发展，我们目前的微服务架构，分布式系统开发越来越成熟，他们也是系统高可用的一个基础，按照领域的拆分，分为一个个服务，每个服务负责自己专门的功能，各个系统建立自己系统和其他系统的边界。

依赖组件的高可用设计（mysql,redis等）我们知道目前的业务系统中，肯定不单单的只有我们的业务服务，一个大型的软件系统，里面肯定会包含很多的中间件，这些中间件的高可用也是非常重要的，当然很多服务有些是强依赖，有些也许不是，但是我我们肯定也考虑这些中间件的高可用的，就拿mysql和redis来举例吧，

mysql，首先我们的mysql的部署肯定要是同城主备的部署方案，并且要异地灾备，并且这些监控服务的网络等情况，必要的时候我们业务尽量连接的是一个cdb,也就是代理服务，由代理服务去连真正的db
redis，又比如我们的缓存服务，我们的缓存的中间件也是要做高可用的，比如我们的sentinel高可用方案

小六六，并没有说一个大型系统的每个组件的高可用，但是我们基本上都是要考虑他们的高可用的。
负载均衡说的负载均衡这个词，很多小伙伴一听，负载均衡呀，这个东西我清楚，但是仔细一想，却好像一知半解的样子，今天小六六给大家好好来看看系统高可用的利器负载均衡

LVS：使用Linux内核集群实现一个高性能、高可用的负载均衡服务器，它具有很好的可伸缩性（Scalability)、可靠性（Reliability)和可管理性（Manageability)。他可以对同城多机房做负载均衡

nginx

一般LVS过来就是Nginx了,也可以做负载

我们的应用网关

这个一般我们说的是api网关吧，也是要多个副本的

我们的应用服务

这个就是我们服务的最小的微服务了，基本上所有的服务是由这边去提供的，所以它的负载均衡还是很有毕要的。
LVS+Nginx+Keepalived的架构
限流限制到达系统的并发请求数量，保证系统能够正常响应部分用户请求，而对于超过限制的流量，则通过拒绝服务的方式保证整体系统的可用性。
限流可以认为服务降级的一种，限流就是限制系统的输入和输出流量已达到保护系统的目的。一般来说系统的吞吐量是可以被测算的，为了保证系统的稳定运行，一旦达到的需要限制的阈值，就需要限制流量并采取一些措施以完成限制流量的目的。
1、单机版限流
主要借助于本机内存来实现计数器，比如通过AtomicLong#incrementAndGet()，但是要注意之前不用的key定期做清理，释放内存。
纯内存实现，无需和其他节点统计汇总，性能最高。但是优点也是缺点，无法做到全局统一化的限流。
2、分布式限流
单机版限流仅能保护自身节点，但无法保护应用依赖的各种服务，并且在进行节点扩容、缩容时也无法准确控制整个服务的请求限制。而分布式限流，以集群为维度，可以方便的控制这个集群的请求限制，从而保护下游依赖的各种服务资源。

??限流支持多个维度??

整个系统一定时间内（比如每分钟）处理多少请求
单个接口一定时间内处理多少流量
单个IP、城市、渠道、设备id、用户id等在一定时间内发送的请求数
如果是开放平台，则为每个appkey设置独立的访问速率规则

常见的限流算法有：计数器、漏桶和令牌桶算法。
熔断 fail-fast熔断，其实是对调用链路中某个资源出现不稳定状态时（如：调用超时或异常比例升高），对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。
在系统开发和设计之时，尽量考虑系统的调用链超时等情况，以防止服务需崩的情况，Fail-fast要求尽快返回错误结果，终止正在进行的操作，让潜在错误尽可能早的被发现，以此让更上层的系统去处理错误。

隔离隔离，其实也是为了我们的服务的高可用做打算的，隔离属于物理层面的分割，将若干的系统低耦合设计，独立部署，从物理上隔开。
每个子系统有自己独立的代码库，独立开发，独立发布。一旦出现故障，也不会相互干扰。当然如果不同子系统间有相互依赖，这种情况比较特殊，需要有默认值或者异常特殊处理，这属于业务层面解决方案。
还有就是就算说就是同一个服务也是可以做隔离的，比如说线程的隔离。

超时与重试其实在系统开发中有一个定律叫做网络永远不可靠的，所以我们的网络请求说非常有可能超时的，为了提升用户体验，调用方可以通过 ??重试?? 方式再次发送请求，尝试获取结果。
接口重试是一把双刃剑，虽然客户端收到了??响应超时??结果，但是我们无法确定，服务端是否已经执行完成。如果盲目地重试，可能会带来严重后果。比如：银行转账。
【高可用业务系统你必须知道的点】??重试???通常跟??幂等???组合使用，如果一个接口支持了 ??幂等??，那你就可以随便重试就好比小六六负责支付系统，对于超时和重试的场景还是要非常慎重，像一般我们的请求其他系统的时候一般会在heart头中带一个幂等key
回滚其实一般线上的问题都是新上功能的时候，第一次上线的时候会出问题，所以我们要在线上上线的时候必须要考虑回滚的计划。

压测与预案系统压测

压测方案：压测接口/并发量/压测策略/压测指标
压测报告：机器负载/QPS/响应时间/成功率
线上/线下压测
读写/仿真/引流/隔离集群/缩容压测
单机/集群/离散/全链路压测

应急预案每一层故障都要做预案

网络接入层（DNS/LVS/HaProxy）
应用接入层（Nginx/OpenResty）
WEB应用层（Tomcat）
服务层（Dubbo）
数据层（Redis/DB）

监控和告警完善的基础/业务Metrics监控 + 配置告警阈值，包括（基础硬件监，JVM监控，应用业务监控，日志监控告警）基本上每个公司都应该有鹰眼系统，所以这块也是高可用的一个基石了，能第一时间发现问题，并且通知到研发人员，具体怎么做的话，大家可以看看业界上怎么做的，基本上互联网公司这块都会有的
健全的值班体系和线上发布checkList