访问量： 4589

亿级流量下的高可用实践：携程门票秒杀架构如何设计？

去哪儿“技术债”偿还实践：如何高效、低风险砍掉50%无用代码?

B站SRE负责人亲述 713事故后的多活容灾建设

如何避免这10类常见故障？B站数据库架构设计做了这5步……

SRE实战：如何低成本推进风险治理？稳定性与架构优化的3个策略

这些文章共同揭示：稳定性是设计出来的，而非运维出来的。 一次成功的架构优化，其价值远超无数次“救火式”的事后补救。架构优化的核心目标是提升系统的韧性（Resilience）、可扩展性（Scalability）和可维护性（Maintainability）。

一、 核心问题与教训：架构缺陷如何引发系统性风险？

  1. 单点故障（SPOF）：
    • 问题：关键组件（如SLB、主数据库）无冗余，一旦故障，导致大面积服务不可用。B站“713事故”即因SLB故障引发。
    • 根源：设计时未充分考虑高可用，过度依赖单一设备或服务。
  2. 热点与瓶颈：
    • 问题：流量或数据集中在少数节点（如热门商品、大Key、大表DDL），导致该节点过载，进而影响整个系统。携程秒杀场景中的Redis热点问题即为此类。
    • 根源：负载不均衡、缺乏有效的流量分片或缓存策略。
  3. 技术债堆积：
    • 问题：系统中存在大量无用代码、废弃服务、老旧架构，导致系统臃肿、维护成本高昂、发布效率低下、故障排查困难。
    • 根源：长期重功能开发、轻技术维护，缺乏定期的“系统瘦身”机制。
  4. 依赖脆弱：
    • 问题：对下游服务、数据库、缓存等依赖缺乏保护机制，一旦依赖出现问题，自身服务也迅速雪崩。
    • 根源：未实施熔断、降级、限流等容错设计。
  5. 扩展性差：
    • 问题：系统无法快速应对流量洪峰（如秒杀、促销），扩容耗时长、成本高。
    • 根源：架构未实现弹性伸缩，资源紧耦合。
  6. 数据一致性与延迟：
    • 问题：主从数据库延迟、缓存与数据库不一致，导致用户看到错误信息或下单失败。
    • 根源：复制机制缺陷、缓存更新策略不当。

二、 实践经验与提升方法：构建高可用、高韧性、可持续的架构

1. 高可用与多活容灾：消除单点，实现故障隔离

  • 怎么做：
    • 分层实现高可用：B站实践表明，需在接入层、服务层、中间件层均实现高可用。
      • 接入层：部署多个SLB/CDN节点，通过DNS/HTTP DNS实现故障转移；API网关多可用区部署。
      • 服务层：服务多可用区（AZ）部署，利用服务发现（如B站的Discovery）实现自动故障转移。
      • 中间件层：数据库主从架构+高可用组件（如Orchestrator）；缓存集群化部署。
    • 建设多活架构：
      • 同城多活：写请求跨AZ访问主库，读请求在本AZ闭环，通过Proxy实现路由。
      • 异地多活：需业务单元化改造，读写均在本单元闭环，通过DTS（数据传输服务）实现全局数据同步，并解决数据冲突（如覆盖、暂停）。
    • 优化故障切换流程：将“713事故”中1小时的SLB重建时间优化至5分钟，通过自动化脚本和预配置实现快速恢复。
  • 降低问题：将系统从“脆弱的单点”转变为“坚固的网络”，单个组件或机房故障不会导致全局不可用。

2. 弹性伸缩与容量管理：从容应对流量洪峰

  • 怎么做：
    • 引入云原生与存储计算分离：如B站引入TiDB，计算节点可基于K8s的HPA（水平Pod自动伸缩）能力快速扩容，应对突发流量。
    • 实施垂直与水平扩容：
      • 垂直扩容：动态调整实例资源（CPU、内存、Buffer Pool）。
      • 水平扩容：对于读负载，可快速将灾备或离线实例接入读负载池。
    • 常态化故障演练：B站模拟单机房故障，验证数据库切流效果和预案有效性，确保多活架构“能用、好用”。
  • 降低问题：系统具备“弹性”，能像弹簧一样伸缩，避免因流量突增导致服务崩溃。

