爆发式增长业务的高可用架构优化之路
爆发式增长业务的高可用架构优化之路 邓学祥 0 1 目录0 爆发式增长业务的稳定性挑战 Content 爆发式增长业务的稳定性应对之道 2 s0异地多活—交易单元化技术架构 3 0降爆炸半径—自研ServiceMesh实现去中心化网关 4 主题 爆发式增长业务的稳定性挑战 01 SUBJECT 中间件及基础设施庞大业务架构复杂X因素多 Infrastructure规模大中间件复杂 业务子系统多 下游二方/三方依赖多 变更引发的故障非变更引发的故障 基础设施 业务系统 HSFMetaq Tair分布式数据库 中间件 日志服务容灾 盘古存储 AliOs 监控服务 调度 容器 洛神网络神龙架构 云操作系统 云资源 面向失败设计，单点故障可能是常态，机房级故障较少，对业务系统挑战高 主备切换抖动延时， 中间件bug，中间件故障 单容器故障 K8S调度故障，K8S升级故障 单机故障，单块硬盘故障机房故障，机房网络故障 request ApiGateway MicroService1.1 MicroService1.2 MicroService1.3 MicroService1.4 MicroService1.5 MicroService1.6 MicroService2.1 MicroService2.2 MicroService2.3 MicroService2.4 MicroService3.1 MicroService3.2 MicroService3.3 MicroService3.4 MicroService3.5 MicroService3.6 •系统的自我保护，防止被上游异常大流量打死 •下游的超时保护，防止被下游拖死 •区分强弱依赖，可降级依赖 •防止重试风暴，多级重试是叉乘关系 •复杂系统链路较长，定位问题可能变得困难 •二方/三方系统故障，RT变长，成功率下降等 •上游请求量暴增 •下游失败的后的上游重试 •上游非法请求，安全攻击等 •链路上的上下游变更故障 变更类故障省略 时间类变化 证书到期服务到期 账户余额变化 故障类别 非变更类故障 其实本质也是变化 消耗类值变化 量变引起质变 库存类变化 自增id超int最大值，变long类型 数据量级变化 非生产环境变更 ...... 因素太多，无法穷举 主题 爆发式增长业务的稳定性应对之道 02 SUBJECT 事前防范未然，事中快速发现，事后快速恢复 灰度发布 灰度平台 灰度引流 灰度diff 压测计划 压测平台 压测引流语料 自动报告 代码扫描 质量平台 测试覆盖率 质量评分 故障演练 资损熔断演练 支付渠道故障 预案降级故障 风险故障 事前 数据库连接/超时故障 Redis连接/超时故障 混沌工程 单机服务故障RT延迟故障三方故障注入 水位自动巡检 qps水位播报 存储水位播报 应用水位播报 全链路追踪 变更归因 故障归因 全链路日志 逆向监控 风险视图 报警通知 逆向校验 数据处理 数据采集 监控大盘 天级大盘 分业务大盘 整体大盘 业务监控告警 风险监控 业务监控 用反监控 舆情监控 用反监控 事中 预案平台 预案执行 降级预案 风险预案关联 机房切流 单元化管控平台 单元化监控 单元化中间件 单元化切流 资损熔断 熔断处置决策 聚类异常发现 统一数据流 支付渠道自动切换 支付渠道上下线 支付渠道下线决策 支付渠道监控 外部依赖管控平台 自动下线 外部依赖监控 限流管控平台 限流调整 限流监控 事后 流量染色&识别，中间件根据环境标定位环境 上线前灰度环境做引流验证 通过环境标实现流量精细化管控，支持白名单、百分比等灰度流量控制 灵活，不需要全链路都有灰度环境。 压测自动化：常态化压测，压测提效 人工收集压测语料，压测case 手工执行压测准备，手工切流，手工检查 压测过程中收集数据，手工生成保告 线上引流录制，自动收集压测语料 VS一键压测，自动完成切流等压测准备，自动检查 自动收集servercpu等信息，自动生成压测保告。历史报告对比。 线上真实流量回归验证，流量录制回放 对业务代码的侵入性尽可能少 录制不影响线上性能 串联一起请求的所有调用 主流： •Ebpf录制+服务回放(回放+Mock) 选择： •中间件录制(服务本身承载录制+Mock) 正逆向校验，双重保障 专注于资损bug发现，避免资损。 信息流、订单流、资金流三流对比。跨系统数据比对校验。发现隐藏的系统bug。 校验规则使用Faas来实现，可插拨扩展。快速上线新的逆向校验规则 对线上系统保持敬畏 稳定性NO.1法则 主题 异地多活—单元化技术架构 •自研Go中间件单元化技术方案 •单元化落地过程中的高级坑 •高可用与单元化成本的平衡取舍 03 SUBJECT •问题：核心业务依赖机房，无法抵抗地域级、机房级故障，无法做到真正的容灾 •目标：建设一种通用的机房级异地容灾架构，让业务具备异地容灾（单元化），故障快速恢复的能力 •方案选型： •同城双活 •伪双活的单边架构 •主库机房出问题依然会影响全量业务，灾备切换时间较长 •依然受地域资源限制和重大自然灾害影响，比如地震、电力限制 •异地冷备 •纯冷备，资源严重浪费 •日常不跑流量，不敢切流 •即使切流，没有任何预热也很难扛住 •异地多活，单元封闭✅ •数据单元内闭合，读写均走当前单元，需保证分区数据的一致性 •并非所有服务都做单元化改造，只需核心链路服务做高可用单元化改造 •主要挑战 •距离导致的网络时延是物理限制，不可能突破 •多次跨地域的调用会严重影响服务RT，导致用户体验严重下降 •网络时延对数据一致性是巨大挑战，要写业务多活更是难上加难 异地多活，单元封闭 单元划分模式： •Unit：即所有读写流量在单元内完成，有异常不会影响其他单元。随时切流✅ •Copy：读流量走单元服务，写流量走中心服务。单元切流无异常，中心服务出问题，整体都会出问题 单元化纬度： •买家纬度单元化 • • • • 单元化 单元封闭 核心链路内最多只有一次纠偏统一单元化管控 单元化切流压测，实现压测提效 • • • 自研Go中间件实现单元化路由方案。 服务具备单元化纠偏路由能力。数据层中间件TDDL具备单元化禁写能力。 统一单元化管控规则 单元A 中心单元C 单元B 系统庞大链路复杂：(解决：内圈向外推动) •上下游链路较为复杂，架构由核心内部服务向外扩充推动单元化 •只有必须的服务才进行单元化改造，平衡改造成本 强中心化服务，例如库存服务，如何做到单元封 闭：(解决：按单元做业务划拨) •例如按单元划拨库存，某单元无库存后，从其他单元再划拨 单元化后，压测链路是否影响：(解决：流量染 色，支持单元化切流压测) •业务无感，业务代码基本无改造，中间件层面支持，升级SDK Sequence冲突：：(解决：单元Group Sequence，各单元使用自己的Sequence号段) •单元化后，Sequnce号段浪费，按单元化比例分配sequence号段 双向同步 单元 商品id 单元库存 单元A 1001 200 单元B 1001 300 中心单元C 1001 500 扣库存 双向同步 单元 商品id 单元库存 单元A 1001 200 单元B 1001 300 中心单元C 1001 500 扣库存 单元 商品id 单元库存 单元A 1001 200 单元B 1001 300 中心单元C 1001 500 扣库存 ALTERTABLE`tb1`MODIFYCOLUMN`column1`intunsignedNULL; --原表column1是tinyint类型，变更为int类型 --非单元化之前执行过类似变更，没有问题，单元化之后，执行此变更，引起锁表，连接数爆涨，业务不可用的故障 无锁变更简述步骤： 1.创建临时表：CREATETABLEA`LIKEA。并变更结构ALTERTABLEA`XXXX。 2.全量拷贝数据：INSERTIGNOREINTOA ` (SELECT%sFROMAFORCEINDEX(%s)WHE RExxx。 3.增量数据Binlog同 步：UPDATE/INSERT/DELETEA`。 4.切换新旧表：RENAMETABLEA`toA。 单元化数据库执行无锁变更有丢数据风险 所以对于单元化数据库，使用的是原生mysql变更而原生Mysql字段类型变更会锁表 •基于成本考虑，平时两单元 •两单元都扛流量，没有资源浪费，并且相比冷备随时可切 •大促态扩到多单元，多机房扛 量，一键部署 大促扩单元 主题 SUBJECT 降爆炸半径—自研ServiceMesh实现去中心化网关 •ServiceMesh基础设施建设 •ServiceMesh业务落地方案 04 QPS飞速增长接口量迅速增长 业务增速 OnServiceMesh VS OnSDK 易为瓶颈&成本&效率 风险 高德特点 底层引擎多语言、多框架，对跨语言/跨框架诉求强 透明升级，无侵入业务， 让业务开发回归业务，为业务提效 云原生架构升级 稳定性 提效 去中心化 隔离 降本 落地 解题 采用Mecha的ServiceMesh落地 南北流量&边缘节点 •可以通过类似Envoy的数据面来管理 •未来自研LeapMesh(异构语言VM- >Filter),由边缘工具->Gateway->Ingress •可通过部署类似Dapr的Sidecar进行通讯 （MultiRuntime工具集合） 东西流量 多语言访问中间件方案： 内聚在业务中的中间件访问，可下沉到Sidecar中 • • • 新技术应用遵从稳定性三板斧：可灰度、可监控、可回滚 支持按用户白名单，百分比控制灰度 从非核心应用开始切换，逐步成熟之后再应用到核心应用。 可回滚 可灰度 可监控
