58速运货物运输，滴滴快递网约车，司机端都是按照行驶公里数收费的，所以“里程”的准确性，是这类业务的一个核心难题，“里程计算”方案演进，以及其中优化思想，是本文要讨论的问题。
一、直接调用地图API
这是最容易想到的方法，最省事，但司机往往不是按照预定的路线行驶的，很有可能因为堵车、道路封闭等改变路线，所以直接调用地图API，一次性计算出一个预估值，不太靠谱
优化方案：根据实际路线计算里程
二、司机APP实时计算增量里程，服务端存储总里程
过程如下：
(1)货车位置不停的在改变，司机APP每隔一段时间(例如1s)记录一次GPS，即打点
(2)实时计算相邻两点的距离，上报服务端
(3)服务端存储总里程
潜在问题：GPS可能不准确，偶尔会有噪点，一旦有噪点，相邻两点的距离会很远，导致最终总里程可能比实际里程远
优化方案：不能实时计算增量，而应该先打点，最终统一计算，这样才有机会去除噪点
三、打点上报服务端，服务端统一计算里程
过程如下：
(1)货车位置不停的在改变，司机APP每秒打一个点，上报服务端
(2)服务端将打点落地，记录数据库
(3)到达目的地后，服务端对于所有点进行统一处理，一次性计算里程，可以去除噪点
潜在问题：假设每单平均货运时长1小时，即每单要打3600个点，58速运每天100w订单，即总共要打36亿个点，每个点对应数据库一个写请求，则数据库的写压力大概在每秒4w次，扛不住
优化方案：批量写是一种常见的降低数据库压力的方案
四、客户端实时打点，压缩后批量上传
过程如下：
(1)司机APP每秒在本地打点，每隔一段时间(例如20s)，压缩，上报服务端，服务端压力从4w降低到2k
(2)服务端解压，批量写入队列
(3)队列中的点，每隔一段时间(例如2s)再写入数据库
优化成果：大大降低了数据库压力(由于存储量较大，实际优化的过程中，使用Hbase进行了优化存储)
其他问题：数据库压力降下来了，但到达目的地后，一个订单打的所有点计算里程，成本较高，如何减少计算量
优化方案：去除无效点
五、打点过滤，提高效率
什么样的打点是无效点，需要去除呢?
(1)噪点原则：连续打点，偏移量较大的噪点，需要去除
(2)同点原则：相同位置的点可以去除，因为移动路径为0
(3)速度原则：行驶速度超过合理范围的点，需要去除
(4)角度原则：理论上订单轨迹是平滑有序的，如果角度反复折回，可以视为无效点
潜在问题：如果司机APP有断网或者信号不好，可能会漏点，导致计算出的总距离小于实际距离，给司机带来损失
优化方案：补点
六、事后补点，数据修正，计算里程
如何进行补点，如何进行数据修正呢?
(1)补点：车辆行驶过程中，如果有中断路线，采用“地图路径规划”的方式补点
(2)修正：采用卡尔曼滤波算法，对轨迹进行整形
(3)计算里程：按照点到点的距离，进行累加
总结
“里程计算”的优化历程：
- 直接调用地图API
- 司机APP实时计算增量里程，服务端存储总里程
- 打点上报服务端，服务端统一计算里程
- 客户端实时打点，压缩后批量上传
- 打点过滤，提高效率
- 事后补点，数据修正，计算里程
“里程计算”业务并不是所有公司都会涉及到，但其中的优化思路，很多还是可以借鉴的：
- 单次与统筹：客户端单次记录与计算是不靠谱的，应该由服务端来实施，综合所有数据，去除噪点
- 单次与批量：单次操作，压力较大，不好压缩;批量操作能大大降低压力，并且压缩比高
- 全量与过滤：全量计算成本较高，过滤掉无效数据，能够降低计算量，提高精确性
- 补充与修正：对于少量缺少的数据，可以预测补充，平滑修正
【本文为51CTO专栏作者“58沈剑”原创稿件，转载请联系原作者】
