继续创作，加快生长！这是我参与「日新方案 10 月更文应战」的第4天，点击查看活动概况
一、前言
高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在体系架构规划中有必要考虑的要素之一。今天咱们就来聊一聊三H中的高可用，也是咱们常说的体系稳定性。
本篇文章只聊思路，没有太多的深入细节。阅览全文大约需求5~10分钟。
二、高可用的界说
业界常用N个9来量化一个体系可用性程度，能够直接映射到网站正常运转时刻的百分比上。
可用性的计算公式：
大部分公司的要求是4个9，也便是年度宕机时长不能超过53分钟，实际要到达这个目标仍是十分困难的，需求各个子模块相互配合。
要想提高一个体系的可用性，首要需求知道影响体系稳定性的要素有哪些。
三、影响稳定性的要素
首要咱们先整理一下影响体系稳定性的一些常见的问题场景，大致可分为三类：
- 人为要素
不合理的改变、外部攻击等等
- 软件要素
代码bug、规划漏洞、GC问题、线程池反常、上下流反常
- 硬件要素
网络毛病、机器毛病等
下面便是对症下药，首要是毛病前的防备，其次是毛病后的快速康复才能，下面咱们就聊聊几种常见的处理思路。
四、提高稳定性的几种思路
4.1 体系拆分
拆分不是以削减不可用时刻为意图，而是以削减毛病影响面为意图。因为一个大的体系拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，然后降低毛病的影响面。体系拆分又包含接入层拆分、服务拆分、数据库拆分。
- 接入层&服务层
一般是按照事务模块、重要程度、改变频次等维度拆分。
- 数据层
一般先按照事务拆分后，假如有需求还能够做笔直拆分也便是数据分片、读写分离、数据冷热分离等。
4.2 解耦
体系进行拆分之后，会分成多个模块。模块之间的依靠有强弱之分。假如是强依靠的，那么假如依靠方出问题了，也会受到牵连出问题。这时能够整理整个流程的调用联系，做成弱依靠调用。弱依靠调用能够用MQ的办法来完成解耦。即使下流出现问题，也不会影响当时模块。
4.3 技术选型
能够在适用性、优缺点、产品口碑、社区活跃度、实战事例、扩展性等多个方面进行全量评价，挑选出合适当时事务场景的中间件&数据库。前期的调研必定要充分，先比照、测验、研究，再决议，磨刀不误砍柴工。
4.4 冗余布置&毛病主动搬运
服务层的冗余布置很好了解，一个服务布置多个节点，有了冗余之后还不够，每次出现毛病需求人工介入康复势必会增加体系的不可服务时刻。所以，又往往是经过“主动毛病搬运”来完成体系的高可用。即某个节点宕机后需求能主动去除上游流量，这些才能基本上都能够经过负载均衡的探活机制来完成。
涉及到数据层就比较复杂了，可是一般都有老练的方案能够做参阅。一般分为一主一从、一主多从、多主多从。不过大致的原理都是数据同步完成多从，数据分片完成多主，毛病搬运时都是经过推举算法选出新的主节点后在对外供给服务（这儿假如写入的时分不做强共同同步，毛病搬运时会丢失一部分数据）。详细能够参阅Redis Cluster、ZK、Kafka等集群架构。
4.5 容量评价
在体系上线前需求对整个服务用到的机器、DB、cache都要做容量评价，机器容量的容量能够选用以下办法评价：
- 明确预期流量目标-QPS；
- 明确可接受的时延和安全水位目标（比方CPU%≤40%，中心链路RT≤50ms）；
- 经过压测评价单机在安全水位以下能支撑的最高QPS（主张经过混合场景来验证，比方按照预估流量配比一起压测多个中心接口）；
- 最终就能够预算出详细的机器数量了。
DB和cache评价除了QPS之外还需求评价数据量，办法大致相同，等到体系上线后就能够根据监控目标做扩缩容了。
4.6 服务快速扩容才能&泄洪才能
现阶段不论是容器仍是ECS，单纯的节点复制扩容是很容易的，扩容的要点需求评价的是服务本身是不是无状态的，比方：
- 下流DB的连接数最多支撑当时服务扩容几台？
- 扩容后缓存是否需求预热？
- 放量战略
这些要素都是需求提早做好预备，整理出齐备的SOP文档，当然最好的办法是进行演练，实际上手操作，未雨绸缪。
泄洪才能一般是指冗余布置的情况下，挑选几个节点作为备用节点，平时承当很小一部分流量，当流量洪峰来暂时，经过调整流量路由战略把热节点的一部分流量搬运到备用节点上。
比照扩容方案这种本钱相对较高，可是长处便是响应快，风险小。
4.7 流量整形&熔断降级
流量整形也便是常说的限流，主要是避免超过预期外的流量把服务打垮，熔断则是为了本身组件或者依靠下流毛病时，能够快速失利避免长时间阻塞导致雪崩。关于限流熔断的才能，开源组件Sentinel基本上都具有了，用起来也很简单便利，可是有一些点需求注意。
- 限流阈值一般是装备为服务的某个资源能支撑的最高水位，这个需求经过压测了解来评价。跟着体系的迭代，这个值或许是需求继续调整的。假如装备的过高，会导致体系溃散时还没触发保护，装备的过低会导致误伤。
- 熔断降级-某个接口或者某个资源熔断后，要根据事务场景跟熔断资源的重要程度来评价应该抛出反常仍是回来一个兜底结果。比方下单场景假如扣减库存接口产生熔断，由于扣减库存在下单接口是必要条件，所以熔断后只能抛出反常让整个链路失利回滚，假如是获取产品谈论相关的接口产生熔断，那么能够挑选回来一个空，不影响整个链路。
4.8资源阻隔
假如一个服务的多个下流一起出现阻塞，单个下流接口一向达不到熔断标准（比方反常份额跟慢请求份额没到达阈值），那么将会导致整个服务的吞吐量下降和更多的线程数占用，极端情况下甚至导致线程池耗尽。引入资源阻隔后，能够限制单个下流接口可运用的最大线程资源，确保在未熔断前尽或许小的影响整个服务的吞吐量。
提到阻隔机制，这儿能够扩展说一下，由于每个接口的流量跟RT都不相同，很难去设置一个比较合理的可用最大线程数，并且跟着事务迭代，这个阈值也难以保护。这儿能够选用同享加独占来处理这个问题，每个接口有自己的独占线程资源，当独占资源占满后，运用同享资源，同享池在到达必定水位后，强制运用独占资源，排队等候。这种机制长处比较显着便是能够在资源使用最大化的一起确保阻隔性。
这儿的线程数只是资源的一种，资源也能够是连接数、内存等等。
4.9体系性保护
体系性保护是一种无差别限流，一句话概念便是在体系快要溃散之前对一切流量进口进行无差别限流，当体系康复到健康水位后中止限流。详细一点便是结合应用的 Load、整体平均 RT、进口 QPS 和线程数等几个维度的监控目标，让体系的进口流量和体系的负载到达一个平衡，让体系尽或许跑在最大吞吐量的一起确保体系整体的稳定性。
4.10 可观测性&告警
当体系出现毛病时，咱们首要需找到毛病的原因，然后才是处理问题，最终让体系康复。排障的速度很大程度上决议了整个毛病康复的时长，而可观测性的最大价值在于快速排障。其次基于Metrics、Traces、Logs三大支柱装备告警规矩，能够提早发现体系或许存在的风险&问题，避免毛病的产生。
4.11 改变流程三板斧
改变是可用性最大的敌人，99%的毛病都是来自于改变，或许是装备改变，代码改变，机器改变等等。那么怎么削减改变带来的毛病呢？
- 可灰度
用小份额的一部分流量来验证改变后的内容，减小影响用户群。
- 可回滚
出现问题后，能有有效的回滚机制。涉及到数据修改的，发布后会引起脏数据的写入，需求有牢靠的回滚流程，确保脏数据的铲除。
- 可观测
经过调查改变前后的目标改变，很大程度上能够提早发现问题。
除了以上三板斧外，还应该在其他开发流程上做标准，比方代码控制，集成编译、主动化测验、静态代码扫描等。
五、总结
对于一个动态演进的体系而言，咱们没有办法将毛病产生的概率降为0，能做的只有尽或许的防备和缩短毛病时的康复时刻。当然咱们也不用一味的寻求可用性，毕竟提高稳定性的一起，保护本钱、机器本钱等也会跟着上涨，所以需求结合体系的事务SLO要求，合适的才是最好的。
怎么做好稳定性和高可用保证是一个很巨大的命题，本篇文章没有太多的深入细节，只聊了整体的一些思路，主要是为了大家在以后的体系高可用建造过程中，有一套体系的结构能够参阅。最终感谢耐心看完的同学。
*文/新一
重视得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有协助的话，欢迎谈论转发点赞～
