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

如果无法正常显示，请先停止浏览器的去广告插件。

1. 爆发式增长业务的高可用架构优化之路邓学祥

3. 目录 Content s 0 1 0 2 0 3 0 4 爆发式增长业务的稳定性挑战爆发式增长业务的稳定性应对之道异地多活—交易单元化技术架构降爆炸半径—自研Service Mesh实现去中心化网关

4. 主题 SUBJEC T 爆发式增长业务的稳定性挑战 01

5. 稳定性挑战中间件及基础设施庞大业务架构复杂 X因素多 Infrastructure 规模大中间件复杂业务子系统多下游二方/三方依赖多变更引发的故障非变更引发的故障

6. 基础设施挑战面向失败设计，单点故障可能是常态，机房级故障较少，对业务系统挑战高业务系统主备切换 HSF Metaq Tair 分布式数据库日志服务容灾监控服务调度容器盘古存储洛神网络 AliOs 神龙架构中间件抖动延时，中间件bug，中间件故障云操作系统云资源单容器故障 K8S调度故障，K8S升级故障单机故障，单块硬盘故障机房故障，机房网络故障

7. 业务架构挑战 • 复杂系统链路较长，定位问题可能变得困难 request • 二方/三方系统故障，RT变长，成功率下降等 • 上游请求量暴增 Api Gateway • 下游失败的后的上游重试 • 上游非法请求，安全攻击等 Micro Service1.1 Micro Service1.2 Micro Service2.1 Micro Service1.3 Micro Service2.2 Micro Service1.4 Micro Service2.3 Micro Service1.5 Micro Service1.6 Micro Service2.4 • 链路上的上下游变更故障 • 系统的自我保护，防止被上游异常大流量打死 • 下游的超时保护，防止被下游拖死 • 区分强弱依赖，可降级依赖 Micro Service3.1 Micro Service3.2 Micro Service3.3 Micro Service3.4 Micro Service3.5 Micro Service3.6 • 防止重试风暴，多级重试是叉乘关系

8. X因素挑战变更类故障省略证书到期时间类变化服务到期账户余额变化消耗类值变化故障类别库存类变化非变更类故障自增id超int最大值，变 long类型其实本质也是变化量变引起质变数据量级变化非生产环境变更 ...... 因素太多，无法穷举

9. 主题 SUBJEC T 爆发式增长业务的稳定性应对之道 02

10. 稳定性之道事前防范未然，事中快速发现，事后快速恢复灰度平台灰度发布压测平台灰度引流事前灰度diff 压测计划质量平台压测引流语料自动报告代码扫描故障演练资损熔断演练支付渠道故障事中数据处理预案降级故障逆向校验数据库连接/超时故障风险故障故障归因报警通知风险视图业务监控变更归因事后聚类异常发现单元化中间件水位自动巡检风险监控应用水位播报存储水位播报分业务大盘熔断处置决策外部依赖监控自动下线天级大盘限流监控限流调整用反监控舆情监控支付渠道自动切换支付渠道监控限流管控平台单元化监控 qps水位播报用反监控外部依赖管控平台单元化管控平台单元化切流整体大盘三方故障注入 RT延迟故障单机服务故障监控大盘资损熔断统一数据流 Redis连接/超时故障业务监控告警全链路追踪全链路日志质量评分混沌工程逆向监控数据采集测试覆盖率支付渠道下线决策支付渠道上下线预案平台降级预案预案执行风险预案关联机房切流

11. 灰度平台流量染色&识别，中间件根据环境标定位环境  上线前灰度环境做引流验证  通过环境标实现流量精细化管控，支持白名单、百分比等灰度流量控制  灵活，不需要全链路都有灰度环境。

12. 压测平台压测自动化：常态化压测，压测提效  人工收集压测语料，压测case  手工执行压测准备，手工切流，手工检查  压测过程中收集数据，手工生成保告  线上引流录制，自动收集压测语料 VS  一键压测，自动完成切流等压测准备，自动检查  自动收集server cpu等信息，自动生成压测保告。历史报告对比。

13. 引流回放平台线上真实流量回归验证，流量录制回放  对业务代码的侵入性尽可能少  录制不影响线上性能  串联一起请求的所有调用主流： • Ebpf录制 + 服务回放(回放 + Mock) 选择： • 中间件录制 (服务本身承载录制+Mock)

14. 逆向监控正逆向校验，双重保障  专注于资损bug发现，避免资损。  信息流、订单流、资金流三流对比。跨系统数据比对校验。发现隐藏的系统bug。  校验规则使用Faas来实现，可插拨扩展。快速上线新的逆向校验规则

15. 对线上系统保持敬畏稳定性NO.1法则

16. 主题 SUBJEC T 异地多活—单元化技术架构 • • • 自研Go中间件单元化技术方案单元化落地过程中的高级坑高可用与单元化成本的平衡取舍 03

