为了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、盒马安全生产、中间件、网络、气象台、雨雪冰雾、道路交通、红绿灯、小区设施、骑手装备等等各类因素，每个组成部分都是相当重要。稳定性的探索咱们还在路上，不断追求极致。

---

本文做者： 三郎

阅读原文

本文来自云栖社区合做伙伴“ 阿里技术”，如需转载请联系原做者。