3. 主动偿还技术债：精简系统，提升可维护性

  • 怎么做：
    • 制定明确目标：去哪儿网设定“代码精简50%”的明确目标，驱动变革。
    • 两阶段法：“找得到” + “删得好”。
      • 找得到：利用可观测性技术（如代码行覆盖率、调用链分析）识别无流量、低价值的服务和代码。
      • 删得好：建立自动化、低风险的删除流程，通过灰度、监控验证确保安全。
    • 四步筛选模型：挖掘特征（如无流量、无变更）-> 度量特征 -> 收集数据 -> 匹配特征，实现自动化识别。
    • 设立公共支持团队：提供通用工具和方法论，支持各业务线自主精简。
  • 降低问题：系统更轻量、更清晰，发布更快、故障更少、维护成本更低，从根本上提升稳定性。

4. 核心架构优化：针对常见故障的专项治理

  • 怎么做：
    • 数据库架构优化（B站5步法）：
      1. 高可用：主从复制 + 高可用组件。
      2. 扩容：垂直+水平扩容，引入云原生数据库。
      3. 多活建设：实现同城/异地多活。
      4. Proxy代理：实现读写分离、拦截、限流、熔断，作为数据库的“安全阀”。
      5. 慢查询预警：通过历史数据对比和线性回归，预测性地发现慢查询，变被动为主动。
    • 秒杀架构优化（携程实践）：
      1. 多级缓存：在客户端、本地、Redis多层缓存热点数据，减轻后端压力。
      2. 热点识别：在SDK层主动发现热Key，并自动降级到本地缓存。
      3. 大Key优化：避免单个Key过大，导致网络阻塞或GC停顿。
      4. 精细化流量控制：对不同用户、不同渠道进行限流，防止恶意刷单。
      5. 数据一致性保障：采用可靠的消息队列、分布式锁等机制，确保超卖等问题不发生。
  • 降低问题：针对最常见、影响最大的故障场景进行专项优化，从根源上消除隐患。

5. 成本与风险的平衡：低成本推进风险治理

  • 怎么做：
    • 策略一：风险分级：将风险分为高、中、低，优先处理高风险项（如可能导致全站不可用的单点故障）。
    • 策略二：小步快跑：不追求一次性大改造，而是通过多个小的、低风险的优化迭代来逐步提升架构质量。
    • 策略三：工具赋能：开发自动化工具（如代码精简平台、容量评估工具），降低优化成本，提高效率。
  • 降低问题：在资源有限的情况下，也能持续、有效地推进架构优化工作，避免“雷声大雨点小”。

总结：架构优化的“三大支柱”与“行动指南”

优化方向核心目标关键实践方法
高可用与容灾消除单点，故障隔离多层高可用、多活架构（同城/异地）、快速切换流程、常态化演练
弹性与可维护性应对洪峰，降低维护成本云原生/存储计算分离、弹性伸缩、偿还技术债（代码/服务精简）、自动化工具
专项与主动治理解决痛点，防患未然数据库5步法、秒杀架构优化（缓存/限流/一致性）、慢查询预警、风险分级治理

行动指南：

  1. 诊断：定期进行架构评审，识别单点、瓶颈、技术债。
  2. 规划：设定清晰目标（如“明年实现同城多活”、“砍掉30%无用代码”）。
  3. 执行：选择合适策略（大改造 or 小步快跑），利用工具和自动化。
  4. 验证：通过压测、故障演练验证优化效果。
  5. 固化：将最佳实践写入规范，形成持续优化的机制。

最终，一个优秀的架构不仅是技术方案，更是一种持续演进、主动防御的文化。通过系统性的架构优化，可以将“救火”变为“防火”，从根本上提升系统的稳定性和业务的连续性。