我们可以通过哪些方式来提高系统的高可用性？

1。什么是高可用

可用性是一个可量化的指标。计算公式在维基百科中描述如下： 根据系统损坏情况、不可使用时间、以及从不可操作状态恢复到可操作状态的时间，与系统总运行时间进行比较。业界一般用几个9来表示可用性指标。应用可用性的一般衡量标准是三个9到五个9。一般来说，我们的系统必须至少有 4 个 9 (99.99%) 的可用性才能被认为是高可用的。

高可用性的定义：（来自维基百科）是一个 IT 术语，指系统不间断地执行其功能的能力。它代表了系统的可用性程度，是系统设计的标准之一。服务不可能100%可用，所以要改进我们的高可用设计，我们必须尽最大努力提高服务的可用性，提高可用性指标。

用一句话来说：高可用就是指在任何情况下我们的服务都能最大程度地向外界提供。

2。如何提高系统可用性

从三个主要维度开始：

• 开发
• 部署
• 操作与维护

3。发展

3.1。首先，技术架构方案的选择非常重要。请记住避免过度设计。

例如，我们经常谈论单体应用架构和微服务架构。简单对比两种架构，单体应用架构比微服务架构具有更高的可用率。因为多个服务之间的依赖肯定会降低系统的可用性，比如一个外部接口依赖了10个微服务，假设每个服务的可用性都是99%，那么这个接口提供的外部服务的整体可用性会直接减少。 90.4%的人还必须考虑服务之间的网络延迟和数据一致性问题。

另一个例子是中间件选择。比如缓存业务场景，我可以使用内存缓存或者Redis分布式缓存。那么我应该使用哪一个呢？如果使用内存缓存的话系统可用性会更高，因为如果引入redis的话，系统的可用性将会乘以redis的可用性。当然，如果我们的业务场景一定要使用redis，那么也是完全可以的，但是这里要记住，系统的过度设计也是一个复杂的系统，同时也需要更多与高可用相关的保证，以及系统的成本。资源和运营维护成本。也是几何级增长。

3.2。第二是代码质量。

其实这可能是很多人忽视的一点，因为很多人更喜欢讲分布式、集群、压力测试、故障演练等等，但在我看来，一个代码开发的质量，或者说一个程序开发人员对代码的控制对于系统可用性起着至关重要的作用。

以下是代码尺寸的一些示例。第一个是异常处理。代码的质量取决于其处理异常的能力。本科生的课程设计代码可能都是主要业务逻辑，一直写到最底层，不考虑任何异常情况，

一个几年前毕业，经历过线上业务折磨的程序员，可能会发现代码中有很多try-catch来捕捉各种不确定的逻辑，但一个资深的程序员，相反，他可以'代码中看不到任何try-catch，因为它都是使用AOP来捕获异常。

这是代码维度的考虑。优秀的代码必须是防御性编程，并且还要配合单元测试。

第二个讲什么是对代码的控制。在大工厂里，你更有可能接手别人的旧代码。所有程序员一定都知道，接手别人的旧代码，尤其是别人写了一半的代码，是一种极其痛苦的经历。

古话说，前人栽树，后人乘凉。然而，在程序员圈子里，前人栽树，后人只能乘凉……这只是一个笑话，但有些事情是需要面对的。前期需要了解业务场景，梳理代码逻辑非常重要。

如果你不完全熟悉旧代码，那么你就不敢重写和重构它。如果在不熟悉的情况下贸然修改代码或者配置，然后上线，很有可能会导致上线问题。系统问题影响系统可用性。

从另一个角度来说，我们写的代码将来也可能会交给别人。防止他人受苦也是我们的责任。因此，合理使用设计模式、遵循代码规范、编写代码架构和设计文档也非常重要。它的重要性可能会影响系统未来的可用性。

具体措施：

