全物流，仓、CFC 、配送、运输 作业端定时上传蓝牙扫码到的温度信息，实现全链冷链温度跟踪。采集率达到 93% 1、项目新增了容器管理，用于容器与温度采集蓝牙设备的关系。 2、App 温度采集，由于作业端 APP 数据定时上报，将近1万 App 终端。每分钟就会产生 10 万条温度记录。对系统的存储 要求比较高，通过上报时间作为分表键进行分表。 3、 App 采集频率很高，当温度没有变化时记录大量的无用的数据，通过道格拉斯普克算法对历史数据进行抽稀 4、 作业端 APP 改造，作业时校验温度是否超温，如何有超温需要上报异常情况，通过场景分析需求后认为后续还有可能增 加新的操作前值条件，故需要考虑可扩展性，尽量减少 APP 端的发布次数。故与 App 制定了前置检查接口，接口返回 APP 弹窗列表，由服务端定义有多个弹窗，弹窗确认后的动式什么，通过这个设计，连续解决了多个需求的开发，节约了 APP 50%开发时间

配送站站内作业架构升级 原退仓功能，没有单测试，属于历史遗留代码。充斥这个大量的 if else 缺乏业务语意，代码规范混乱维护成本极高，在此 基础上修改产出及低，故需要重构，重构后方案使用清晰，易维护 重构方案： 系统显性的定义产品方案，逆向收货单接单时通过相关属性判断使用那种解决方哪，在退仓作业时通过方哪种方案决定如何 创退仓单，如果打包，是否需要预约等 方案引入 liteflow 轻量级框架，通过强制定义 node 节点来开发出符合单一原则的组件，通过对 Node 编写单元测试，来 实现代码可测试能力 内容: 全物流，仓、CFC 、配送、运输 作业端定时上传蓝牙扫码到的温度信息，实现全链冷链温度跟踪。采集率达到 93% 1、项目新增了容器管理，用于容器与温度采集蓝牙设备的关系。 2、App 温度采集，由于作业端 APP 数据定时上报，将近1万 App 终端。每分钟就会产生 10 万条温度记录。对系统的存储 要求比较高，通过上报时间作为分表键进行分表。 3、 App 采集频率很高，当温度没有变化时记录大量的无用的数据，通过道格拉斯普克算法对历史数据进行抽稀 4、 作业端 APP 改造，作业时校验温度是否超温，如何有超温需要上报异常情况，通过场景分析需求后认为后续还有可能增 加新的操作前值条件，故需要考虑可扩展性，尽量减少 APP 端的发布次数。故与 App 制定了前置检查接口，接口返回 APP 弹窗列表，由服务端定义有多个弹窗，弹窗确认后的动式什么，通过这个设计，连续解决了多个需求的开发，节约了 APP 50%开发时间 业绩: 采集率达到 93% app 开发减少 50% 开发时间 内容: 履约物流横跨多个团队的应，配送服务在妥投，收货后需要回调履约服务，当履约服务异常时将出现单据状态不一致的情 况。 该组件（pan_task ）为了解决这个问题，组件可以指定数据源，来保证写操作的原子性，业务动作完成后需要写入后，需要 调用 panTask 组件注册一个任务，通过定时任务服务调用，来重试，已达到最终一致的目的。如达到重试上限，将通过报警 通知开发进行处理 业绩: 配送域内，已经全部接入并通过此框架解决，并作为内部开源项目，推动其他域使用 教育经历 利用3年周末时间完成了专升本的学习。带着工作中的种种疑惑，重新学习理论基础学习。解决了工作中的实际问题。受益匪浅

随着配送系统承接的单量逐步增加，原有由站长分配骑手的模式不可为继，为了提高分配效率、需要搭建自动化的调度系 统。 项目新增调度系统应用，和原有的作业系统隔离，避免应调度系统不可用导致整个配送系统不可用。调度系统每20 秒，以配 送站维度，查询所有待调度的单据，将数据预处理之后（计算距离、查询查询天气，GIS 网格）等信息，提交给算法模块， 将算法返回的 配送员和单据的匹配结果 通过 RPC 接口 （阿里内部的 HSF ，与 dubbo 类型 ）持久化，并通知骑手。调 度系统使用分布式锁保证每个配送站只调度一次，通过使用配送站 code 散列化，避免集中调度产生的压力大的情况出现 内部架构设计上，自行搭建 flow 组件，将调度的步骤节点化，通过节点的组合来构建不同场景的调度服务