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实时计算增量里程，服务端存储总里程

• 打点上报服务端，服务端统一计算里程

• 客户端实时打点，压缩后批量上传

• 打点过滤，提高效率

• 事后补点，数据修正，计算里程

“里程计算”业务并不是所有公司都会涉及到，但其中的优化思路，很多还是可以借鉴的：

• 单次与统筹：客户端单次记录与计算是不靠谱的，应该由服务端来实施，综合所有数据，去除噪点

• 单次与批量：单次操作，压力较大，不好压缩；批量操作能大大降低压力，并且压缩比高

• 全量与过滤：全量计算成本较高，过滤掉无效数据，能够降低计算量，提高精确性

• 补充与修正：对于少量缺少的数据，可以预测补充，平滑修正

希望大家有收获。