别急着画架构图，先回答一个问题：你的系统挂多久，业务会出问题？
在金边做软件开发12年，团队维持在28个人，每年交付大约100个项目。主攻电商、娱乐、金融交易、地产和物流，客户分布在柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚七个国家。见的客户多了，有个现象反复出现：很多老板上来就说“系统绝对不能挂”，但真坐下来细聊，每个人对“不能挂”的理解完全不一样。
有个本地外卖平台的客户就是这样。第一次见面态度很坚决，说平台必须7×24小时在线。后来我们追问了一句：半夜两三点没什么订单的时候，系统挂半小时你会在意吗？他想了想，说不会。他真正在意的是午市和晚市那两个高峰时段，那段时间每断一分钟都是真金白银的损失。最后我们把资源集中在高峰时段的稳定性保障上，架构投入省了将近一半。
所以，高可用设计的起点不是技术选型，而是把“可用性”翻译成业务能感知的具体指标。这个指标叫SLO（服务水平目标），它决定了后面所有架构决策的方向。
不同可用性等级意味着什么，对应的架构形态和适用场景有哪些，下面这张表可以快速建立认知：
| 可用性等级 | 年允许停机时间 | 典型架构形态 | 适用场景 |
|---|---|---|---|
| 99.9%（三个9） | 8.76小时 | 单机房集群 + 主从复制 | 内部管理系统、非核心业务 |
| 99.99%（四个9） | 52.6分钟 | 同城双活 + 自动故障转移 | 电商交易、SaaS平台 |
| 99.999%（五个9） | 5.26分钟 | 异地多活 + 单元化架构 | 金融清算、支付核心链路 |
有个容易被忽略的数字：每往上提一个9，综合成本通常翻3到5倍。不是线性增长，是跳跃式增长。2021年我们参与过一家柬埔寨本地银行的核心系统改造，对方明确要求五个9。光机房租用和专线费用，一年就多出18万美元。这个数字对银行来说可能合理，但换成一个建材批发的SaaS系统，就完全没必要了。那个建材客户最初也说要高可用，我们评估后建议他99.9%加一套凌晨自动备份脚本就够了，省下来的预算投到了离线报表模块上——那才是他业务团队天天催的功能。定制开发的意义就在这里：把每一分钱花在业务真正需要的地方，不为用不到的可用性买单。
加了冗余就一定高可用？这三个坑我们每年都遇到
冗余是高可用的基础手段，但“有冗余”和“高可用”之间隔着一条很宽的河。下面三类问题，在我们经手的项目里反复出现，几乎成了通病。
应用层做了集群，负载均衡器反而成了最大的单点
2022年我们接到一个柬埔寨本地电商的急救需求。他们应用层部署了4个节点，看起来冗余很充分，但前面只挂了一台Nginx做流量分发。结果Nginx内存泄漏，双12当天直接挂了。后面的4台应用服务器全部变成摆设，整个平台宕机2小时。后来我们把入口改成两台Nginx加Keepalived虚拟VIP，主备切换实测1.2秒完成，客户端完全无感知。预算允许的话，直接用云厂商的托管负载均衡更省心，运维成本几乎可以忽略。
这个案例的教训很直白：冗余要覆盖整条请求链路上的每一个环节，任何一个环节没做冗余，前面做的所有冗余都可能白费。
数据库读写分离了，但主从延迟让用户“看到不该看的东西”
读写分离是提升数据库吞吐量的常用手段，但很多团队忽略了从库延迟带来的体验问题。我们做过一个在线票务平台的定制开发，用户买完票跳转到“我的订单”页面，结果看不到刚买的票。客服每天接上百通投诉电话，用户以为支付出问题了，实际上只是从库还没同步到那条订单记录。
解决方案是在代码层引入“读己之写”策略：下单成功后30秒内，订单查询强制走主库。同时把刚生成的订单快照写入Redis，TTL设60秒，覆盖从库延迟窗口。上线之后，相关客诉直接归零。这个方案不复杂，但需要开发团队在设计阶段就意识到从库延迟是一个必须面对的问题，而不是上线后出了问题再去补。
文档里写着“无状态服务”，代码里却藏着本地状态
很多架构文档会写“服务无状态化”，但真去翻代码，可能会看到File.WriteAllText()把临时文件存到本地磁盘，或者用静态变量缓存用户会话。这些“隐形”的本地状态，平时运行完全正常，一旦实例故障，数据就跟着丢了。而且这类问题在常规测试里很难暴露，因为测试环境很少模拟实例突然宕机的场景。
我们的做法是在Code Review阶段用SonarQube自定义规则，扫描本地文件写入和静态集合的使用。从源头堵住，比事后补救成本低得多。
数据库层：高可用架构里最难啃、也最值得投入的部分
应用层做无状态化相对容易，真正拉开架构水平差距的是数据库层。数据库高可用没有捷径，但有一条经过验证的演进路线，可以根据业务当前阶段选择对应的方案。
第一阶段：主从复制加手动切换，先把数据保住
这个阶段的目标是99.9%的可用性。MySQL半同步复制（semi-sync replication）保证至少一个从库收到binlog后才返回客户端确认，主库宕机时数据丢失风险降到秒级。但切换需要人工介入，恢复时间通常在10到30分钟。这个阶段有一个关键配置：rpl_semi_sync_master_timeout建议设1000毫秒，避免从库网络抖动时主库写入被长时间阻塞。
适合这个方案的场景包括内部管理系统和非核心业务。我们的很多客户在项目初期都从这个阶段起步，投入小，数据安全性有基本保障。
第二阶段：自动故障转移，把恢复时间从半小时压到30秒
当业务开始依赖系统持续在线时，手动切换的30分钟就太长了。这个阶段引入Orchestrator或MHA来管理MySQL拓扑。自动检测主库心跳，2秒一次，连续3次失败就触发切换，总恢复时间可以压缩到30秒以内。
但自动切换有一个必须处理的隐患：脑裂。以Orchestrator为例，它通过Raft协议选举leader节点，只有leader有权执行切换，避免多节点同时发起切换导致双主冲突。这个细节直接决定了自动故障转移能不能在生产环境放心用。
第三阶段：分片加跨机房容灾，应对单库扛不住的增长
当单库写入QPS超过5000，或者数据量超过500GB，水平分片就不是可选项而是必选项了。我们服务过的一家金融科技公司在定制开发交易系统时，把流水表按user_id % 64拆成64个分片，每个分片一主两从，分布在不同机柜。配合ShardingSphere的读写分离和分片路由，单个分片故障只影响1/64的用户，整体可用性大幅提升。跨机房层面，采用MySQL Group Replication的异步复制模式，同城机房之间走专线同步，RPO控制在1秒以内。
这个阶段的投入显著增加，适合金融交易、支付核心链路这类对可用性有硬性要求的场景。我们团队在金融和交易类项目上有多年积累，这类架构的落地经验是实打实跑出来的。
熔断、限流、降级：参数调不对，保护机制比故障本身更伤业务
熔断、限流、降级，这三个词几乎出现在所有高可用方案里。但真正把参数调对的项目，少之又少。最常见的问题就是阈值设置要么过于敏感、要么过于迟钝，两种极端都会伤害业务。
具体到参数层面，有几个容易踩的坑：
- 熔断阈值不能一刀切：Hystrix默认错误率50%触发熔断，这个默认值对支付接口来说太宽松了——5%的错误率已经意味着大量用户支付失败。建议按业务敏感度分层设置：核心链路（支付、下单）错误率超过10%就熔断，非核心链路（推荐、评论）可以放宽到30%。
- 限流算法要匹配业务特征：令牌桶适合允许突发流量的场景，漏桶适合需要平滑输出的场景。API网关层建议用Sentinel的“匀速排队”模式，既控制QPS又避免请求被粗暴拒绝。
- 降级顺序要提前定好，不能临时拍脑袋：提前定义降级优先级清单，写入配置中心。比如：推荐列表 → 用户评价 → 优惠券查询 → 库存展示 → 下单 → 支付。前三个可以降级为静态缓存或空数据，后三个任何情况下都不允许降级。
这些参数没有普适的“正确值”，必须结合具体业务的容忍度来调整。这也是定制开发和套模板之间的本质区别——模板给你一套能跑的东西，定制开发给你一套真正匹配业务的东西。
Kubernetes不是银弹，但用对了三个特性确实能直接提升可用性
容器化改变了高可用的实现方式，从“手动配置”进入“声明式管理”。但K8s本身并不能自动保证高可用，用错配置反而会引入新的风险。在我们做的定制开发项目里，下面三个特性对可用性提升最直接：
- Liveness与Readiness探针必须分离：Liveness探针失败会触发Pod重启，Readiness探针失败只会把Pod从Service端点摘除。很多团队把两者配成同一个HTTP接口，导致应用启动慢或短暂阻塞时被误杀。正确做法是：Liveness探针检查进程存活性（如
/healthz，返回200即可），Readiness探针检查依赖就绪状态（如数据库连接池可用、缓存预热完成）。 - PodDisruptionBudget（PDB）要设：设置
minAvailable: 2，管理员执行节点维护或集群自动缩容时，K8s会保证至少2个Pod始终存活。没有PDB保护的Deployment，节点驱逐时可能瞬间全部不可用。这个配置花不了两分钟，但在关键时刻能救命。 - TopologySpreadConstraints让Pod分散到不同可用区：一个在线教育平台在定制开发时设置了
maxSkew: 1和topologyKey: topology.kubernetes.io/zone，确保3个副本分布在3个不同可用区，单个数据中心故障不影响服务。这个配置直接决定了你的“多副本”是真正的跨机房冗余，还是纸面上的多副本。
没验证过的高可用，都只是“相信它能用”
架构文档写得再漂亮，没经过故障演练，都只能算假设。混沌工程的核心价值，就是用受控实验替代“祈祷式运维”。定制开发团队不用一步到位上全套Chaos Monkey，可以从三个渐进实验开始：
- 实验一：杀进程——随机终止一个应用Pod，观察K8s是否在30秒内完成重启，请求有没有丢失。预期结果：Liveness探针检测失败 → Pod重启 → Service端点恢复，期间请求由其他副本承载。如果这个流程跑不通，说明探针配置或副本数有问题。
- 实验二：注入网络延迟——用Chaos Blade给数据库连接注入200毫秒延迟，观察连接池是否饱和、熔断器是否触发、业务响应时间是否在可接受范围。这个实验能暴露出很多“正常时看不出来”的参数问题。
- 实验三：模拟机房断电——在测试环境直接关闭一个可用区的所有节点，验证流量是否全部切到另一可用区，切换后的容量是否够扛全部负载。这是最接近真实灾难的演练，建议每半年执行一次。
每次演练后产出故障复盘报告，记录发现的问题、修复措施和下次演练时间。我们服务过的一家电商公司坚持每月一次GameDay演练，一年内把平均故障恢复时间（MTTR）从45分钟压缩到6分钟。这个提升比任何架构优化都来得直接，因为演练暴露的问题往往是最容易被忽视的运维细节。
给定制开发团队的五条落地建议
高可用架构设计没有标准答案，但下面五条原则在我们团队12年的实践中被反复验证，几乎适用于所有定制开发场景：
- 先画故障树，再画架构图：列出所有可能导致服务不可用的单点——DNS、负载均衡、应用实例、数据库、消息队列、第三方依赖——逐一确认冗余和切换方案。哪个单点没有冗余方案，就明确记录为“已知风险”并设定监控告警。知道哪里会出问题，比相信哪里都不会出问题靠谱得多。
- 核心链路优先，非核心敢于牺牲：电商系统在流量洪峰时，推荐模块挂了远比下单模块挂了可接受。架构设计时应明确各模块的可用性等级，把资源集中在核心链路上。
- 监控指标要能回答问题：光有CPU、内存监控不够。每个微服务至少暴露四个黄金指标：延迟（P99）、流量（QPS）、错误率、饱和度。故障发生时，能在2分钟内定位到具体服务和依赖。定位不了问题的监控，等于没有监控。
- 文档不是负担，是故障时的救命稻草：为每个核心服务编写Runbook，包括架构图、依赖关系、常见故障处理步骤、回滚方案。故障发生时人处于高压状态，没有文档的团队往往在慌乱中做出错误决策。
- 高可用是持续过程，不是一次性项目：业务在变，流量在涨，依赖在增加。每季度重新审视架构中的单点风险，每半年做一次容量评估，每年至少执行一次跨机房切换演练。
如果你的团队正在规划一个定制开发项目的高可用架构，或者现有系统频繁出现可用性问题，可以找我们聊聊。我们团队在金边做了12年开发，28个人，每年交付约100个项目，客户覆盖柬埔寨、菲律宾、越南、老挝、泰国、印尼、马来西亚七个国家。电商类系统有现成成品，开箱即用，交付速度快；复杂项目开发周期从几天到两个月不等。沟通用中文，TG分钟级响应，系统bug修复免费，新增功能按工作量评估。具体报价需要面谈或Telegram详谈，按功能清单评估，付款方式为先付30%，验收后结清尾款。支付通道由客户提供资源，我们负责对接，这块不碰。不接的活我们也会直说，能帮上的忙一定给出具体建议。