Forrest’s 博客🚍高可用的常见手段
type
status
date
slug
summary
tags
category
icon
password
Blocked by
Blocking
AI summary
高可用是一个复杂的命题。日常的运维操作例如服务升级、硬件更新、数据迁移等都会造成服务等宕机，尤其是在功能上线周期越来越短、发布越来越频繁的开发模式下，实现“4个9”或“5个9”高可用的难度不言而喻。简单来说，在设计时要避免单点故障：路由、防火墙、负载均衡、反向代理以及监控都得是冗余设计，以此来保证最佳的高可用性。
以下是一些提升系统高可用的常规方法，对于思考系统设计时会有不少帮助
一 服务无状态化
所谓的无状态化是指每个服务实例的服务内容和数据都是一致的，每一个服务都能提供服务。如果每一个服务都是无状态的，那么我们能够根据系统的负载，进行服务的扩缩容，这时目前微服务的主流趋势。
若服务是有状态的，那么逻辑处理是依赖数据的，此时应该将“有状态”的数据剥离出来，借助擅长数据同步的中间件使得数据的集中管理，保证数据的一致性。
因为提供逻辑处理的服务是无状态的，当流量爆发时，进而扩容时无需考虑数据是否一致的问题。
二 服务拆分
将一个大的系统拆分为多个独立的小模块，各个模块之间互相调用，是减少故障影响的主要手段。当一个模块出现问题时，只会影响系统的局部服务，同时，模块之间调用尽量异步化，因为调用的响应时间越长，存在超时的风险越大。
三 服务冗余
每个服务运行多个实例，也就是牺牲一定的资源换取更高的可用性。当主设备出现故障时，只需要切换住呗设备，就能实现故障的转移，即可短时间内恢复服务。
除了考虑实例的冗余，还需要考虑设备的隔离冗余，也就是服务实例是否部署在不同的计架、不同的机房、不同的数据中心。
四 数据存储高可用
无论业务如何拆分，有状态的数据存储服务依旧是限制整个服务高可用的瓶颈。存储高可用的方案的本质是将数据复制到多个存储设备中，通过数据冗余的方式来实现高可用。
但是无论是正常情况下的传输时延，还是异常情况下的数据中断，都会导致系统的数据在某个时间点出现不一致。数据的不一致又会导致业务问题。在CAP理论中，最多满足其中的两个，而其中分区容错性是必须的，那么此时在做架构设计时，我们必须结合业务对一致性和可用性进行取舍。
五 服务降级
服务降级不是为了避免故障发生，而是当故障发生时，减少故障带来的损失，也就是常说的兜底操作。当系统正常操作时，能提供100%的能力，当故障发生时，我们通过有效的措施使得服务不是完全不可用，而是提供其中核心的功能。这类措施通常称为流量管理。常见的流量控制有限流和熔断。
限流是服务器端处于保护自己的目的，限定自己所接受的并发请求上限，超出流量控制的上限的请求直接被拒绝或随机选择拒绝，以防止服务过载。
熔断时客户端在发出请求后，由于无法在固定的期限内收到预期的目标（失败率大于xx、平均响应时间超过xxs、异常数量大于xx时），从而采取服务降级的手段。
六 负载均衡
负载均衡时高可用手段中必不可少的手段之一，可以按照权重负载均衡、按地域就近访问等手段，来提升系统的整体效率，避免因为过载而导致整个系统全地域失效。
七 服务变更管理
变更时影响高可用的最大因素，此时需要一个完备的流程管理。
应用的变更需要经过灰度部署，在小范围内进行，监控足够长时间后没有问题，再继续变更，通过流量管理，将新版本推送给固定特征的用户群体。同时尽量采取自动化发布，减少人为发布的流程。使用持续集成和持续部署来减少认为错误的概率。
灰度发布还应该配合有效的回滚机制，当系统变更出现问题时，能够快速从故障中恢复。
出了发布流程，还应该在开发流程上做出响应的规范，比如代码质量检测、静态代码扫描、持续集成、自动化测试等。
八 服务监控
完善的监控系统对整个系统的可靠性和稳定性都有很大帮助。服务监控更多时对风向的预判，在出现服务不可用之前对风险进行预判。
一套完整的服务监控体系需要涵盖服务运行层的各个层面
- 基础设施监控：网络、交换机、路由器等地层设备等丢包错包情况
- 系统层面的监控：物理机、虚拟机的CPU、内存情况
- 应用层的监控：请求的数量和延时情况、服务性能和错误率
Prev
常见的网络设备
Next
k8s架构简介
Loading...