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

邓学祥 爆发式增长业务的稳定性挑战 目录 爆发式增长业务的稳定性应对之道 异地多活—交易单元化技术架构 降爆炸半径—自研Service Mesh实现去中心化网关 爆发式增长业务的稳定性挑战01 稳定性挑战 中间件及基础设施庞大Infrastructure 规模大中间件复杂 业务架构复杂 X因素多 变更引发的故障非变更引发的故障 业务子系统多下游二方/三方依赖多 基础设施挑战 业务架构挑战 •复杂系统链路较长，定位问题可能变得困难 •二方/三方系统故障，RT变长，成功率下降等•上游请求量暴增•下游失败的后的上游重试•上游非法请求，安全攻击等•链路上的上下游变更故障 •系统的自我保护，防止被上游异常大流量打死•下游的超时保护，防止被下游拖死•区分强弱依赖，可降级依赖•防止重试风暴，多级重试是叉乘关系 X因素挑战 爆发式增长业务的稳定性应对之道02 稳定性之道 事前防范未然，事中快速发现，事后快速恢复 灰度平台 流量染色&识别，中间件根据环境标定位环境 上线前灰度环境做引流验证通过环境标实现流量精细化管控，支持白名单、百分比等灰度流量控制灵活，不需要全链路都有灰度环境。 压测平台 压测自动化：常态化压测，压测提效 线上引流录制，自动收集压测语料一键压测，自动完成切流等压测准备，自动检查自动收集server cpu等信息，自动生成压测保告。历史报告对比。 人工收集压测语料，压测case手工执行压测准备，手工切流，手工检查压测过程中收集数据，手工生成保告 引流回放平台 线上真实流量回归验证，流量录制回放 对业务代码的侵入性尽可能少录制不影响线上性能串联一起请求的所有调用 选择：•中间件录制 (服务本身承载录制+Mock) 逆向监控 正逆向校验，双重保障 专注于资损bug发现，避免资损。信息流、订单流、资金流三流对比。跨系统数据比对校验。发现隐藏的系统bug。校验规则使用Faas来实现，可插拨扩展。快速上线新的逆向校验规则 对线上系统保持敬畏 稳定性NO.1法则 主题SUBJEC 异地多活—单元化技术架构 •自研Go中间件单元化技术方案•单元化落地过程中的高级坑•高可用与单元化成本的平衡取舍 03 单元化架构背景 •问题：核心业务依赖机房，无法抵抗地域级、机房级故障，无法做到真正的容灾•目标：建设一种通用的机房级异地容灾架构，让业务具备异地容灾（单元化） ，故障快速恢复的能力•方案选型： •同城双活 •伪双活的单边架构•主库机房出问题依然会影响全量业务，灾备切换时间较长•依然受地域资源限制和重大自然灾害影响，比如地震、电力限制 •异地冷备 •纯冷备，资源严重浪费•日常不跑流量，不敢切流•即使切流，没有任何预热也很难扛住 •数据单元内闭合，读写均走当前单元，需保证分区数据的一致性•并非所有服务都做单元化改造，只需核心链路服务做高可用单元化改造 •主要挑战 •距离导致的网络时延是物理限制，不可能突破•多次跨地域的调用会严重影响服务RT，导致用户体验严重下降•网络时延对数据一致性是巨大挑战，要写业务多活更是难上加难 异地多活单元化架构 单元划分模式：•Unit：即所有读写流量在单元内完成，有异常不会影响 其他单元。随时切流✅•Copy：读流量走单元服务，写流量走中心服务。 单元切流无异常，中心服务出问题，整体都会出问题 单元化纬度：•买家纬度单元化 单元化 •单元封闭•核心链路内最多只有一次纠偏•统一单元化管控•单元化切流压测，实现压测提效 中间件单元化方案 •自研Go中间件实现单元化路由方案。•服务具备单元化纠偏路由能力。数据层中间件TDDL具备单元化禁写能力。•统一单元化管控规则 单元化遇到的问题 系统庞大链路复杂：( 解决：内圈向外推动) •上下游链路较为复杂，架构由核心内部服务向外扩充推动单元化•只有必须的服务才进行单元化改造，平衡改造成本 强中心化服务，例如库存服务，如何做到单元封闭： ( 解决：按单元做业务划拨)•例如按单元划拨库存，某单元无库存后，从其他单元再划拨 单元化遇到的高级坑 ALTER TABLE `tb1`MODIFY COLUMN `column1` int unsigned NULL;--原表column1是tinyint类型，变更为int类型--非单元化之前执行过类似变更，没有问题，单元化之后，执行此变更，引起锁表，连接数爆涨，业务不可用的故障 无锁变更简述步骤： 1. 创建临时表：CREATE TABLEA`LIKE A。并变更结构 ALTER TABLEA`XXXX。2. 全量拷贝数据：INSERT IGNORE INTOA`(SELECT %s FROM A FORCE INDEX (%s) WHERE xxx。3. 增量数据Binlog同步： UPDATE/INSERT/DELETE A`。4. 切换新旧表： RENAME TABLE A` to A。 单元化数据库执行无锁变更有丢数据风险所以对于单元化数据库，使用的是原生mysql变更而原生Mysql字段类型变更会锁表 高可用与单元化成本取舍 •基于成本考虑，平时两单元•两单元都扛流量，没有资源浪费，并且相比冷备随时可切•大促态扩到多单元，多机房扛量，一键部署 主题SUBJEC 降爆炸半径—自研Service Mesh实现去中心化网关•Service Mesh基础设施建设•Service Mesh业务落地方案 04 Service Mesh降爆炸半径 Service Mesh架构 南北流量&边缘节点 •可以通过类似Envoy的数据面来管理•未来自研Leap Mesh (异构语言VM->Filter ),由边缘工具->Gateway->Ingress 东西流量 •可通过部署类似Dapr的Sidecar进行通讯（Multi Runtime 工具集合） 多语言访问中间件方案： 内聚在业务中的中间件访问，可下沉到Sidecar中 Service Mesh业务落地 •新技术应用遵从稳定性三板斧：可灰度、可监控、可回滚•支持按用户白名单，百分比控制灰度•从非核心应用开始切换，逐步成熟之后再应用到核心应用。