可靠的系统是业务稳定、快速发展的基石。那么，如何做到系统高可靠、高可用呢？下面从技术方面介绍几种提高系统可靠性、可用性的方法。

扩展

扩展是最常见的提升系统可靠性的方法，系统的扩展可以避免单点故障，即一个节点出现了问题造成整个系统无法正常工作。换一个角度讲，一个容易扩展的系统，能够通过扩展来成倍的提升系统能力，轻松应对系统访问量的提升。

一般地，扩展可以分为垂直扩展和水平扩展：

垂直扩展：

是在同一逻辑单元里添加资源从而满足系统处理能力上升的需求。比如，当机器内存不够时，我们可以帮机器增加内存，或者数据存不下时，我们为机器挂载新的磁盘。垂直扩展能够提升系统处理能力，但不能解决单点故障问题。

• 优点：扩展简单。
• 缺点：扩展能力有限。

水平扩展：

通过增加一个或多个逻辑单元，并使得它们像整体一样的工作。水平扩展，通过冗余部署解决了单点故障，同时又提升了系统处理能力。

• 优点：扩展能力强。
• 缺点：增加系统复杂度，维护成本高，系统需要是无状态的、可分布式的。

可扩展性系数 scalability factor 通常用来衡量一个系统的扩展能力，当增加 1 单元的资源时，系统处理能力只增加了 0.95 单元，那么可扩展性系数就是 95%。当系统在持续的扩展中，可扩展系数始终保持不变，我们就称这种扩展是线性可扩展。

在实际应用中，水平扩展最常见：

1. 通常我们在部署应用服务器的时候，都会部署多台，然后使用 nginx 来做负载均衡，nginx 使用心跳机制来检测服务器的正常与否，无响应的服务就从集群中剔除。这样的集群中每台服务器的角色是相同的，同时提供一样的服务。
2. 在数据库的部署中，为了防止单点故障，一般会使用一主多从，通常写操作只发生在主库。不同数据库之间角色不同。当主机宕机时，一台从库可以自动切换为主机提供服务。

隔离

隔离，是对什么进行隔离呢？是对系统、业务所占有的资源进行隔离，限制某个业务对资源的占用数量，避免一个业务占用整个系统资源，对其他业务造成影响。

隔离级别按粒度从小到大，可以分为线程池隔离、进程隔离、模块隔离、应用隔离、机房隔离。在数据库的使用中，还经常用到读写分离。

1. 线程池隔离：不同的业务使用不同的线程池，避免低优先级的任务阻塞高优先级的任务。或者高优先级的任务过多，导致低优先级任务永远不会执行。
2. 进程隔离：Linux 中有用于进程资源隔离的 Linux CGroup，通过物理限制的方式为进程间资源控制提供了简单的实现方式，为 Linux Container 技术、虚拟化技术的发展奠定了技术基础。在工作中的实际应用，可以看看这篇文章：日志压缩资源消耗优化: Linux CGroup 的使用。
3. 模块隔离、应用隔离：很多线上故障的发生源于代码修改后，测试不到位导致。按照代码或业务的易变程度来划分模块或应用，把变化较少的划分到一个模块或应用中，变化较多的划分到另一个模块或应用中。减少代码修改影响的范围，也就减少了测试的工作量，减少了故障出现的概率。
4. 机房隔离：主要是为了避免单个机房网络问题或断电吧。
5. 读写分离：一方面，将对实时性要求不高的读操作，放到 DB 从库上执行，有利于减轻 DB 主库的压力。另一方面，将一些耗时离线业务 sql 放到 DB 从库上执行，能够减少慢 sql 对 DB 主库的影响，保证线上业务的稳定可靠。

解耦

在软件工程中，对象之间的耦合度就是对象之间的依赖性。对象之间的耦合越高，维护成本越高，因此对象的设计应使模块之间的耦合度尽量小。在软件架构设计中，模块之间的解耦或者说松耦合有两种，假设有两个模块A、B，A依赖B：

