基于 ESA 流量分治的多云架构设计与实践

1. 项目背景与目标

为规避单一云厂商依赖风险，提升系统容灾能力与业务连续性，我们设计并落地了一套基于 ESA（边缘安全加速平台）流量分治的多云架构，核心目标包括：

流量可调度：按用户 ID（userid）和接口维度，灵活配置各云流量比例。
故障快速恢复：单云故障时，15 秒内完成全量流量切换。
数据最终一致：跨云场景下，通过 OceanBase 主从同步 + Redis 延迟双删，平衡性能与一致性。
服务发现隔离：各云独立部署私有化 CoreDNS，同时支持跨云服务解析。

2. 整体架构图

flowchart TD User[用户请求] subgraph ESA[ESA 边缘安全加速平台] Traffic[流量分治器 （userid + 接口）] Traffic -->|10% A接口| Aliyun Traffic -->|90% A接口| Tencent Traffic -->|一键全量切流| Aliyun Traffic -->|一键全量切流| Tencent end subgraph Aliyun[阿里云（主）] ALB[ALB] UI1[UI 层] Service1[Service 层] Middleware1[中间件（私有化） Redis Proxy / MySQL Proxy ELK / Kafka / Memcache] DNS1[私有化 CoreDNS 服务发现 + 跨云] ALB --> UI1 --> Service1 --> Middleware1 Middleware1 --> DNS1 end subgraph Tencent[腾讯云（备）] CLB[CLB] UI2[UI 层] Service2[Service 层] Middleware2[中间件（私有化） Redis Proxy / MySQL Proxy ELK / Kafka / Memcache] DNS2[私有化 CoreDNS 服务发现 + 跨云] CLB --> UI2 --> Service2 --> Middleware2 Middleware2 --> DNS2 end subgraph CrossCloud[跨云专线 10-20ms] direction LR DNS1 <--> DNS2 end subgraph SharedMiddleware[共用中间件] MNS1[MNS] KafkaShared[Kafka] RedisMaster[Redis（主）] RedisSlave[Redis（从）] end Middleware1 --> SharedMiddleware Middleware2 --> SharedMiddleware

3. 流量分发层（ESA）

3.1 分流策略

ESA 作为流量入口，承担核心的路由决策职责：

维度	说明
分流因子	`userid`（用户级粘性）+ 请求接口路径
分流粒度	接口级（不同接口可配置不同比例）
动态调整	支持百分比灰度，例如 A 接口 10%→腾讯云，90%→阿里云
全量切流	通过 ESA 配置快速开关，一键将某云流量切至另一云

3.2 容灾切换实战

在一次线上故障中，腾讯云 RedisProxy 崩溃导致 APP 瘫痪，运维团队通过 ESA 快速开关将腾讯云所有接口流量全量切至阿里云：

切换耗时：从配置修改到生产恢复约 15 秒
切换方式：目前为手动改 ESA 配置，未来将演进为自动健康检查触发

3.3 ESA 稳定性保障

ESA 作为阿里云成熟边缘产品，故障概率极低，且具备边缘化部署特性，本身不引入额外单点风险。

4. 各云内部架构

4.1 负载均衡层

云厂商	负载均衡产品
阿里云	ALB（应用型负载均衡）
腾讯云	CLB（云负载均衡）

4.2 应用层

UI 层：各自云独立部署前端应用
Service 层：各自云独立部署后端微服务，通过私有化 CoreDNS 进行服务发现

4.3 中间件层（各自云独立部署）

中间件	用途
Redis Proxy	缓存型 Redis 代理，各自云独立
MySQL Proxy	数据库代理，连接 OceanBase（主从架构）
Kafka	消息队列，各自云独立 Topic
ELK	日志采集与分析，各自云独立
Memcache	分布式缓存，各自云独立

5. 服务发现（私有化 CoreDNS）

5.1 部署模式

每个云厂商独立部署一套私有化 CoreDNS，实现：

