高可用设计

1.背景

可用性是一个可以量化的指标，计算的公式在维基百科中是这样描述的：根据系统损害、无法使用的时间，以及由无法运作恢复到可运作状况的时间，与系统总运作时间的比较。

行业内一般用几个9表示可用性指标，对应用的可用性程度一般衡量标准有三个9到五个9；一般我们的系统至少要到 4 个 9（99.99%）的可用性才能谈得上高可用。

高可用（High Availability）的定义：（From 维基百科）是 IT 术语，指系统无中断地执行其功能的能力，代表系统的可用性程度，是进行系统设计时的准则之一。

2.高可用设计

2.1高可用设计思路

高可用设计需要从以下方面考虑设计：

2.2高可用详细设计

2.2.1 应用层

设计关注点：系统运行过程中，不可避免的会产生故障，可能是由于网络异常导致，可能是由于操作错误导致，可能是由于依赖服务崩溃导致等，要根据不同的异常，设计不同的处理策略。

高可用设计思路	当前设计梳理	未来设计规划
操作错误导致故障： 平台正常使用过程中，由于操作错误导致的异常，或者由于正常操作导致的任务失败等，高可用设计思路如下： 首先应该提供友好的提示。 其次，应尽可能的提供自动重试或者手动重试的功能设计，以帮助用户恢复故障。	友好提示 重试
网络问题导致的故障： 由于网络故障导致访问第三方服务无法获取响应的异常情况，高可用设计思路如下： 设定超时时间，超过超时时间，则抛出异常。 设定重试次数（一般是3次），重试依然失败，则进入终态。	统一配置restTemplate 的超时时间和重试次数 超时设置：10 min 重试次数：3次 重试间隔：500 ms	应针对不同的第三方服务以及不同的功能场景，设置不同的超时时间和重试机制。 如fas 服务超时时间设置为10 min； drd网关相关服务超时时间设置为10s； 等等。
依赖服务导致的故障： 依赖服务故障，导致平台功能故障的情况，高可用设计需要考虑如何避免故障范围扩大，以免造成其他功能故障，或者造成无法挽回的错误 服务熔断：对故障服务进行熔断处理，对该服务的所有请求将被快速处理，返回错误 服务降级：依赖该故障服务的功能，进行服务降级，暂时不可用，避免错误操作导致故障升级		使用Istio 或者 hystrix 实现熔断能力 依赖的其他服务应该尽量实现熔断能力 依赖其他服务的功能，实现服务降级的能力，服务不可用时，停止提供相关功能
服务过载导致的故障 监控应用流量的 QPS 或并发线程数等指标，如果请求量超过了系统最大处理能力或者超过了指定的处理能力，需要有对应的应对策略，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。 异步处理：对于耗时的操作，以及对实时性无要求的操作，采用异步处理的方式，提高吞吐能力，降低模块耦合度，降低过载概率和故障影响范围 限流：监控应用流量的 QPS 或并发线程数等指标，当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的高可用性。 排队：当并发较高的时候，甚至是流量突发的时候，只要消息生产者能够将消息写入到消息队列中，那么这个消息就不会丢，后续处理逻辑可以慢慢的去消息队列里面消费这些突发的流量数据，这样就不会因为有突发流量而把整个系统打垮，还可以做到削峰的作用	在异步处理应用方面 在限流方面 在排队处理方面	限流和排队方面
应急预案：应急预案主要是为了应对突发事件或异常情况，保证系统的高可用性。 软件故障：包括应用程序出现错误、系统崩溃等，导致系统无法正常提供服务。 入侵攻击：包括黑客攻击、病毒攻击等，导致系统被攻击者控制或瘫痪。	无	软件故障：应急预案应该包括重启应用程序、回滚版本、恢复备份等措施。 入侵攻击：应急预案应该包括隔离攻击、清除病毒、备份数据等措施。

2.2.2 数据层

设计关注点：数据层的高可用方案，本质都是通过通过数据冗余的方式来实现高可用，将数据复制到多个存储介质里面，可以有效的避免数据丢失，同时还可以提高并发能力。

高可用设计思路	当前设计梳理	未来设计规划
mysql的高可用： 数据备份和恢复：确保定期备份数据库，并测试备份的可用性。同时，建立有效的恢复策略，以便在发生故障时能够快速恢复数据。 数据复制和同步：使用MySQL的复制功能，将主数据库的数据复制到一个或多个从数据库中。这样可以实现数据的冗余存储和读写分离，提高系统的可用性和性能。 故障检测和自动切换：监控数据库的状态，及时检测到故障并采取相应的自动切换措施。例如，使用心跳检测来监测主数据库的可用性，并在主数据库故障时自动切换到从数据库。 负载均衡：通过使用负载均衡器，将请求分发到多个数据库节点上，以实现请求的均衡分配和高并发处理能力。这样可以提高系统的性能和可扩展性。 故障恢复和容灾：设计容错机制，确保在发生故障时能够快速恢复系统，并保证数据的一致性和完整性。例如，使用数据库集群或分布式存储系统来实现数据的冗余备份和故障切换。
doris的高可用
minio的高可用 分布式架构 数据冗余 自动故障检测和恢复 水平拓展 快速故障转移
应急预案：应急预案主要是为了应对突发事件或异常情况，保证系统的高可用性。 数据丢失：包括数据误删除、备份失败等，导致系统数据丢失。	无	数据丢失：应急预案应该包括恢复备份、重新构建系统等措施。

