“持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第3天，点击查看活动详情”
大家好，我是小六六，好久没给大家分享一些东西了，今天给大家带来关于我们互联网行业业务中最看重的一点性能指标，高可用的关键的一些点，刚好目前小六六做的是支付，那支付是所有业务的基石，支付对可用性的标准则是会更加重要，所以，我根据自身系统给大家总结了下面的点，分享给大家。
可用性的度量与考核
网站不可用时间（故障时间） = 故障修复时间点 - 故障发现（报告）时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间 ） * 100%
其实通过这张图你可以发现，一个九和两个九的可用性是很容易达到的，只要没有蓝翔技校的铲车搞破坏，基本上可以通过人肉运维的方式实现。
三个九之后，系统的年故障时间从 3 天锐减到 8 小时。到了四个九之后，年故障时间缩减到 1 小时之内。在这个级别的可用性下，你可能需要建立完善的运维值班体系、故障处理流程和业务变更流程。你可能还需要在系统设计上有更多的考虑。比如，在开发中你要考虑，如果发生故障，是否不用人工介入就能自动恢复。当然了，在工具建设方面，你也需要多加完善，以便快速排查故障原因，让系统快速恢复。
到达五个九之后，故障就不能靠人力恢复了。想象一下，从故障发生到你接收报警，再到你打开电脑登录服务器处理问题，时间可能早就过了十分钟了。所以这个级别的可用性考察的是系统的容灾和自动恢复的能力，让机器来处理故障，才会让可用性指标提升一个档次。
一般来说，我们的核心业务系统的可用性，需要达到四个九，非核心系统的可用性最多容忍到三个九。在实际工作中，你可能听到过类似的说法，只是不同级别，不同业务场景的系统对于可用性要求是不一样的。
系统模块化，微服务化
在之前我们一个系统的后端提供的服务都放在一个服务里面，比如商品，订单，支付等等，但是这里会有一个问题，就是如果我们其中一个服务挂了，会导致所有的服务不可用，
所以随着系统的发展，技术的发展，我们目前的微服务架构，分布式系统开发越来越成熟，他们也是系统高可用的一个基础，按照领域的拆分，分为一个个服务，每个服务负责自己专门的功能，各个系统建立自己系统和其他系统的边界。
依赖组件的高可用设计（mysql,redis等）
我们知道目前的业务系统中，肯定不单单的只有我们的业务服务，一个大型的软件系统，里面肯定会包含很多的中间件，这些中间件的高可用也是非常重要的，当然很多服务有些是强依赖，有些也许不是，但是我我们肯定也考虑这些中间件的高可用的，就拿mysql和redis来举例吧，
- mysql，首先我们的mysql的部署肯定要是同城主备的部署方案，并且要异地灾备，并且这些监控服务的网络等情况，必要的时候我们业务尽量连接的是一个cdb,也就是代理服务，由代理服务去连真正的db
- redis，又比如我们的缓存服务，我们的缓存的中间件也是要做高可用的，比如我们的sentinel高可用方案
小六六，并没有说一个大型系统的每个组件的高可用，但是我们基本上都是要考虑他们的高可用的。
负载均衡
说的负载均衡这个词，很多小伙伴一听，负载均衡呀，这个东西我清楚，但是仔细一想，却好像一知半解的样子，今天小六六给大家好好来看看系统高可用的利器负载均衡
- LVS
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
- 完善的系统发布体系和上线的checkList 百分之90以上的系统问题，基本上是因为我们开发新的功能上线导致的，所以这个是非常有必要的。
- 还有就是监控告警的值班体系，如果我们系统发出了告警能第一时间处理掉这个问题，这样才能完成我们系统的高可用
结束
好了，今天就给大家分享这么多了，我是小六六，三天打鱼，两天晒网！