一款车载GPS定位产品后端服务器架构的填坑之路(一）

文章名字取得有些唬人。这里说“架构”二字也是有些夸大，其实也就是实现一些简单的位置解析功能、数据存储等功能。整理出来，也只是给后来者一些借鉴。希望看到的能够去除糟粕，取其精华。

2014-15年，全民响应“万众创新”号召，创业热情高涨，深圳智能硬件创业大潮风起云涌，一时间市面上智能门锁、机器人、手表穿戴等一系列让人眼花缭乱的“APP+硬件终端”结合的产品纷涌而出。

当时在一家小型创业公司做一款车载GPS产品后台服务器开发工作，主要就是做一款车载智能硬件后台服务器的开发工作，其中有一项最主要的工作就是做GPS位置解析（GPS定位只是其中的一项功能，硬件产品的本地功能还有很多，由于与服务器之间没有直接交互，故略去）相关的工作。现在有空分享一下做这个后端服务器中的一些经验和一些心得。因为本身也是摸着石头过河，不敢妄自尊大，希望有兴趣的朋友们一起探讨。

1.定位产品的应用场景

想要去了解一个产品的核心需求，最直接的就是去分析产品的应用场景。我们在做这款产品的时候，经常会面临外行朋友们的疑问，“手机已经能定位了，既免费又不用安装，还要你们产品干嘛？”。当然这个是产品经理经常要去面临的问题，就好比“如何让客户理解在有淘宝的情况下，垂直电商存在的必要性。”

车载定位产品在物流、外卖、车辆租赁业务（如最近大热门的摩拜单车）等等领域都发挥了重要的作用。

比如下图，每辆单车都安装了GPS设备以提供APP查询周边车辆的硬件支持。

我们产品的主要应用场景就是被安装在机动或人力车辆上，获取位置信息并上传服务器，由服务器解析GPS位置信息后，在相应的用户交互界面（绝大多数是以地图的形式）显示出来。

2.定位原理

产品上内置GPS模块。启动后硬件产品搜星开始定位，定位后取得自身GPS位置信息，此时获取到的信息大多为GPGGA格式的数据，如以下所示

$GPGGA,014434.70,3817.13334637,N,12139.72994196,E,4,07,1.5,6.571,M,8.942,M,0.7,0016*7B

详细的GPGGA，在百度的定义是：
GPS固定数据输出语句($GPGGA)，这是一帧GPS定位的主要数据，也是使用最广的数据。
详细说明见这里 百度百科-GPGGA

设备从自身的GPS模块获取到这样的GPS位置信息。解析出其中的经纬度。
关于经纬度解析的一些参考信息。可以看我以前转载的一篇文章GPGGA数据解析

关于经纬度的纠偏、经纬度的度分秒转换相关事宜，大家可以自行百度。或在文章下留言沟通。

设备在获取到经纬度信息后。大多数是通过GPRS模块（也就是设备里面会插一张SIM卡），连接到附近的基站。然后将这些GPS数据封包发送到服务器上去。

以上就是硬件产品完成的基础设施工作。也就是将位置信息上报。告诉服务器“我现在在这里”。

接下来就是服务器端对这些信息进行存储、运算、分析的过程。

服务器在接收到GPS后，进行网络数据包的拆分和解析，得到封包中的设备ID（便于确定是哪个设备在上报位置，进行socket和设备ID的关联），经纬度信息（在这里查询经纬度和地理位置的对应关系）。

数据拆分、解包等工作完成了就需要进行数据的存储，将数据存储到数据库中，如关系型数据库MYSQL,或NOSQL的数据库。这里是一个技术难点，后面再说。

数据存储到数据库中后。要查看设备的当前位置、历史位置信息，只需要提供数据访问接口即可。比如APP需要查询牌号为粤A07987的车辆现在在哪里，只需要向接口提交一个查询请求，得到最新的位置信息。APP通过直观的形式展示出待查询的车辆位置信息。

3.对系统演变的思考

不难理解，从上面的描述中发现，最简单的逻辑就是如下所示

DEV - SERVER - USER

综合成一句话，就是“设备上报，服务器存储，用户查询”

大多数老板都不是很懂技术，而人们对于问题的认知，总是充满了主观臆断。所以就会觉得这个系统SO EASY。

缺乏专业的分析和足够的经验，对自己不了解的领域进行了错误的低估，在重要的、能够影响到整个公司发展进程、影响产品规划和方向的问题上，缺少预见性。做出很多足以让公司陷入泥潭的决定。是大多数小型创业公司的缩影。也是为什么大多数研发型创业公司总是在一个又一个的技术深坑中艰难跋涉，却又停滞不前的原因。

接下来就是这个系统要面临的挑战和各种神坑。

因为对于这个系统复杂度的低估，所以在技术选型上，一开始就选择了最简单粗暴的实现方式——找外包。而且外包的实现方式也是最简单粗暴的：

基于一个汽车OBD项目随便改了一下的源代码，一份网上找的IOCP模型。用于接收设备的GPS数据。将GPS数据存储到MYSQL数据库，之后用ASP.NET搭建了一个超级简陋的位置查询网站。然后验收，查看了几台设备在网站上是否能够看到最新的位置，OK，验收。

这个，就是我当时接手时所面临的一个挑战。验收系统的都是一群硬件工程师，嵌入式工程师，所以理所当然的没有进行压力测试，也理所当然的外包不会给你实现数据库读写分离，没有高可用，没有考虑到数据量大之后的高并发处理方案，没有考虑主服务器IP变更的应对策略。没有考虑到后期的可延续性。

公司在摸索中部署并实施了这套方案。而这一举措，让公司产品开发陷入极长一段时间的技术债务中。因为重构产品逻辑和代码需要大量的时间。而且在现有的基础上重构的代价极其大。同时因为产品的陆续出货，就需要兼顾现有客户的使用下进行重构。难度可想而知。

也是经历了这些，才深刻的感觉到

产品型的公司，在产品被市场认可之前，应该以产品质量和市场反响为根基，销售可以去接触市场反馈市场的需求和行情，而不是被销售带领着朝令夕改，到最后想要做的没实现，新增的又是纯属鸡肋。
产品的不稳定，功能的缺失以及目标群体定位的不明确，就会导致销售、市场错失很多先机，而且不好的口碑都会持续发酵，直接影响到品牌。当然这些都是公司战略层面的事情了，就不过多的探讨。


收钱办事对于外包来说，无可厚非。但是对于中小型创业型公司。如果一开始为了减少麻烦去找外包，认为外包给自己一套解决方案就能够高枕无忧，这种做法，无疑于给自己埋下了一颗深水炸弹。表面上风平浪静。功能都运作良好，只等一开始市场推广，就会肆无忌惮的爆开。


毕竟。保姆最多能给你保证儿子长大。不可能去操心他的教育、成长、关怀和茁壮成长。

接下来，就是记录一下在开发这套系统中陆陆续续面临的各种坑，以及填坑方法。

2016年11月16日17:16:31
witch_soya