物流场景下的架构稳定性实践

如果无法正常显示,请先停止浏览器的去广告插件。
分享至:
1. 物流场景下的架构稳定性实践 卢旭 北京顺丰同城科技丨架构师
2.
3. 讲师介绍 • 卢旭丨北京顺丰同城科技-架构师 • 2013年,毕业于北京邮电大学(硕士)。 • 2013年04月,入职百度LBS事业部,参与旅游服务端开发。 • 2016年03月,入职百度外卖基础架构组,负责基础服务类的研 发、维护。 • 2017年10月,入职顺丰同城基础架构组,先后负责策略架构方 向、智慧供应链方向、基础架构方向、科技中心,近期专注于 业务架构的稳定性以及微服务治理等领域。
4. • 关于我们 – 业务及架构演进 • 系统稳定性理论 • 基于微服务架构的稳定性体系建设 • 618、双十一实战经验 • 总结&展望
5. 关于我们 快递物流 Express Delivery 实时预警 动态任务分配 收派能力监控 订单协防调度 风险预测 SOP管控及时干预 快递网点 电商仓 KA仓 固定资源-速运、快运、国际 弹性资源-同城、星管家、落地配 业务智能诊断 资源前置规划 收/寄件人 供应链物流 供应链计划 OMS 仓网规划 需求预测 库存计划 响应供应 WMS 集散点 供应链科技解决方案 仓内精细化运营管理 SMART 供应链执行 Supply Chain 模型预估价值 劳动定价差异化 资源投入智能评估 任务合理分配 TMS 门店 城配物流 In-city logistics 团餐外卖 商务宴请 技术中台 科技底盘 Technology 食堂用餐 开发框架: • JIE • PIE • GMP 通用能力: • 中间件 • 基础服务 • 人工智能 大前端: • SOFA • Hybrid • 热修复 企业福利 门店/电商 Devops流水线 大数据: • 离线仓库 • 实时计算 • 业务赋能 代码扫描 -> 安全扫描 -> 自动化测试 构建 -> 预发环境 -> 生产环境 -> 发布 即时配送 智能化运维 可观测性: • Log • metric • trace 服务治理: • 降级 • 限流 • 熔断 消费者 基础资源 智能探索: • 异常检测 • 混沌工程 顺丰云 公有云
6. 关于我们 JAVA:微服务 PHP:单体应用
7. 关于我们 场景复杂: ToB + ToC 物流行业: 偏传统行业 物流行业,双十一、618 流程复杂性(收、转、运、派) 高并发(万+QPS) 标准化建设周期长,历史债务多 大数据量(过亿数据) 核心是小哥+设备,实操场景多 安全性要求高 系统交互:上下游多 顺丰科技系统 大客户系统(能力参差不齐) 依赖服务多,链路复杂 稳定性挑战: • 满足ToB、ToC场景的稳定性要求 • 兼容异构系统的稳定性保证 • 应对周期性流量高峰 定制化 大客户同频 语言栈异构: JAVA + PHP + GO 异构系统 链路复杂 工作量 > 1 JAVA起步较晚
8. • 关于我们 – 业务及架构演进 • 系统稳定性理论 • 基于微服务架构的稳定性体系建设 • 618、双十一实战经验 • 总结&展望
9. 稳定性理论 开发 多活 分布式追踪 规范 测 数据库规范 压测保障 日 析 分 志 监控告 警 考核标准 检索 依 弱 强 理 梳 赖 设计评审 稳定 冗余 段 手 试 标 目 性 预 台 平 案 Code review 熔断 、降 根因定位 级、 限流 架构优化
10. 稳定性理论 人+规范: 业务 开发规范、测试规范、上线规范、 运维规范等 框架封装 标准能力: 基础工具+平台 工具+平台: 机房环境(高可用方案) 服务治理:熔断、限流、降级 预防、发现、定位、止损、复盘 机房部署架构: 同城、异地、多活、灰度、蓝绿 稳定性目标 SLA:99.97% MTTR:25min
11. • 关于我们 – 业务及架构演进 • 系统稳定性理论 • 基于微服务架构的稳定性体系建设 • 618、双十一实战经验 • 总结&展望
12. 稳定性体系 – 提前预防,精准定位,快速止损 事前 故障前(事前): 故障预防、灾备预 故障后(事后): 故障复盘、 高可用架构 机房环境 全链路压测 改进;目标是尽可能多的从故障 自动化测试 预案&混沌工程 巡检机制 案;目标是尽可能做足准备工作,做到有 备无患。 中吸取教训,反思和学习,完善 和修复故障中暴露出来的问题。 预防 事后 事中 运营体系 复盘 故障 生命周期 发现 监控、告警 事中 事中 事件平台 链路追踪 止损 定位 根因定位 日志平台 故障中(事中): 发现、定位、解决故障;目标是尽可能提高效率,缩短故障恢复的时间(MTTR)。
13. 稳定性体系 – 机房:高可用架构 选了什么: 遇到的问题: • 异地双机房 • 业务开始全国推广,稳定性有了更高要求 • 同城双机房双活 • Sh机房机器过保,面临服务迁移 • 异地多活 做了什么: • 流量(sf naming service): 按照机房tag路由 支持跨机房tag降级 • 数据库: 读写分离(读双活、写主节点) 集群支持高可用切换 • 分布式服务: 三中心高可用架构
14. 稳定性体系 – 机房:高可用架构 分布式服务:消息队列SFMQ 做了什么: • 仲裁节点(zk): 三机房高可用部署 • Broker设置: broker数量从单机房3台调整为每个机房不少于2台 borker根据机房添加rack信息,保证每个topic在每 个机房内至少有一个副本 • Topic设置: topic的副本数调整为4,在producer ack=all情况下 满足单机房故障的高可用 • 生产、消费设置: 优先生产/消费同机房partition 我们的收益: • 单节点、单机房broker异常情况下,集群的整体可用
15. 稳定性体系 – 机房:高可用架构 大数据: GZ3 在线/离线分离 读写分离 GZ6
16. 稳定性体系 – 机房:部署环境 机房环境:保证高可用性的多套机房环境 Mirror 生产 • 上线回归 • 暂停点、全量 • 线上环境一部分 • 无损发布 • 流量闭环 • 多机房部署 UAT 灰度 • 预演环境 • 发布过程,小流量环境 • 客户验收环境 • 标准化灰度流程 • 与线上完全隔离 • 流量闭环
17. 稳定性体系 – 链路:线上全链路压测 面临的问题: • 稳定性压力:系统出问题频率增加,需要进 难点: • 行性能探底,暴露瓶颈; • • 流量隔离:不干扰线上真实流量,区分真实 流量进行监控、统计; 成本压力:压测依赖线下1:1mock环境,机 • 数据隔离:不污染线上真实数据; 器、人力成本巨大; • 快速止损:完备的监控能力,紧急停止能 业务压力:多系统联动压测(语言栈、框架 差异)。 力,快速恢复能力;
18. 稳定性体系 – 链路:线上全链路压测 目标: • 常态化压测需求; • 系统容量评估依据; 技术方案: • 流量隔离(框架+中间件改 造); • 数据隔离:影子库/表; • 组件:vegeta/goreplay 支持场景: • 常规压测; • 流量录制/回放; 实践: • 超5业务线完成高峰压测; • 链路管控能力。 JIE Agent
19. 稳定性体系 – 链路:线上自动化测试 面临的问题: • ToB业务,流程多,客制化严重,且逻辑细节分支多。底层改动影响范围难确定,手工测试执行慢,且覆盖不全。 目标: • 支持研发提测准入、测试快速回 归、上线系统卡点、线上定时巡检 的全流程覆盖。 技术方案: • 依赖全链路压测技术能力 • Httprunner + jenkins 实践: • 核心服务(P0 case覆盖 90%, P1 case覆盖 60%+); • 流水线打通。
20. 稳定性体系 – 链路:预案演练平台 面临的问题: • 资源的不确定性:网络、机器、依赖等; • 系统的不确定性:架构、逻辑漏洞等; • 预案的不确定性:弱依赖的降级、兜底预案等; • 统一工具平台:各中心都在做类似的事情,缺少统一工具平台。 目标: • 以攻代守、通过注入有限可控的故障,提前发现系统的风险点; • 评估系统可靠性,提供降级策略、参数调整的优化依据; • 输出标准可执行的线上应急预案。 技术方案: • 基于开源chaosblade故障注入工具; • 预案演练(业务强沟通) -> 红蓝对抗(常态化); • 打通公司内部各个资源管理和监控观测系统等。
21. 稳定性体系 – 链路:预案平台 架构实现: 预案系统 + 作业平台 + 执行系统。 故障类型: 机器 + 资源 + 三方依赖。 故障分类 故障描述 系统预期 机器 宕机 探活机制+负载均衡 进程强杀 探活机制+负载均衡 文件删改 请求报错 CPU打满 探活机制+负载均衡 内存打满 探活机制+负载均衡 网络丢包 自动重试+报警 网络延迟 自动重试+报警 mysql从库异常 探活机制+负载均衡 mysql主库异常 高科用切主 Tidb节点异常 分布式系统无影响 单机房故障 机房流量切换 资源 数据库 机房
22. 稳定性体系 – 监控 我们各阶段监控的需求/问题: 初期建设阶段: 业务精细化阶段: 智能化阶段: • 基础资源监控覆盖率; • 业务自定义指标监控; • 报警阈值不能一概而论; • 基础资源监控开箱即用、业务解 • 多维日志监控; • 报警有效性; 耦; • 大客户个性化监控: • 异常情况监测(流量为0 • 业务日志监控。 大客户单量只占大盘一小部分 大客户关注点不同 等)
23. 稳定性体系 – 监控 目标: • 构建一套从用户端到服务端,从底层网 络到上层业务的全面监控体系,支持业 务的快速发展。 技术方案: • 监控1.0: 基于openfalcon快速上线 • 监控2.0: 基于prometheus的服务自监控 完成,基于flink的多维日志方案 • 监控3.0: AIOPS探索。 实践: • 资源监控 • 服务自监控 • 任务维度监控 • 异常监控
24. 稳定性体系 – 监控 基于prometheus服务自监控 基于资源维度监控 基于任务维度监控 基于异常检测监控
25. 稳定性体系 – 监控:链路追踪 问题: 目标: • 异构系统端到端问题诊断难; • 系统间依赖梳理、端到端问题诊断; • 系统间依赖复杂,梳理难度大。 • 向上赋能业务,辅助业务快速问题决策; • 向下与基础设施可观测联动,提前发现资源风险。 技术方案: • 基于开源的jaeger方案,打造公司的 trace生态; • 系统框架、组件集成,评估性能损 耗。
26. 稳定性体系 – 监控:可观测性 可观测性 = Log + metric + trace 目标: • 基于otel规范,统一log、metric、trace的采集方 案; • 关联log、metric、trace指标,可以在一个页面切换 相关的指标、日志和trace数据,提升问题定位的效 率。
27. 稳定性体系 监控 Log、metric、trace 链路 可观测性 提升问题召回率 链路容量、性能 机房 链路的不确定性 链路强管控 - 稳定性的基础 机房架构 - 同城、异地、多活 部署环境 – uat、灰度、生产 匹配业务和技术 稳定性
28. • 关于我们 – 业务及架构演进 • 系统稳定性理论 • 基于微服务架构的稳定性体系建设 • 618、双十一实战经验 • 总结&展望
29. 双十一 & 618实战 差异 共性 • 618 &双十一是对系统稳 • 定性的一次“技术阅 兵”; • • 目标是推进稳定性的体系 • 显; • 需要我们常态化的机制保 障、立体化的工具支撑; 流量分布:流量突增明 难点 问题影响:高峰期问题影 高; • 响严重(灾难性); • 时间紧、任务重、风险 目标容量的不确定性,需 要系统更强的健壮性; 应对周期:周期短,且业 • 预案精细化; 务快速迭代。 • 更快速止损。 化建设。 日常建设技术,高峰规范流程!
30. 双十一 & 618实战 :建流程 业务目标 • 方案梳理 目标拆解: 根据业务目标确定系统 目标; • 制定流程: 根据系统目标进行方案 裁剪; 容量规划 线上扩容 系统压测 • 故障演练 系统压测: 根据系统目标,进行线上压测, 探查系统瓶颈; • 服务扩容: 依据压测数据进行服务扩容; • 故障演练: 以攻代守,发现系统隐患; 定目标 节前排查 探瓶颈 • 应急预案 排查: 高峰值班 • 管控: 监控完善、降级方 24小时值班; 案、系统资源等; • 应急预案: 封线,紧急上线流 程; 各类应急预案梳 理,快速恢复; 降风险 复盘总结 问题记录; • 故障复盘 强管控
31. 双十一 & 618实战:建规范 资源排查: 值班: 管控: • 机器资源瓶颈; • 24小时值班流程; • 高峰期间封线; • 机房流量负载均衡; • 作战会议室; • 紧急上线需要审批机制等; • 监控报警完善; • 关注业务流量、监控大盘; • 数据库备份容灾能力等; • 做好问题记录; 应急预案梳理: 问题跟进: • 封禁流量封堵机制; • 报警认领率超80%; • 入口流量限速; • 故障解决时效:5min, • 业务熔断配置; • 机房流量异常切换等 10min,25min;
32. 双十一 & 618实战 10倍+单量增长、5倍+流量增长、0线上故障…
33. 双十一 & 618实战 稳定性体系,有效保障高峰应对 稳定性 体系 高峰应 对 高峰应对,有效推进稳定性体系建设 预案平台 全链路压测平台 自动化扩容平台
34. • 关于我们 – 业务及架构演进 • 系统稳定性理论 • 基于微服务架构的稳定性体系建设 • 618、双十一实战经验 • 总结&展望
35. 总结&展望 服务 治理 可观 测性 服务 部署 service mesh落地: • • 解耦基础组件升级和 otel规范落地: 业务开发 • • trace的采集方案 解决多语言栈的成本 及稳定性目标 内部平台集成istio管 理能力 统一log、metric、 • 提高问题定位、恢复 效率 • 跨云多活
36.
37.

trang chủ - Wiki
Copyright © 2011-2024 iteam. Current version is 2.137.1. UTC+08:00, 2024-11-11 14:43
浙ICP备14020137号-1 $bản đồ khách truy cập$