为了30分钟配送,盒马工程师都有哪些“神操作”?
阿里妹导读:提到盒马鲜生,除了新鲜的大龙虾以外,大家印象最深的就是快速配送:门店附近3公里范围内,30分钟送货上门。
盒马是基于规模化和业务复杂度两个交织,从IT到DT,从原产地到消费者而形成的端到端的平台,而盒马配送更是集成IOT、智能化、自动化等到线下作业,同时受不可抗力因素雨雪冰雾、道路交通、小区设施等让配送系统的稳定性更加雪上加霜,如何保障线下配送作业的稳定性,让骑手快乐,更让用户开心是盒马配送永恒的话题。
三大规范
整个盒马技术部对线上/线下作业生产之关注,代码质量之高、故障处理之严,让我们工程师在反复反复地肯定自己的同时又不断地否定自己,在开发中设计重构系统,在生产之中检验系统。经过线上/线下冰与火的历练,我们淬炼出了一套稳定性的方法论,概括起来就12个字:研发规范、架构规范、稳定性规范。
无规矩,无以成方圆
首先是研发规范,且看下图:
这个图管它叫做7层漏斗模型(努力画出漏斗,画图功夫不行,浅色的箭头表示漏斗),7层是指PRD评审、技术方案评审、TC评审、编码、测试&代码Review、灰度发布、运维。为什么是漏斗模型呢?因为我们通过这7层经过层层筛选,将阻碍线下流程的重大故障全部在这7层兜住。
PRD评审:我们有个需求池,所有的需求都先扔到这个池子里面,每两周有个运营双周会,从中筛选出优先级高、紧急程度高的需求开始进行PRD评审(倒排项目除外),所有的PRD评审都有PD组织,从项目或者需求的价值认识上达成一致,在评审的过程中研发同学从PRD中寻找名词进行领域建模和抽象。整个需求和项目需要识别到技术风险,遵循“不被别人搞死、不搞死别人”的原则,识别核心链路和非核心链路;测试同学从中识别风险点和测试功能点,为后面TC评审做好准备。
技术方案评审:PM组织研发、测试和PD总共参与,研发同学按照事先分配好的研发模块进行技术串讲,同时和PD、甚至电话业务同学共同达成产品兜底方案和业务兜底方案。人都会犯错,何况是人写出来的代码,我们要拥抱bug,但更要识别到潜在的风险进行兜底。
TC评审:一般在技术评审完成后的两天内会进行TC评审,主要功能的覆盖点、技术方案潜在的坑、非功能角度的业务降级方案、性能的QPSRT、接口的可测性的评估、测试环境、测试数据等,最后给出可靠的上线时间。
编码:首先遵循集团的编码规则,然后就是防御性编程,业务系统可能80%的代码都在考虑异常情况下如何保证高可用。系统异常、业务异常的处理,上线时门店灰度方案(一个门店出问题,不影响整个盒马门店),缓存机制、柔性可用、重试机制、事务处理、串并行、打日志等等。
测试&代码Review:首先研发完成自测并冒烟通过,正式提测,当然在编码的过程中也会进行代码Review,那时的代码Review管它叫线上Review,通过Aone的功能提交给相关同学进行Review;整个测试结束后上线前我们会聚集到一起进行代码围观Review,这个阶段也会完成系统依赖顺序、发布顺序、回滚顺序,每个人的位置。
灰度发布:首先我们严格遵守盒马研发红线,按照发布窗口进行发布,同时为了将风险降到最低,针对不同的业务做不同的发布时间点,比如O2O场景下午2点准时发布,B2C场景晚上8点半准时点火;针对不同的门店进行灰度,发布完成后就立马通过SLS查看原始错误日志,A3查看错误统计日志,EagleEye查看QPS/RT,CloudDBA查看DB性能/慢SQL等全面盯屏30分钟以上。一般我们觉得风险比较大的,在发布时会只发2台机器,第二天观察没有任何问题再全部上线,如果有问题就直接上去Kill掉这两台机器。
运维:每次发布后第二天早起盯屏是非常关键,尤其是配送涉及不同运力商、运力类型等作业的校验方式不同,在早上运力类型丰富是最容易出问题,也最容易发现问题。一旦有问题,谁先第一个发现先问题就会立马在群里钉钉电话所有人,若是跨团队的会单独拉小群电话所有人,对于问题的定位我们设置专门的同学,有人看SLS,有人看EagleEye,有人看A3,有人看Xflush,有人看CloudDBA,有人对外发声安抚骑手,一个人统一指挥,大家分工明确,整个问题处理起来就像一个人。
不把鸡蛋放在一个篮子
盒马配送目前有50+系统,其中核心应用有20+,那么这么多系统如何既保稳定又能协作?且看下图:
项目化:盒马配送从刚开始按照项目维度构建整个系统,能够满足盒马用户的个性化需求,这种在人少的情况下开发起来很快,也能快速的迭代。
产品化:随着业务需求越来越多,这种开发方式越来越拖慢整个项目节奏,尤其是需求的灵活多变,这个时候产品化的方式随之而来,我们在去年5月份的引入了NBF的规则中心、各种Setup,将运营逻辑和业务逻辑区别开来等各种配置化,快速支持需求的变化。
服务化:去年8月份的时候和点我达、邻趣、蜂鸟等三方进行对接,对接的过程比较痛苦,我们发现业务逻辑主要是在盒马场景下,三方的场景需要做一些定制,这个时候我们开始考虑整个线下作业不变业务规则和基于场景的业务规则,将不变业务规则下沉作为我们的后台,基于场景的业务规则放到我们的中台,形成后台解释业务概念、业务状态和业务规则,中台做统一权限校验、场景化的业务逻辑、数据网关、整个降级限流可以上浮到中台来,完成对各运力商的流控,慢慢孵化出上面的架构规范。这一过程比较痛苦,我们既要追赶业务,又把34个核心的L0服务梳理业务逻辑、接口参数的合理性、外部依赖等重新升级一遍,新老服务平滑迁移对业务无感,最后注册到NBF上,通过NBF链接起所需的各域能力去表达业务。
数字化:最底下一层是我们的用工管理平台,新零售从企业角度看有两个核心层面,其一是技术层面“人货场”的数字化;其二是零售层面的“人货场”的变革或者革命;用技术驱动零售变革,让我们真正能看到整个线下作业流程的好与坏,哪些门店好,哪些门店差,原因到底在哪里,如何去优化提供技术依据和支撑,整个数据模型如下图:
纸上得来终觉浅
任何理论、架构都要不断接受实践的检验,在错误中学习,在错误中成长,提出了一套适合线下配送的7路23招打法,如下图:
第一路:核心和非核心隔离
首先我们从应用维度进行核心和非核心隔离,核心服务和非核心服务隔离,从数据库层面我们做了核心库和非核心库隔离,读写分离、充分发挥各存储层的优势,比如核心作业场景我们采用Mysql,实时聚合分析场景我们采用ADS,非核心多维度组合查询场景我们引入OpenSearch、和离线场景的ODPS,这样既起到分流的作用,又保护了核心作业场景。如此架构升级,可以让我们的上嘉同学进来在一些非核心场景上独挡一面,充分发挥他们的潜力。
系统交互上我们采用基于Request/Response模式的HSF水平调用;另外一种基于Event-driven模式的消息垂直调用。
对核心服务的依赖上,我们本着不信任任何外部服务的原则,即使外部服务出问题,我们依然能够继续作业,形成如下图的调用方式:
链路开销大且网络抖动很容易引起问题,我们会将其做成一个“航母级”的服务来调用,如下调用:
举个例子:配送人货匹配生成笛卡尔积后类似map-reduce进行分布式计算,通过鹰眼链路观察发现耗时主要在map到reduce的网络耗时,不在于计算耗时,我们将将人货匹配生成矩阵,平衡网络开销和分布式计算,最后将108次调用变为9次,性能基本提升12倍,如下矩阵:
第二路:及时发现问题是稳定的一半
服务级别-幂等、参数校验、熔断、还是静态和动态控制超时时间、重试次数来保障服务级别的高可用;
系统级别-流量调度、研发红线、代码Reivew文化、重大发布集体上光明顶、流量调度、A3EagleEyeSLSXflush等的QPSRT同比环比的服务监控还是底层的机器性能监控都能保证在第一时间发现问题。重大发布集体上光明顶是我们的一个文化,记得在双12前两周我们对整个系统架构进行了一次升级,涉及13个系统又在大促前顶着压力发布上线,最终在双12期间系统整体平稳,较双11各项指标毛刺减少,特别是双12哪几天的雨雪天气在站内批次积压严重的情况下,我们的人货追加服务较双11的QPS增加近一倍,但我们的RT却降低了50%。
其它招,比如我们在过年期间每天的专人进行核心系统的例行检查,确保系统正常运行;在稳定性知识方面,我们内外结合进行分享,同时将别的team的故障都当做自己的故障来分析原因和查找我们系统的不足。
第三路:故障预防
在系统复杂和业务需求不断导致代码腐化,我们定时对整个系统进行重构,将整个重构方案大家达成一致;在今年系统的混部环境对我们也是一个挑战,所以我们引入了超时和重试机制,特别是做到了运行期修改超时时间,防止雪崩,每一个新功能上线时都会做故障注入和故障演练,识别潜在风险。
第四路:故障缓解
我们机器留有一些buffer以防大促、线程池满等紧急扩容情况下使用,同时对高QPS有降级预案以防异常情况紧急止血。还是前面提到的业务系统一定要有产品和业务兜底方案,比如我们在和蜂鸟对接时当蜂鸟的系统如果出现问题时,我们服务端针对此种情况做了防御性编程,打开开关让蜂鸟骑手用飞鱼app进行作业,减轻对用户的影响面。在稳定上,我们不但要自己赢,也要让合作伙伴赢。
第五路:快速恢复
回滚是系统发布后出现异常最有效的止血方案,对于弱依赖我们通过柔性可用性让它跳过不阻塞继续往下走,当出现异常case时比如履约和配的状态不一致我们通过阿波罗后台进行一键修复,异常紧急订正预案、Diamond命令下发等来快速恢复。
第六路:快速补偿
我们的系统在设计的都是无状态扁平化,不存在单点,机器扩容是应对某些异常情况的快速止血方案。
第七路:发布治疗
在上述路数招数都无法快速止血的情况下只能采用发布治疗,我们有一次突然机器Load飙高,收到报警后第一反应是机器问题,但又发现部分机器的线程池也快满了,我们随即开始扩容和机器重启,一部分同学在快速扩容,一部分同学在不停的机器重启,其它同学在迅速查找问题的根本原因,最后通过DUMP发现是由于引用了一个Jar,而这个Jar包里面使用了Java的正则表达式在解析一个特殊商品名称的时候进入了死循环,找到原因后这种情况只能通过发布解决,我们迅速达成一致紧急发布解决,正是前面一部分同学的扩容和不停的重启,从而避免了一场故障。
大海航行靠舵手
盒马配送的稳定性靠的是业务方、产品、研发、测试、Web端、App端、RF端、GOC、上下游、算法、IOT、NBF、盒马安全生产、中间件、网络、气象台、雨雪冰雾、道路交通、红绿灯、小区设施、骑手装备等等各种因素,每一个组成部分都是至关重要。稳定性的探索我们还在路上,不断追求极致。
原文发布时间为:2019-03-19
本文作者: 三郎
本文来自云栖社区合作伙伴“ 阿里技术”,了解相关信息可以关注“ 阿里技术”。
为了30分钟配送,盒马工程师都有哪些“神操作”?相关推荐
- 30岁后的测试工程师都去哪儿了?
下坡路? 测试员干到30岁,好不容易从测试小白混到了白领,却再也干不动了,还时时面临失业的危险.30岁,是一个测试员伤不起的年龄.明天,何去何从? 30岁现象 还有机会吗? 在官场上,曾经有一个59岁 ...
- PHP 依赖镜像出问题后,阿里工程师的一顿“神操作“令人叫绝!
简介: 上个月,PHP开发者在网上纷纷反映出现 Composer 镜像无法访问的问题.阿里云内部一位 90 后工程师顾咏连夜开工排查,快速解决问题后,他在问题群里收到了一大波来自用户的红包.顾咏最后谢 ...
- 数学家的这些迷惑行为,最后都成了神操作
有句鸡汤名言说得好,你的气质里藏着你读的书.到了学界,应该再加上半句,你气质里还藏着你做过的学问.文学评论家文质彬彬,经济学家目光炯炯,地质学家风尘仆仆,但最可爱的是数学家,他们大智若愚. 历史上很多 ...
- 盒马 iOS Live Activity “灵动岛”配送场景实践
作者:陈振港.李凯 苹果在 WWDC22 中,提出了实时活动(Live Activity)的概念,以便于用户在锁屏查看一些应用实时活动的更新,这与盒马的配送场景十分贴合.因此,我们将 Live Act ...
- 用户体验五要素_从用户体验 5 要素,分析盒马鲜生是如何收获百万好评的!
转自:设计意志(ID:D-Minder) 作者:王晗陵 写在前面的话 前几天我去盒马鲜生凑热闹逛了一会,体验了一下盒马的商品品类.用户动线.展柜分布和设计.APP交互.品牌设计等方面. 客观的说,逛完 ...
- 盒马鲜生真的是新零售吗?
2017年马云发布新零售概念,新零售到底怎么定义,去年在零售界.零售信息化界都吵翻了天.今年马云专门主推了盒马鲜生,说它是新零售的代表.盒马鲜生作为一个实际个案而非概念,能否从中总结出一些新零售的特征 ...
- 用户体验五要素_新零售「盒马」的用户体验设计5要素
写在前面的话 前几天我去盒马鲜生凑热闹逛了一会,体验了一下盒马的商品品类.用户动线.展柜分布和设计.APP交互.品牌设计等方面. 客观的说,逛完之后的整体购物体验感受还是可以的,但是自动结账机只能使用 ...
- 系出阿里“同门”的盒马鲜生要怎么走?
在盒马鲜生,你能看到正常超市里的大部分商品,海鲜.蔬菜.食品.酒水.生熟食.甚至部分日化快消品.7月18日,盒马鲜生北京.上海三家店同时开业,按照阿里人的说法,这标志着盒马模式经过一年半左右的迭代升级 ...
- 盒马鲜生卖花,“白菜花坊”是搅局者还是颠覆者?
最近,下班之后去盒马鲜生逛上一圈成为了李莹新的解压方式.每天除了买菜,她还会去鲜花区域转上几圈,看看有没有新鲜好看的鲜花. 李莹告诉笔者,她养成买鲜花的习惯已经快一年了,一般是一周左右换一次花.&qu ...
最新文章
- 如何破解压缩文件密码-省时省力的方法
- 2019年上半年收集到的人工智能迁移学习干货文章
- 消息中间件和JMS介绍
- AtCoder Beginner Contest 174 总结
- 关于maven导入工程pom文件报错问题及解决
- flex图表坐标轴样式设置
- HDU 2553 N皇后问题 DFS 简单题
- conda可以更改环境的python anaconda替换环境的Python
- Python多项逻辑回归和线性判别分析识别英文字母
- Win10免费升级 Win11 有时间限制
- 【沃顿商学院学习笔记】商业分析——Customer Analytics:04 规范性分析 Prescriptive Analytics
- matlab 求矩阵的逆
- 好用的记事本陈列 tree/f
- 3种方式获取Wifi名称 兼容获取Wifi名字为空 WifiInfo.getSSID为空的情况
- 把html页面保存为图片格式
- 提升工作效率的软件及网站(不断更新中)
- unity上传头像_unity3d 上传本地PC图片
- 使用openfeign调用报错java.io.IOException: too many bytes written,以及调用过程中参数传递为空等问题
- [作业]英语作业,无聊记事
- 【生活语录】为成智者,三省吾身
热门文章
- Python(5):循环
- 重拾python Day 2
- 偏最小二乘 非线性 matlab,求助:Matlab偏最小二乘程序哪错了
- SQL Server安装计划
- noip2017d2t2
- VS2010 无法计算HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\14.0@VCTargetPath处的属性表达式...
- 设计模式之Composite模式(笔记)
- 让KVM虚拟机支持console功能
- 【转】Android 轻松实现语音识别
- linux shell脚本编程技巧介绍(一)