物流场景下的架构稳定性实践
如果无法正常显示,请先停止浏览器的去广告插件。
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.