系统别一宕就“全死”：谈谈高可用架构到底怎么设计

大家好，我是 Echo_Wish。
做运维这行久了，会发现一个残酷真相：

系统真正的对手不是黑客，是“挂”。

数据库一挂，业务停；
网关一挂，全站宕；
接口超时，老板电话就来了；
而最常见的事故复盘最后一句通常是：

“当时就那一台。”

所以今天咱聊的不是炫技，而是活命：
高可用架构怎么设计，怎么用负载均衡、集群让系统“不容易死”。

一、什么是高可用？不是“不挂”，而是“挂了也能扛”

大家别被“高可用（High Availability）”这个名字唬住，
它不是说系统永远不挂，
而是说：

挂了你也感受不到。

系统都是会出问题的，我们要做的，是让故障不影响业务。

就像高速公路修路，不会把路全封了，而是留车道，
系统架构也是这个逻辑：

• 不要只依赖一台 → 一挂全挂
• 不要把鸡蛋放一个篮子 → 那篮子抖一下全碎

所以高可用的底层逻辑特别质朴：

核心原则：消灭单点故障（SPOF）

凡事就问一嘴：

“这个东西挂了，会不会影响业务？”

如果答案是：会
→ 那就必须备份、扩容、冗余、分布式、集群。

二、高可用架构的三大思路（接地气版本）

一句话总结：

不是加机器，就是做切换，要么就分摊压力。

三、负载均衡：让请求别都挤一条道儿

最常见的高可用第一步就是：
把服务部署多个实例 + 加一个负载均衡器。

简单示意：

          ┌─────────┐
Request → │ LB层(HAProxy/Nginx) │
          └────┬────┘
           ┌────┴────┐
        Service A   Service B

配个最简单的 Nginx 负载均衡：

http {
    upstream backend_servers {
        server 192.168.10.1:8080;
        server 192.168.10.2:8080;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://backend_servers;
        }
    }
}

这样请求就不固定走某一个服务了，
挂一个，另一个还能扛。

但光这样不够。
如果两台全挂了，你照样寄。

四、集群管理：不是多部署，是让系统“自动”恢复

仅仅“多部署”是低级高可用，
真正能保证业务稳的，是自动检测 + 自动切换 + 自动恢复。

这就需要集群管理（Cluster Management）。

比较常见的方案：

比如我们搞一个 健康检查 + 自动摘除节点：

#!/bin/bash
# 简单健康检查脚本

SERVER="http://127.0.0.1:8080/health"

if curl -s $SERVER | grep -q "OK"; then
   echo "Service healthy"
else
   echo "Service bad, removing from LB..."
   # 执行摘除操作，视具体 LB 而定
fi

高可用的要点不是你准备了几台机器，
而是 “坏了之后，你不用手动修”。

五、数据库高可用才是重头戏（大多数系统死在这）

应用可以挂，数据库不能挂。
只要数据库挂了，业务直接黑屏。

常见做法：

简单 Keepalived VIP 漂移示例：

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    virtual_ipaddress {
        192.168.10.100
    }
}

VIP 不变，谁活着谁顶上，
业务连的 IP 不需要改。

六、最后说一句掏心窝子的

高可用不是优雅，是现实。
不是炫技术，是保命。

很多公司明明只用了一台数据库，一台网关，一台缓存，
还以为自己是“分布式架构”……