2024年阿里巴巴安全生产体系建设最佳实践报告

阿里巴巴安全生产体系建设最佳实践 谢 吉 宝（唐 三） 阿里云智能资深技术专家、云原生中间件&SRE负责人、前阿里集团容灾架构负责人 阿里巴巴核心电商的架构演进 容错–混沌工程 容灾-异地多活架构 单 元 化 发 展 历 程 •2013：杭州同城两个POC验证•2014：杭州、上海近距离两个单元•2015：千里之外的三地四单元架构•2016：三地五单元混合云•2017：三地七单元混部混合云•2018：多维度单元化•… 容 量 问 题站点级弹性、一键建站、快上快下 1 2 容 灾 问 题爆炸半径确定、秒级切换 意 外 收 获成为技术创新的实验田 3 成 本 问 题通Serverless来降低成本 容灾-异地多活架构 核 心 优 势 稳定：SLA承诺高于99.95%，多可用区容灾、推空保护、过载保护、配置热更新安全：信通院最高安全评级，控制面数据面分离，从根本上避免安全漏洞，内置WAF、黑白名单、JWT/OIDC/IDAAS/自定义等多种认证鉴权性能：深度调优、软硬一体、比开源自建性能高于90%成本：三合一网关，Serverless版最高比自建成本低75%易用：免运维，使用效率比自建提升10倍以上高度集成13款云产品、开箱即用，容开源Nginx Ingress、支持平滑迁移 容灾-异地多活架构 消息的跨区域容灾，全球消息备份能力助力业务构建异地灾备、异地多活架构 核 心 优 势 低代码开发：实例间的同步可以通过全球消息备份来实现，降低消息同步的代码开发工作量。 配置灵活： 可配置实例间单向/双向的消息数据同步，完成灾备，双活系统架构建设。并可由系统完成消息数据的打标，方便业务侧灵活的选择数据处理的范围 消息数据的同步能力技术选型采用事件总线EventBridge产品，高压力下全球同步延迟秒级，稳定性，弹性有保障 容灾-异地多活架构 微服务后，节点数量庞大，容灾切换效率问题，怎么解决？ 核 心 优 势 注册配置中心（三可用区部署） 稳定：三可用区部署、SLA承诺高于99.95%优雅上下线、推空保护、风险管理。安全：信通院最高安全评级，支持访问、传输、存储，构建全链路安全防护体系性能：基于Dragonwell构建，内核参数深度调优，比开源性能高50%。成本：成本比开源自建低75%易用：免运维、效率比自建提升10倍以上兼容开源NACOS/ZK/EUREKA、平滑迁移推送轨迹、观测分析开箱即用 容灾-异地多活架构 重 管 控02 轻 标 准01 •业务全链路监控、全息监控•单元管控平台•巡检•故障快恢平台 常 演 练03 •混沌工程常态化•断网、断电演练定期化•容灾大考标准化•生产突袭 变更三板斧–可观测 1、根据业务价值设计自上而下的监控系统，明确应用系统中更有价值的部分，优先业务监控，应用监控、资源监控依次向下推进2、需要回答客户几个问题：出问题了吗？哪里出问题了？是什么问题？提升用户体验洞察及故障定位能力3、最后考虑可观测架构设计（metrics、tracing、logging）和开源可观测组件、云厂商产品的选型 变更三板斧–可灰度（可回滚） 核 心 优 势 无侵入：5分钟完成接入，不改变现有架构，现有代码高性能：CPU<5%，内存<200m，RT增加< 1ms安全可靠：支持通过全链路TLS、服务鉴权构建全链路零信任安全防护体系简单易用：支持Go / Java，免运维、效率提升5倍以上全链路灰度、无损上下线、限流熔断等能力开箱即用 面对失败设计 凡是可能出错的事必定会出错 李 艳 林 （ 彦 林 ）阿 里 十 年 双 十 一 老 司 机 2024/12 导航 •风险分析&解决思路•全链路灰度•限流降级熔断•动态配置精准容灾•预案快恢•MSE面对失败设计•混沌工程•铭师堂最佳实践 服务测试 端云互联 据调研数据70%的线上问题都是由于变更导致的，除应⽤本身问题外，运⾏时⻛险概括为：不确定流量、不稳定调⽤、不稳定基础设施。 全链路灰度观测体系（让风险无处藏身） 在做新版本灰度发布的时，可以方便地通过修改规则来限定能访问新版本的流量，比如限制只有内部用户才能使用新版本，充分验证后再进行全量发布，从而保证新版本发布时的稳定性。 限流&降级&熔断（运行风险发生快速恢复） 筹备了重大活动，系统却因为流量激增不可用，活动热度未能完成业务转化。 流量防护（防止突发流量打垮业务） 业务场景/痛点 场景一（突发流量）：活动场景，某个时刻激增的脉冲流量到达系统（抢购/秒杀/活动），系统被打挂不能正常提供服务，导致活动热度不能转换成有效流量。 解决方式 配置接口维度流控规则，通过容量范围内的请求，拒绝多余的请求，相当于安全气囊的作用。 层层防护，在网关层进行粗粒度防护，在应用层进行API、接口、方法、参数维度细粒度流量控制。 效果：系统正常提供服务、保障业务成功率 热点数据流控（防止热点流量击穿业务） 业务场景/痛点 热点流量场景：大促活动中涌现一批“黑马”热点商品，事先无法准确预知热点商品。这些突发的热点流量会击穿缓存，将DB打挂，影响了正常流量的业务处理。 解决方式 通过热点参数防护能力，自动识别参数中的TopN访问热度的参数值，并对这些参数分别进行统计与流控，避免单个热点访问过载；并且可以针对一些特殊热点访问（如极热门的抢购单品）配置单独的流控值。 参数可以是任意业务属性，可以来自调用端IP、RPC参数、HTTP请求参数、header等，也支持自定义。 进程内部并发隔离（运行时软保险，避免级联故障） 业务场景/痛点 场景一：某系统对外提供某查询接口，内部涉及数据库调用，SQL语句涉及多表join，某些情况下会触发慢查询，耗时长达30s，虽然QPS不大，但是请求还是越积越多，最终导致DB连接池/Tomcat线程池满，应用整体不可用。 场景二：应用依赖的下游支付服务因网络抖动出现大量慢调用，导致该应用的线程池全部被该服务调用占满，无法处理正常业务流程。 解决方式 结合并发隔离能力，给重要服务/接口调用配置并发线程数限制，相当于一道“软保险”，防止不稳定调用占满线程池、过多挤占正常服务资源，避免级联故障。 并发：在途请求数（开始处理但未完成的请求） 并发隔离是保障运行时常态化稳定性的核心手段 下游依赖降级（熔断非核心接口，保护重点业务） 业务场景/痛点 业务高峰期，某些非核心的下游服务接口遇到性能瓶颈或网络问题，影响业务主流程运转，且可能需要较长时间恢复。小问题变成大问题。 解决方式 事前配置熔断规则，当满足熔断条件时自动触发熔断，直接返回fallback的结果，这样既可以保障调用端不被不稳定服务拖垮，又可以给不稳定下游服务一些“喘息”的时间，保障整个业务链路的正常运转。 同时仍需配合客户端超时、重试等配置，并且需要关注熔断后的fallback返回行为，确保业务体验。 熔断是保障运行时常态化稳定性、避免级联故障的重要手段，但仅适用于非核心接口。 阿里双十一预案体系（大促自动化和高可用的底气） MSE微服务引擎容错设计 数据面+控制面+存储架构分离，多级缓存，数据备份，运行弱依赖，常态故障演练 强弱依赖•数据面弱依赖控制面，数据缓存 •控制面弱依赖存储，全量缓存 •推空保护•数据多副本•数据定期备份 •前端灰度•按照Region/GC/版本灰度 铭师堂高可用架构 MSE钉钉交流群（43525005207） 产品入口：https://www.aliyun.com/product/aliware/mse