文章名字取得有些唬人。這裡說“架構”二字也是有些誇大，其實也就是實現一些簡單的位置解析功能、資料儲存等功能。整理出來，也只是給後來者一些借鑑。希望看到的能夠去除糟粕，取其精華。

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位置資訊。解析出其中的經緯度。
關於經緯度解析的一些參考資訊。可以看我以前轉載的一篇文章

關於經緯度的糾偏、經緯度的度分秒轉換相關事宜，大家可以自行百度。或在文章下留言溝通。

裝置在獲取到經緯度資訊後。大多數是通過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