17. 单元化架构背景 • 问题：核心业务依赖机房，无法抵抗地域级、机房级故障，无法做到真正的容灾 • 目标：建设一种通用的机房级异地容灾架构，让业务具备异地容灾（单元化），故障快速恢复的能力 • 方案选型： • 同城双活 • 伪双活的单边架构 • 主库机房出问题依然会影响全量业务，灾备切换时间较长 • 依然受地域资源限制和重大自然灾害影响，比如地震、电力限制 • 异地冷备 • 纯冷备，资源严重浪费 • 日常不跑流量，不敢切流 • 即使切流，没有任何预热也很难扛住 • 异地多活，单元封闭✅ • 数据单元内闭合，读写均走当前单元，需保证分区数据的一致性 • 并非所有服务都做单元化改造，只需核心链路服务做高可用单元化改造 • 主要挑战 • 距离导致的网络时延是物理限制，不可能突破 • 多次跨地域的调用会严重影响服务RT，导致用户体验严重下降 • 网络时延对数据一致性是巨大挑战，要写业务多活更是难上加难

18. 异地多活单元化架构异地多活，单元封闭单元划分模式： • Unit：即所有读写流量在单元内完成，有异常不会影响其他单元。随时切流 ✅ • Copy：读流量走单元服务，写流量走中心服务。单元切流无异常，中心服务出问题，整体都会出问题单元化纬度： • 买家纬度单元化单元化 • • • • 单元封闭核心链路内最多只有一次纠偏统一单元化管控单元化切流压测，实现压测提效

19. 中间件单元化方案 • 自研Go中间件实现单元化路由方案。 • 服务具备单元化纠偏路由能力。数据层中间件TDDL具备单元化禁写能力。 • 统一单元化管控规则

20. 单元化遇到的问题系统庞大链路复杂：( 解决：内圈向外推动) • 上下游链路较为复杂，架构由核心内部服务向外扩充推动单元化单元A 扣库存单元库存 200 300 500 商品id 1001 1001 1001 单元库存 200 300 500 商品id 1001 1001 1001 单元库存 200 300 500 强中心化服务，例如库存服务，如何做到单元封闭： ( 解决：按单元做业务划拨) 中心单元C • 例如按单元划拨库存，某单元无库存后，从其他单元再划拨单元化后，压测链路是否影响： ( 解决：流量染色，支持单元化切流压测) 扣库存单元单元A 单元B 中心单元C • 业务无感，业务代码基本无改造，中间件层面支持，升级SDK 单元B Sequence冲突：： ( 解决：单元Group Sequence，各单元使用自己的Sequence号段) • 单元化后，Sequnce号段浪费，按单元化比例分配sequence号段扣库存单元单元A 单元B 中心单元C 商品id 1001 1001 1001 • 只有必须的服务才进行单元化改造，平衡改造成本单元单元A 单元B 中心单元C

21. 单元化遇到的高级坑 ALTER TABLE `tb1` MODIFY COLUMN `column1` int unsigned NULL; --原表column1是tinyint类型，变更为int类型 --非单元化之前执行过类似变更，没有问题，单元化之后，执行此变更，引起锁表，连接数爆涨，业务不可用的故障无锁变更简述步骤： 1. 创建临时表：CREATE TABLE A` LIKE A。并变更结构 ALTER TABLE A` XXXX。 2. 全量拷贝数据：INSERT IGNORE INTO A ` (SELECT %s FROM A FORCE INDEX (%s) WHE RE xxx。 3. 增量数据Binlog同步： UPDATE/INSERT/DELETE A`。 4. 切换新旧表： RENAME TABLE A` to A。单元化数据库执行无锁变更有丢数据风险所以对于单元化数据库，使用的是原生mysql变更而原生Mysql字段类型变更会锁表

22. 高可用与单元化成本取舍 • 基于成本考虑，平时两单元 • 两单元都扛流量，没有资源浪费，并且相比冷备随时可切 • 大促态扩到多单元，多机房扛量，一键部署大促扩单元

23. 主题 SUBJEC T 降爆炸半径—自研Service Mesh实现去中心化网关 • • Service Mesh基础设施建设 Service Mesh业务落地方案 04

24. Service Mesh降爆炸半径云原生架构升级 QPS 接口量飞速增长迅速增长稳定性解题风险提效去中心化隔离降本业务增速易为瓶颈 & 成本 & 效率高德特点 On ServiceMesh VS On SDK 底层引擎多语言、多框架，对跨语言/跨框架诉求强透明升级，无侵入业务，让业务开发回归业务，为业务提效落地采用Mecha的Service Mesh落地

25. Service Mesh架构南北流量& 边缘节点 • 可以通过类似Envoy的数据面来管理 • 未来自研Leap Mesh ( 异构语言VM- >Filter ),由边缘工具->Gateway->Ingress 东西流量 • 可通过部署类似Dapr的 Sidecar进行通讯（Multi Runtime 工具集合）多语言访问中间件方案：内聚在业务中的中间件访问，可下沉到Sidecar中

26. Service Mesh业务落地可回滚可监控 • 新技术应用遵从稳定性三板斧：可灰度、可监控、可回滚 • 支持按用户白名单，百分比控制灰度 • 从非核心应用开始切换，逐步成熟之后再应用到核心应用。可灰度

27.