您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[阿里巴巴]:2024年阿里巴巴安全生产体系建设最佳实践报告 - 发现报告
当前位置:首页/其他报告/报告详情/

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

2024-12-30谢吉宝(唐三)阿里巴巴D***
2024年阿里巴巴安全生产体系建设最佳实践报告

阿里巴巴安全生产体系建设最佳实践 谢吉宝(唐三) 阿里云智能资深技术专家、云原生中间件&SRE负责人、前阿里集团容灾架构负责人 阿里巴巴核心电商的架构演进 2003 2004-2008 2008–至今 2013–至今 2015–至今 1.初创阶段 2.单体应用阶段 3.分布式应用阶段 4.单元化阶段 5.云化阶段 •业务问题 •规模、性能 •规模、效率 •规模、扩展 •规模、成本 每一次架构演进都是为了解决当下或者未来要发生的问题 安全生产体系的建设 面向失败的架构设计 解决确定性的架构设计问题 面向精细化的运维管控 解决不确定性的运维管控问题 面向风险的应急处置 解决不确定性风险事件 架构设计原则变更执行原则应急处理原则 容错可灰度 容量可观测 容灾可回滚 1分钟发现 5分钟响应 10分钟恢复 混沌工程容灾演练红蓝攻防生产突袭 容量–全链路压测&限流 压测链路拓扑 压测指标大盘 性能瓶颈分析 容量规划验证 压测报告 压测Grafana大盘 性能基线对比 全景快照 容量评估验证 压测执行 施压机监控大盘 请求采样日志 ARMS-TraceExplore ARMS-Insight诊断 压测引擎打标 压测引擎日志采集 ARMS-调用链 Streaming统一处理 压测准备 压测配置性能基线管理脚本调试 ARMS 链路拓扑 ARMS 应用列表 ARMS 接口调用 ARMS 数据库调用 Prometheus容器 PrometheusIaaS 容错–混沌工程 容灾-异地多活架构 中心单元 业务单元1业务单元N 中心应用 单元应用 单元应用 全量买家数据 (RW) 本单元买家数据 (RW) ··· 本单元买家数据 (RW) 全面卖家数据 (RW) 全量卖家数据 (RO) 全量卖家数据 (RO) 容灾-异地多活架构 移动/PC 业务单元1 中心单元 业务单元2 统一入口网关 微服务、消息 统一入口网关微服务、消息数据层 业务单元3 业务单元N 数据层 中心服务 2 容灾问题 爆炸半径确定、秒级切换 3 意外收获 成为技术创新的实验田 4 成本问题 通Serverless来降低成本 中心单元 业务单元2 统一入口网关 业务单元N 微服务、消息 数据层 业务单元3 中心服务 单元化发展历程 •2013:杭州同城两个POC验证 •2014:杭州、上海近距离两个单元 •2015:千里之外的三地四单元架构 •2016:三地五单元混合云 •2017:三地七单元混部混合云 •2018:多维度单元化 •… 1 容量问题 站点级弹性、一键建站、快上快下 容灾-异地多活架构 容灾-异地多活架构 云原生网关(双可用部署) 50% 50% 微服务层 微服务A 微服务层 微服务A 微服务B 微服务B 写 读写 数据库层 读 数据库层 主库 备库 核心优势 稳定: SLA承诺高于99.95%,多可用区容灾、推空保护、过载保护、配置热更新 安全: 信通院最高安全评级,控制面数据面分离,从根本上避免安全漏洞,内置WAF、黑白名单、JWT/OIDC/IDAAS/自定义等多种认证鉴权 性能: 深度调优、软硬一体、比开源自建性能高于90% 成本: 三合一网关,Serverless版最高比自建成本低75% 易用: 免运维,使用效率比自建提升10倍以上高度集成13款云产品、开箱即用, 容开源NginxIngress、支持平滑迁移 容灾-异地多活架构 技术架构 北京 杭州 生产应用 生产应用 写 消息打标 写 阿里云企业网 写 写 云消息队列RocketMQ版实例A Conector 异步复制 Conector 云消息队列RocketMQ版实例B 读读 读 读 消息打标 消费应用 消费应用 消息的跨区域容灾,全球消息备份能力助力业务构建异地灾备、异地多活架构 核心优势 低代码开发: 实例间的同步可以通过全球消息备份来实现,降低消息同步的代码开发工作量。 配置灵活: 可配置实例间单向/双向的消息数据同步,完成灾备,双活系统架构建设。并可由系统完成消息数据的打标,方便业务侧灵活的选择数据处理的范围 跨地域低延时同步: 消息数据的同步能力技术选型采用事件总线EventBridge产品,高压力下全球同步延迟 秒级,稳定性,弹性有保障 容灾-异地多活架构 微服务后,节点数量庞大,容灾切换效率问题,怎么解决? 云原生网关 注册配置中心(三可用区部署) 50% 微服务层 微服务A 50% 微服务层 微服务A 服务发现 微服务领域 故障转移 流量控制 微服务B 微服务B 紧急预案 高可用领域 降级开关 容灾配置 数据库层 数据库层 数据库领域 主备切换 动态数据源 分片规则 主库 备库 核心优势 稳定: 三可用区部署、SLA承诺高于99.95%优雅上下线、推空保护、风险管理。 安全: 信通院最高安全评级,支持访问、传输、存储,构建全链路安全防护体系 性能: 基于Dragonwell构建,内核参数深度调优,比开源性能高50%。 成本: 成本比开源自建低75% 易用: 免运维、效率比自建提升10倍以上 兼容开源NACOS/ZK/EUREKA、平滑迁移推送轨迹、观测分析开箱即用 容灾-异地多活架构 01轻标准02重管控 1 不支持容灾 2 异地冷备 3 同城双活 4 异地多读 5 异地多活 •业务全链路监控、全息监控 •单元管控平台 •巡检 •故障快恢平台 A RTO<=10min&RPO<=10min B 10min<RTO<=30min&10min<RPO <=30min C RTO>30min&RPO>30min X 完全不具备恢复能力 03常演练 •混沌工程常态化 •断网、断电演练定期化 •容灾大考标准化 •生产突袭 变更三板斧–可观测 1、根据业务价值设计自上而下的监控系统,明确应用系统中更有价值的部分,优先业务监控,应用监控、资源监控依次向下推进 2、需要回答客户几个问题:出问题了吗?哪里出问题了?是什么问题?提升用户体验洞察及故障定位能力3、最后考虑可观测架构设计(metrics、tracing、logging)和开源可观测组件、云厂商产品的选型 Prometheus ARMS+SLS 业务监控 应用调用链应用性能 业务核心指标,如:订单数量、订单金额、日活、月活、投保人数及其它业务指标… 服务调用全景、RT、TPS、Exception、慢sql、MQ、自 Redis上 JVM堆内存、GC、Thread,Method性能..而 +Grafana 应用日志业务日志、应用日志、异常日志下设 容器CaaS层 POD内存、CPU、健康度(Running、Pending、Failed)、计 集群资源监控、核心组件、运行事件… IaaS/PaaS层 CPU、内存、网络、磁盘、TCP、Load… 微服务治理控制面 云原生网关 userId:99 userId:[00,98] 应用集群 变更态服务治理 灰度版本 正式版本 同步灰度 消息灰度 微服务A agent 微服务A agent 定时任务灰度 无损上/下线 gray 运行态稳定性治理 gray 微服务B agent 限流 熔断 安全 自愈 微服务C agent 微服务B agent 变更三板斧–可灰度(可回滚) 核心优势 无侵入: 5分钟完成接入,不改变现有架构,现有代码 高性能: CPU<5%,内存<200m,RT增加<1ms 安全可靠: 支持通过全链路TLS、服务鉴权构建全链路零信任安全防护体系 简单易用: 支持Go/Java,免运维、效率提升5倍以上全链路灰度、无损上下线、限流熔断等能 力开箱即用 面对失败设计 凡是可能出错的事必定会出错 李艳林(彦林)阿里十年双十一老司机 2024/12 导航 •风险分析&解决思路 •全链路灰度 •限流降级熔断 •动态配置精准容灾 •预案快恢 •MSE面对失败设计 •混沌工程 •铭师堂最佳实践 线上风险分析&解决思路 开发测试态(测试左移) 变更态(三板斧-可灰度) 运⾏态(1-5-10快恢) 服务契约 ⽆损下线 ⽆损上线 不确定流量 全链路TLS 服务测试 单应⽤灰度 全链路灰度 不稳定调⽤ 服务鉴权 端云互联 后端灰度 前端灰度 不稳定基础设施 微服务可信 开发环境隔离 消息灰度 异步任务灰度 应⽤⾃身故障 配置安全 配置灰度 据调研数据70%的线上问题都是由于变更导致的,除应⽤本身问题外,运⾏时⻛险概括为:不确定流量、不稳定调⽤、不稳定基础设施。 解决90%稳定性⻛险 解决70%稳定性⻛险 提升60%开发效率 全链路灰度(变更风险无法避免,控制爆炸半径) Base流量Gray流量 ARMS 观测灰度 SchedulerX 任务灰度 客户端网关层 Android iOS userid:120 userid:100 gray 网关 base ABC gray A Agent gray C gray A Agent base grayAgent TopicA(gray) Agent H5 BC base Agent Message Message base base gray Message TopicA(base) 静态文件 静态文件 SQL92 filter Message Nacos(前端/配置灰度) RocketMQ(消息灰度) 全链路灰度观测体系(让风险无处藏身) 在做新版本灰度发布的时,可以方便地通过修改规则来限定能访问新版本的流量,比如限制只有内部用户才能使用新版本,充分验证后再进行全量发布,从而保证新版本发布时的稳定性。 限流&降级&熔断(运行风险发生快速恢复) 流量入口 后端应用 超容容量之内 服务A 服务B 服务C 服务D 风险分类 上游应用 流量的不确定性 用户案例 业务突然爆发,系统却频频崩溃,错失业务爆发的大好机会。 筹备了重大活动,系统却因为流量激增不可用,活动热度未能完成业务转化。 下游依赖 其它服务 DB 缓存数据库 服务D 下游应用 不稳定调用 APP的购买页/搜索页依赖推荐算法,算法服务不稳定时,页面完全不可用。 个人主页由于查询积分慢SQL导致DB连接池满,应用整体不可用。 流量防护(防止突发流量打垮业务) 业务场景/痛点 场景一(突发流量):活动场景,某个时刻激增的脉冲流量到达系统(抢购/秒杀/活动),系统被打挂不能正常提供服务,导致活动热度不能转换成有效流量。 解决方式 配置接口维度流控规则,通过容量范围内的请求,拒绝多余的请求,相当于安全气囊的作用。 层层防护,在网关层进行粗粒度防护,在应用层进行API、接口、方法、参数维度细粒度流量控制。 效果:系统正常提供服务、保障业务成功率 热点数据流控(防止热点流量击穿业务) 业务场景/痛点 热点流量场景:大促活动中涌现一批“黑马”热点商品,事先无法准确预知热点商品。这些突发的热点流量会击穿缓存,将DB打挂,影响了正常流量的业务处理。 商品P 商品A商品B商品C 商品Q 解决方式 Redis集群 DB集群 通过热点参数防护能力,自动识别参数中的TopN访问热度的参数值,并对这些参数分别进行统计与流控,避免单个热点访问过载;并且可以针对一些特殊热点访问 (如极热门的抢购单品)配置单独的流控值。 参数可以是任意业务属性,可以来自调用端IP、RPC参数、HTTP请求参数、header等,也支持自定义。 商品P 商品A商品B商品C Client端热点流控, 针对自动识别的热点key分别控制 Redis集群 DB集群 商品Q 进程内部并发隔离(运行时软保险,避免级联故障) 业务场景/痛点 场景一:某系统对外提供某查询接口,内部涉及数据库调用,SQL语句涉及多表join,某些情况下会触发慢查询,耗时长达30s,虽然QPS不大,但是请求还是越积越多,最终导致DB连接池/Tomcat线程池满,应用

你可能感兴趣

hot

五色石伙伴计划暨内生安全自主知识体系建设蓝皮书(2024年)

文化传媒
嵩山山实验室&紫金山实验室&复旦大学大数据研究院2024-12-09
hot

阿里巴巴-赵中州-通义AIGC-传媒领域下内容生产到消费的全链路技术实践

文化传媒
2023第十二届全球TOP100软件案例研究峰会2024-08-21