1. 执行代码规范
• 项目布局目录结构标准化，团队保持统一、尽可能简洁
• 遵循团队的内部代码规范。一般来说，公司都有相应语言的规范。如果没有，请参考官方规格。代码规范可以大大减少错误并提高可用性。
2. 单一测试覆盖率
• 代码编写完成后，需要进行一定的单元测试，以保证代码的健壮性。也保证了我们后期调整逻辑或者优化时代码的稳定
• 包括增量覆盖和全覆盖。具体覆盖范围可根据团队内部实际情况确定。
3. 日志规格
• 不要随便打字日志
• 访问远程日志
• 能够分发链接跟踪

提高代码质量的工具：

• sonarqube：保证您编写出更安全、更简洁的代码。
• 阿里巴巴开源的java诊断工具Arthas也是一个不错的选择。
• idea内置的代码分析和其他代码扫描工具也很棒。

3.3业务保护设计（限流、断路器、降级）

系统无法高可用的另一个重要原因是我们的系统经常出现突发流量，导致我们的服务过载。这个时候首先要做的当然是快速扩容，我们也是提前做好规划的。应保留一定的冗余度。还有一种情况，即使我们扩容，仍然会出现过载的情况，比如超过下游依赖存储的最大容量，或者超过下游依赖的第三方服务的最大容量。那么这个时候我们就需要实施我们的过载保护策略，主要包括限流、熔断、降级。过载保护是为了保证服务部分可用，不至于整个服务完全不可用。

• 电流限制。限流是指限制进入系统的请求流量。如果请求量超过我们系统的最大处理能力或者超过我们规定的处理能力，那么该请求将被直接拒绝。这种丢弃部分请求的方式可以保证整个系统有一定的可用性，不至于整个系统完全不可用。如何判断是否超出最大处理能力？一般是根据QPS来判断的。如果QPS超过阈值，则直接拒绝请求。限流的具体策略有很多，比如接口限流、服务限流、用户限流等。

• 融化了。熔断和分断（开路）的值是为了限制故障范围。我们希望能够控制、减少或中断与故障系统的通信，从而减轻故障系统的负载，便于系统恢复。一般来说，我们的服务有很多下游依赖。如果下游依赖的服务出现了问题，比如开始超时甚至响应很慢，如果我们不采取任何措施，就会导致我们整个请求卡住超时。那么我们的业务服务将无法对外提供任何正常的功能。为此，熔断策略可以解决这个问题。熔断是指当我们所依赖的下游服务出现问题时，我们可以快速对其进行熔断（无需发起请求），这样我们的业务服务至少可以提供部分功能。断路器的设计需要至少包括三个部分：断路器请求判断机制算法、断路器恢复、断路器报警

• 降级。降级就是我们把系统的核心功能和非核心功能进行划分，然后当我们的系统超过最大处理能力的时候，我们直接关闭非核心功能，从而包装核心功能的可用性。关闭非核心功能后，我们的系统可以释放一些资源，使资源可以用来处理核心功能。熔断和降级这两种策略看起来很相似，但从字面上看都是快速拒绝请求的意思。但它们是二维设计的。降级的目的是为了处理系统本身的故障，而熔断的目的是为了处理我们系统所依赖的外部服务的故障。

4。部署

4.1 冗余和备份

我们首先考虑的是冗余和备份设计。这可能是大家都已经熟悉的情况。我们可以通过集群、多个服务器、磁盘或网络接口来减少故障点的数量。

说到集群，根据实现方式和目的，我帮大家梳理一下集中式集群类型：

1. 高可用性集群。由多个独立服务器组成的系统旨在提高系统可用性。当主节点出现故障时，备份节点通过故障转移自动接管服务。

我们最常见的有zookeeper集群、etcd集群等。这些集群基于共识算法，通过选举来保证当主节点发生故障时，自动备份节点可以自动接管。

2. 负载均衡集群。在负载平衡系统中，流量分布在多个服务器上，每个服务器独立处理请求。当服务器过载或发生故障时，请求会自动转移到其他可用服务器，以确保系统可用性和性能。

负载均衡可以在多个层面实现，包括应用层、传输层和网络层。

在应用层负载均衡中，负载均衡器通常通过 HTTP 代理分发请求，并根据请求的特定属性（例如 URL 或 cookie）路由它们。