本云服务解析：阿里云 CoreDNS 解析阿里云内网服务 IP
跨云服务解析：腾讯云 CoreDNS 可解析阿里云内网 IP（通过专线访问）

5.2 跨云解析示例

# 腾讯云 CoreDNS 配置示例
# 存储型 Redis（主）→ 阿里云内网 IP
redis.internal  →  172.16.10.100
 
# 缓存型 Redis（各自云独立）
redis-cache.internal → 10.0.20.50

5.3 解析策略

服务类型	解析目标	访问方式
存储型 Redis（主）	阿里云内网 IP	跨云专线
缓存型 Redis	本云内网 IP	本云内网
跨云访问延迟	—	约 10-20ms

6. 数据层设计

6.1 OceanBase 主从架构

角色	部署位置	职责
主库	阿里云	处理所有写请求 + 部分读请求
从库	腾讯云	仅处理读请求

关键参数：

同步延迟：< 1 秒
腾讯云以读为主，无写操作
跨云读延迟：10-20ms（可接受）
后续优化：逐步将读流量本地化

6.2 Redis 双策略

类型	部署方式	一致性方案
存储型 Redis	阿里云单主	腾讯云通过专线访问
缓存型 Redis	各自云独立部署	各自云内网访问

6.3 Redis 延迟双删

适用场景：允许短暂数据不一致的缓存数据
强一致性场景：降级为缓存型数据，避免双删带来的不一致窗口
并发风险：第二次删除前如有读请求可能读到旧数据，通过业务容忍度评估后采用

6.4 共用中间件（跨云专线传输）

中间件	部署模式	用途
MNS	共用	消息通知服务
Kafka	共用 Topic	跨云消息流转
Redis（主）	阿里云为主	存储型数据访问

7. 跨云专线

7.1 专线用途

传输共用中间件流量（MNS、Kafka、存储型 Redis）
支持腾讯云 Service 访问阿里云存储型 Redis
支持 OceanBase 主从同步

7.2 延迟表现

访问场景	延迟
本云内网访问	< 1ms
跨云专线访问	10-20ms
OceanBase 主从同步	< 1s

7.3 优化方向

将跨云读流量逐步迁移至本云，降低专线依赖
热点数据双云缓存，减少跨云穿透

8. 可观测性

8.1 链路追踪

LogID：业务层生成，贯穿全链路
EdgeID：ESA 边缘节点生成，标识边缘请求
通过 LogID + EdgeID 组合，实现跨云全链路追踪

8.2 日志体系

云厂商	日志平台	采集方式
阿里云	ELK（自建）	Filebeat → Kafka → Logstash → ES
腾讯云	ELK（自建）	Filebeat → Kafka → Logstash → ES

8.3 监控指标

各云服务健康检查（HTTP/HTTPS 探活）
跨云专线延迟与丢包率
OceanBase 主从同步延迟
ESA 各接口流量分布实时监控

9. 容灾切换机制

9.1 当前方案（手动切换）

运维人员发现故障（监控告警或用户反馈）
登录 ESA 控制台修改分流配置
将故障云流量全量切至健康云
恢复时间：约 15 秒

9.2 未来演进（自动切换）

接入健康检查探针，自动检测各云核心服务可用性
检测到故障后，自动调用 ESA API 修改分流配置
切换完成后自动发送告警通知

10. 踩坑与经验总结

问题	根因	解决方案
RedisProxy 崩溃导致 APP 瘫痪	腾讯云 RedisProxy 服务异常	ESA 15 秒切流至阿里云恢复

11. 未来优化方向

自动切流：基于健康检查实现故障自动切换，将恢复时间从 15 秒缩短至秒级
读流量本地化：将腾讯云读请求逐步迁移至本云 Redis/MySQL，降低跨云专线依赖
多活演进：从目前的「主备模式」向「双活模式」演进，提升资源利用率
统一控制面：建设多云统一管理平台，可视化展示流量分布、健康状态、切流操作