2.2.3 运维层

设计关注点：在服务运维期间，应主要关注服务的健康运行，如服务状态的感知和检测，故障的通知和自动处理策略，以及服务升级或迁移等场景的可用性持续。

高可用设计思路	当前设计梳理	未来设计规划
健康检查 自动恢复	k8s提供了健康检查和自动重启功能，可以监测容器实例的健康状态，并在发现故障时自动重启或替换容器实例
服务升级与迁移 逐步升级或迁移：避免一次性升级或迁移所有服务实例，而是采用逐步的方式进行。这可以减少对整个系统的影响，并提供更好的控制和回滚能力。 蓝绿部署：使用蓝绿部署策略，在升级或迁移过程中同时运行新旧版本的服务。通过将流量逐渐切换到新版本，可以确保服务的平稳过渡，并在需要时快速回滚到旧版本。 无状态服务：设计服务时尽量保持无状态，将状态信息存储在外部存储（如数据库或缓存）中。这样，在升级或迁移过程中，可以更容易地替换或迁移服务实例，而不会丢失重要的状态信息。 健康检查和自动重启：在升级或迁移过程中，使用健康检查机制来监测服务实例的健康状态。如果服务实例出现故障或不可用，可以自动重启或替换实例，以确保服务的可用性。 数据迁移策略：如果服务迁移涉及数据迁移，确保在迁移过程中数据的一致性和完整性。可以使用数据同步工具或备份和恢复机制来实现数据的平滑迁移。 监控和警报：在升级或迁移过程中，实时监控服务的运行状态和性能指标。设置适当的警报机制，以便在出现异常情况时及时采取措施。 回滚计划：在升级或迁移过程中，制定详细的回滚计划。确保有备份和恢复机制，以便在需要时能够快速回滚到之前的版本或状态。 平滑过渡：在升级或迁移过程中，尽量避免对用户造成中断或影响。可以使用负载均衡器或代理服务器来实现平滑过渡，将流量逐渐切换到新版本或新环境。	平台部署运行在 k8s 环境中，通过 deployment 配置服务升级策略，保障了平滑的服务升级和迁移。 在数据迁移方面，目前还需要认为介入进行数据备份与迁移
日志记录与查看 监控与报警
灾备与故障切换	k8s支持跨多个数据中心或云提供商的集群部署，可以在主数据中心或云出现故障时，自动切换到备份数据中心或云，保证服务的连续性。

2.3.4 基础设施层

设计关注点：基础设施层主要从服务器硬件层面、服务整体架构、服务部署等方面进行高可用设计。

高可用设计思路	当前设计梳理	未来设计规划
集群部署 避免单节点故障导致服务不可用 负载均衡		应在资源允许情况下，进行多节点服务部署，保证服务单节点故障时的可用性
服务发现与注册	k8s提供了内置的服务发现和注册机制。通过定义Kubernetes服务（Service），可以为应用程序创建一个稳定的网络端点，并自动将流量路由到正确的容器实例。
自动化部署 自动伸缩 更好的容错性（Fault-tolerance） ：及时、快速应对负载压力 更好的可用性（High Availability） ：高可用的本质：冗余	通过天牛平台提供的统一打包和一键部署等能力，可以实现平台的快速自动化部署 目前平台没有自动伸缩的能力	k8s 提供3个维度上的伸缩能力： 1、CA（Cluster Autoscaler）：Node级别自动扩/缩容cluster-autoscaler组件 2、HPA（Horizontal Pod Autoscaler）：Pod个数自动扩/缩容 3、VPA（Vertical Pod Autoscaler）：Pod配置自动扩/缩容，主要是CPU、内存,addon-resizer组件 后续可以根据业务场景需求，进行服务的自动伸缩配置，目前各个业务场景中，还没有涉及相关内容
应急预案：应急预案主要是为了应对突发事件或异常情况，保证系统的高可用性。 系统故障：包括服务器硬件故障、网络故障、存储设备故障等，导致系统无法正常提供服务。 自然灾害：包括地震、洪水等自然灾害，导致系统无法正常提供服务。	无	系统故障：应急预案应该包括备份设备、故障切换、快速修复等措施。 自然灾害：应急预案应该包括容灾备份、远程备份等措施。（应适客户需求进行设计）