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

s01020304爆发式增长业务的稳定性挑战爆发式增长业务的稳定性应对之道异地多活—交易单元化技术架构降爆炸半径—自研ServiceMesh实现去中心化网关SUBJECT爆发式增长业务的稳定性挑战01业务子系统多下游二方/三方依赖多业务子系统多下游二方/三方依赖多X因素多变更引发的故障非变更引发的故障机房级故障较少，对业务系统挑战高基础设施机房级故障较少，对业务系统挑战高基础设施K8S调度故障，K8S升级故障云操作系统Tair分布式数据库requestApiGatewayService1.1Service3.1Service1.2Service2.1Service3.2Service1.3Service2.2Service3.3ServiceService1.4Service1.5Service2.3Service3.4Service2.4Service3.5Service1.6Service3.6••复杂系统链路较长，定位问题可能变得困难•二方/三方系统故障，RT变长，成功率下降等••系统的自我保护，防止被上游异常大流量打死X因素挑战变更类故障变更类故障故障类别非变更类故障消耗类值变化故障类别非变更类故障消耗类值变化其实本质也是变化量变引起质变非生产环境变更......其实本质也是变化量变引起质变非生产环境变更......证书到期证书到期服务到期服务到期账户余额变化账户余额变化库存类变化库存类变化数据量级变化数据量级变化SUBJECT爆发式增长业务的稳定性应对之道02支付渠道故障资损熔断演练支付渠道故障资损熔断演练代码扫描测试覆盖率质量评分质量平台压测平台压测计划压测引流语料单机服务故障RT延迟故障三方故障注入混沌工程数据库连接/超外部依赖监控外部依赖管控平台支付渠道自动切换支付渠道监控支付渠道下线决策支付渠道上下线单元化切流单元化中间件单元化监控单元化管控平台限流管控平台代码扫描测试覆盖率质量评分质量平台压测平台压测计划压测引流语料单机服务故障RT延迟故障三方故障注入混沌工程数据库连接/超外部依赖监控外部依赖管控平台支付渠道自动切换支付渠道监控支付渠道下线决策支付渠道上下线单元化切流单元化中间件单元化监控单元化管控平台限流管控平台灰度发布灰度发布灰度平台灰度引流灰度引流故障演练预案降级故障预案降级故障风险故障风险故障数据采集数据采集数据处理数据处理逆向监控逆向校验逆向校验报警通知报警通知风险视图风险视图业务监控告警应用水位播报应用水位播报水位自动巡检qpsqps水位播报风险监控业务监控风险监控业务监控存储水位播报存储水位播报事中全链路日志全链路日志全链路追踪变更归因整体大盘监控大盘天级大盘用反监控用反监控舆情监控故障归因故障归因分业务大盘分业务大盘资损熔断统一数据流统一数据流聚类异常发现聚类异常发现熔断处置决策熔断处置决策预案平台预案执行预案执行风险预案关联风险预案关联机房切流机房切流上线前灰度环境做引流验证通过环境标实现流量精细化管控，支持白名单、百分比等灰度流量控制灵活，不需要全链路都有灰度环境。人工收集压测语料，压测case手工执行压测准备，手工切流，手工检查压测过程中收集数据，手工生成保告VS线上引流录制，自动收集压测语料自动收集servercpu等信息，自动生成压测保告。历史报告对比。线上真实流量回归验证，流量录制回放对业务代码的侵入性尽可能少录制不影响线上性能串联一起请求的所有调用信息流、订单流、资金流三流对比。跨系统数据校验规则使用Faas来实现，可插拨扩展。快速上对线上系统保持敬畏SUBJECT异地多活—单元化技术架构•自研Go中间件单元化技术方案•单元化落地过程中的高级坑•高可用与单元化成本的平衡取舍03•问题：核心业务依赖机房，无法抵抗地域级、机房级故障，无法做到真正的容灾•目标：建设一种通用的机房级异地容灾架构，让业务具备异地容灾（单元化故障快速恢复的能力•异地多活，单元封闭•距离导致的网络时延是物理限制，不可能突破•多次跨地域的调用会严重影响服务RT，导致用户体验严重下降•网络时延对数据一致性是巨大挑战，要写业务多活更是难上加难异地多活单元化架构异地多活，单元封闭•Unit：即所有读写流量在单元内完成，有异常不会影响其他单元。随时切流•Copy：读流量走单元服务，写流量走中心服务。单元切流无异常，中心服务出问题，整体都会出问题•买家纬度单元化•核心链路内最多只有一次纠偏•统一单元化管控•单元化切流压测，实现压测提效•服务具备单元化纠偏路由能力。数据层中间件TDDL具系统庞大链路复杂：系统庞大链路复杂：(解决：内圈向外推动)•上下游链路较为复杂，架构由核心内部服务向外扩充推动单元化•只有必须的服务才进行单元化改造，平衡改造成本强中心化服务，例如库存服务，如何做到单元封闭：(解决：按单元做业务划拨)•例如按单元划拨库存，某单元无库存后，从其他单元再划拨单元化后，压测链路是否影响：(解决：流量染色，支持单元化切流压测)•业务无感，业务代码基本无改造，中间件层面支持，升级SDKSequence冲突(解决：单元GroupSequence，各单元使用自己的Sequence号段)•单元化后，Sequnce号段浪费，按单元化比例分配sequence号段单元库存1001200单元B1001300中心单元C1001500扣库存双向同步双向同步双向同步扣库存扣库存单元库存1001200单元B1001300中心单元C1001500扣库存单元B扣库存单元库存1001200单元B1001300中心单元C1001500--原表column1是tinyint类型，变更为in--非单元化之前执行过类似变更，没有问题，单元化之后，执行此变更，引起锁表，连接数爆涨，业务不可用的故障1.创建临时表：CREATETABLEA`LIKEA。并变更结构ALTERTABLEA`XXXX。`(SELECT%sFROMAFORCEINDEX(%s)WHERExxx。步：UPDATE/INSERT/DELETEA`。4.切换新旧表：RENAMETABLEA`toA。单元化数据库执行无锁变更有丢数据风险所以对于单元化数据库，使用的是原生mysql变更而原生Mysql字段类型变更会锁表高可用与单元化成本取舍•两单元都扛流量，没有资源浪•大促态扩到多单元，多机房扛SUBJECT降爆炸半径—自研ServiceMesh实现去中心化网关•ServiceMesh基础设施建设•ServiceMesh业务落地方案04QPS接口量飞速增长迅速增长解题解题云原生架构升级性去中心化OnOnServiceMesh采用Mecha的Service底层引擎多语言、多框架，对跨语采用Mecha的ServiceSS让业务开发回归业务，为业务提效•可以通过类似Envoy的数据面来管理>Filter),由边