单点服务器适用于小流量场景，但存在单点故障风险；高可用架构通过消除单点、横向扩展、主从复制、负载均衡和自动故障转移等机制实现系统“不倒”。
单点服务器不是不能用，而是扛不住增长。当用户量、请求量、数据量开始爬升，单台机器的CPU、内存、磁盘IO和网络带宽很快见顶，故障一来整个服务就停摆。高可用架构的演进，本质是把“不能倒”这件事，从依赖一台机器，变成靠一套机制来兜底。
单点部署：验证快，但风险集中
开发测试、内部工具、小流量后台系统，单点部署仍是首选。它省去了服务发现、配置同步、跨节点事务等复杂问题，启动一个Docker容器或跑起一个Spring Boot应用就能对外提供API。但它的脆弱性也很直接：服务器宕机、硬盘损坏、内核崩溃、甚至一次误操作的rm -rf，都会导致服务完全中断。
- 适用场景：原型验证、CI/CD流水线中的临时环境、日活低于500的管理后台
- 关键提醒：哪怕只是单点，也必须配置基础监控（如CPU、内存、进程存活）和告警（邮件/钉钉），否则故障发生时你可能最后一个知道
- 典型技术栈：Nginx + 单体Java/Python服务 + 单实例MySQL/PostgreSQL
负载均衡+多实例：横向扩展的第一步
把一个服务部署在多台机器上，再加一层负载均衡器分发请求，这是最常见、见效最快的扩容方式。它不改变应用逻辑，只解决“单点”和“容量”两个核心问题。
- 负载均衡器选型：Nginx适合HTTP/HTTPS七层转发；HAProxy兼顾四层（TCP）与七层，对数据库读写分离更友好；云厂商SLB（如阿里云ALB、腾讯云CLB）则省去运维，但定制性略低
- 健康检查必须开启：定期探测后端实例的HTTP状态码或TCP端口连通性，自动剔除异常节点
- 注意会话保持：若业务强依赖session（如登录态），需配置cookie插入或IP哈希，避免用户反复登录；更推荐把session存到Redis等共享存储中，实现无状态化
数据层高可用：主从、集群与自动故障转移
应用可以多副本，但数据不能丢、不能错、不能长时间不可写。数据库的高可用比应用层更敏感，演进路径也更清晰。
- 主从复制是起点：PostgreSQL流复制、MySQL半同步复制，能保障数据冗余和读写分离，但主库挂了需人工干预切换
- 自动化集群是进阶：Patroni（PostgreSQL）、MHA或Orchestrator（MySQL）可结合etcd/ZooKeeper实现主库故障自动检测、选主、VIP漂移或DNS更新，RTO控制在10秒级
- 连接池要跟上：pgbouncer（PG）、mysql-proxy或ShardingSphere-Proxy，避免应用直连数据库造成连接数爆炸，同时支持连接复用与熔断
服务治理与容错：让系统“有弹性”而非“不崩溃”
集群规模上来后，节点多了，调用链长了，局部故障不可避免。这时高可用的重点，就从“不让它挂”，转向“挂了也不影响核心体验”。
- 熔断降级：用Sentinel、Hystrix或Resilience4j，在下游服务响应超时或错误率超标时快速切断调用，并返回预设兜底数据（如缓存值、静态文案）
- 限流保护：按QPS或并发数限制入口流量，防雪崩。令牌桶适合平滑限流，漏桶适合削峰填谷；网关层（如Kong、APISIX）或服务框架层（如Spring Cloud Gateway）都是落地位置
- 服务注册与发现：Eureka、Nacos、Consul让服务自动上报地址、自动感知下线，配合客户端负载均衡（Ribbon、Spring Cloud LoadBalancer），避免硬编码IP和手动维护列表
