爆发式增长业务的高可用架构优化之路

爆发性增长业务的稳定性挑战与应对之道

稳定性挑战

• 基础设施挑战：中间件及基础设施庞大，规模大、中间件复杂，业务架构复杂，X因素多（变更与非变更故障）。
• 业务架构挑战：业务子系统多，下游二方/三方依赖多，复杂系统链路长导致问题定位困难，二方/三方系统故障影响RT和成功率。
• X因素挑战：上游请求量暴增、下游失败重试、非法请求/安全攻击、链路变更故障，系统自我保护和下游超时保护需求，需区分强弱依赖和防止重试风暴。

稳定性应对之道

• 事前防范：通过灰度平台（流量染色&识别、环境标定位）、压测平台（自动化压测、引流录制、一键压测、自动报告）、引流回放平台（线上真实流量回归验证）、逆向监控（正逆向校验、三流对比、Faas规则可插拔）实现未然防范。
• 事中快速发现：对线上系统保持敬畏，通过上述监控手段快速定位问题。
• 事后快速恢复：结合灰度、压测、回放平台实现快速恢复。

异地多活—单元化技术架构

• 背景：核心业务依赖机房无法抵抗地域级故障，需建设通用机房级异地容灾架构。
• 方案选型：对比同城双活（灾备切换时间长、受地域资源限制）、异地冷备（资源浪费、切换困难），选择数据单元内闭合的单元化架构。
• 单元划分模式：Unit（读写内单元、随时切流）、Copy（读走单元服务、写走中心服务）。
• 单元化纬度：买家纬度单元化，实现单元封闭和统一管控。
• 中间件单元化方案：自研Go中间件实现单元化路由和纠偏，TDDL禁写能力，统一管控规则。
• 单元化遇到的问题：系统庞大链路复杂（内圈向外推动）、强中心化服务（按单元做业务划拨）。
• 高级坑：单元化数据库字段变更会锁表，采用无锁变更（临时表创建、数据拷贝、Binlog同步、表切换）但有丢数据风险。
• 高可用与单元化成本取舍：平时两单元扛流量，大促态扩到多单元。

降爆炸半径—自研Service Mesh实现去中心化网关

• Service Mesh架构：南北流量通过类似Envoy的数据面管理，东西流量通过类似Dapr的Sidecar通讯，多语言访问中间件下沉到Sidecar。
• Service Mesh业务落地：遵循稳定性三板斧（可灰度、可监控、可回滚），支持白名单和百分比灰度控制，从非核心应用到核心应用逐步切换。