第一种是，模块A和模块B只通过接口交互，只要接口设计不变，那么模块B内部细节的变化不影响模块A对模块B服务能力的消费。

• 面向接口设计下真正实现了将接口契约的定义和接口的实现彻底分离，实现变化不影响到接口契约，自然不影响到基于接口的交互。
• 模块A和B之间的松耦合，主要通过合理的模块划分、接口设计来完成。如果出现循环依赖，可以将模块A、B共同依赖的部分移除到另一个模块C中，将A、B之间的相互依赖，转换为A、B同时对C的依赖。

第二种是，将同步调用转换成异步消息交互。

• 比如在买机票系统中，机票支付完成后需要通知出票系统出票、代金券系统发券。如果使用同步调用，那么出票系统、代金券系统宕机是会影响到机票支付系统，如果另一个系统比如专车系统也想要在机票支付完成后向用户推荐专车服务，那么同步调用模式下机票支付系统就需要为此而改动，容易影响核心支付业务的可靠性。
• 如果我们将同步调用替换成异步消息，机票支付系统发送机票支付成功的消息到消息中间件，出票系统、代金券系统从消息中间件订阅消息。这样一来，出票系统、代金券系统的宕机也就不会对机票支付系统造成任何影响了。专车系统想要知道机票支付完成这一事件，也只需要从消息中间件订阅消息即可，机票支付系统完全不需要做任何改动。
• 异步消息解耦，适合那些信息流单向流动(类似发布-订阅这样的)，实时性要求不高的系统。常见的开源消息队列框架有：Kafka、RabbitMQ、RocketMQ。

限流

为什么要做限流呢？举一个生活中的例子，大家早上上班都要挤地铁吧，地铁站在早高峰的时候经常要限制客流，为什么呢？有人会觉得这是人为添堵。真是这样吗？如果不执行客流控制，大家想想会是什么场景呢？站台到处都挤满了乘客，就算你使出洪荒之力也不一定能顺利上车，且非常容易引发肢体碰撞，造成冲突。有了客流控制之后，地铁站才能变得秩序井然，大家才能安全上地铁。

一个系统的处理能力是有上限的，当服务请求量超过处理能力，通常会引起排队，造成响应时间迅速提升。如果对服务占用的资源量没有约束，还可能因为系统资源占用过多而宕机。因此，为了保证系统在遭遇突发流量时，能够正常运行，需要为你的服务加上限流。

熔断

谈到熔断，不得不提经典的电力系统中的保险丝，当负载过大，或者电路发生故障时，电流会不断升高，为防止升高的电流有可能损坏电路中的某些重要器件或贵重器件，烧毁电路甚至造成火灾。保险丝会在电流异常升高到一定的高度和热度的时候，自身熔断切断电流，从而起到保护电路安全运行的作用。

同样，在分布式系统中，如果调用的远程服务或者资源由于某种原因无法使用时，没有这种过载保护，就会导致请求阻塞在服务器上等待从而耗尽服务器资源。很多时候刚开始可能只是系统出现了局部的、小规模的故障，然而由于种种原因，故障影响的范围越来越大，最终导致了全局性的后果。而这种过载保护就是大家俗称的熔断器(Circuit Breaker)。

下面这张图，就是熔断器的基本原理，包含三个状态：

1. 服务正常运行时的 Closed 状态，当服务调用失败量或失败率达到阈值时，熔断器进入 Open 状态
2. 在 Open 状态，服务调用不会真正去请求外部资源，会快速失败。
3. 当进入 Open 状态一段时间后，进入 Half-Open状态，需要去尝试调用几次服务，检查故障的服务是否恢复。如果成功则熔断器关闭，如果失败，则再次进入 Open 状态。

熔断器基本原理

目前比较流行的降级熔断框架，是由 Netflix 开源的 Hystrix 框架。

作者：albon

链接：https://www.jianshu.com/p/7a8cae9d3ea5

来源：简书