在传输层负载均衡中，负载均衡器通常运行在传输层（例如TCP或UDP）上，并基于端口号或其他特定协议进行路由。

在网络层负载均衡中，负载均衡器通常是一个单独的网络设备，用于在不同服务器之间分配网络流量。 3.数据库集群。这里的数据库可以理解为广义的数据库，是数据的存储介质。对于数据库的集群实现，

分为以下几类：主从复制、复制集、分区。

关于这些实现方案，这里可以以elasticsearch为例。 ES有分片和副本的概念。所谓分片，就是将数据水平划分到多个节点，每个节点存储部分数据。查询数据时，需要在多个节点上查询，最后合并结果。分区可以实现数据的高可用性和可扩展性，但需要考虑数据的一致性问题。同时，每个ES分片可以配置多个副本。副本类似于主从复制，或者更像集群内的高可用性子集，允许多个副本实例同时存在，并支持自动故障转移和成员选举。 ，保证数据的高可用性和负载均衡。

此外，对于集群方案，还需要额外考虑多个机房的部署以及不同地点的多个活动。

也就是说，我所有的服务实例不能放在一个篮子里，因为网络的抖动和不稳定对系统可用性是一个很大的威胁。

4.2。释放检测

第二个关键点是释放检测。统计显示，我们的稳定性问题大部分来自于系统的变更，即系统的发布和上线。

5。操作与维护

5.1系统全链路观测监控

监控系统中通用的开源解决方案包括但不限于：

• ELK (Elasticsearch, Logstash, Kibana) 日志收集与分析 我们的日志记录无法存储在本地，因为微服务之后，日志分散在很多机器上，所以需要一个远程日志系统。 ELK是完美的选择

• Prometheus监控集合可以监控各种系统级指标，包括一些定制的业务指标

• OpenTracing 为一个请求分发了这么多上下游服务的全链路跟踪。如何将一个请求的所有上下游服务串联起来？那我们就要依赖OpenTracing了，它可以把一个请求下的所有链接串起来，并且有详细的记录

• OpenTelemetry 是可观测系统的最新标准。它统一并集成了跟踪数据（Traces）、指标数据（Metrics）和日志数据（Logs）来观察分布式系统的状态。我们会依靠开源系统来构建我们自己的或扩展它，甚至直接使用它。那么我们的监控指标一般会包括：

• 基础设施层监控：主要针对网络、交换机、路由器等底层基础设备。如果这些设备出现问题，依赖它们的业务服务肯定无法提供稳定的服务。我们常见的核心监控指标包括网络流量（传入和传出）、网络丢包、网络连接数等。

• 操作系统层监控：需要包括物理机和容器。常见的核心指标监控包括CPU使用率、内存使用率、磁盘IO、网络带宽等

• 应用服务层的监控：这里会有很多指标，核心的比如调用请求数、被叫请求数、接口成功率、接口失败率、响应时间（平均、P99、P95）等等）等等

• 业务内部定制监控：每个业务服务都有自己定制的监控指标。比如电商系统中：浏览、支付、发货等各种情况的业务指标

• 最终用户层面的监控：以前的监控更多是在内部系统层面，但是当用户真正访问页面时，也存在外网的情况。用户真正获取数据并打开页面需要时间。等待这个信息也很重要，但这一般需要客户端或者前端来进行统计。

5.2 报警系统

这些系统连接后，仅用于监控和统计。当出现问题的时候，也需要实时报警，所以也就有了实时报警系统。如果没有实时报警，我们就无法快速感知，就无法快速处理，给我们的业务带来重大故障和灾难。警报设计需要包括：

• 实时：实现秒级监控；
• 全面性：覆盖所有系统业务；
• 实用性：预警分为多个级别，监控人员可以根据预警的严重程度，方便实用地做出准确的决策；
• 多样性：预警方式提供推拉模式，包括短信、邮件、可视化界面，方便监控人员及时发现问题

6。总结

高可用系统的设计需要有相对科学的工程管理流程。必须从开发、部署、运维、甚至产品、业务各个方面来考虑和设计。这是一个综合的考虑。