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

如果无法正常显示，请先停止浏览器的去广告插件。

1. 物流场景下的架构稳定性实践卢旭北京顺丰同城科技丨架构师

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.