原文地址：http://www.jt808.com/?p=1282
在開發一個大規模的部標GPS監控平台的時候，就算我們花費再多的時間設計和規划，我們也並不能准確的預測出自己未來的車載終端接入量有多大，而且一開始就為了我們宏偉的設計藍圖，投入大規模的服務器硬件設備和網絡帶寬，這會帶來極高的成本投入，也會在早期造成大馬拉小車，空耗+復雜度過高。所以大多數的平台一定是從一兩台服務器搭建運營環境， 隨着車載終端量級越來越大，並發越來越高，業務模式也越來越復雜，我們需要將程序解構，從一個模塊拆出多個模塊，從單機運行變成多台服務器分布式部署，從單進程變成多服務模式。所以我們設計的時候，就必須要構建這種可擴展的由1變成N的架構，必須要有一個可擴展的高可用的基於部標jt808協議的服務器。
我們這里所說的10萬+終端接入，首先是10萬+在線的，另外並不是簡單的接入，后續肯定還要保證實時數據推送、數據入庫、報警分析和復雜的業務邏輯計算都能穩定的運行。在這種場景下，單台服務器或者單進程的一個808網關服務器是很難支撐到的。我們需要保證的是從前到后一系列的穩定運行指標：
1） 接入：10萬+終端接入不出現排隊和無法接入現象，由於一般的基於JT808協議的終端設備，都是基於TCP長連接通信，UDP的很少，10萬+長連接的維持對服務器的壓力可想而知非常大。一般的服務器帶寬不夠的時候，或者由於服務器處理速度慢，造成連接無法及時歸還連接池，造成服務器接入的時候，就卡殼。我們一般采用Netty來做為JT808服務器的NIO Socket服務器框架，而Netty在開發的時候就要求在Handler中，獲取的連接數據的時候，必須不能做耗時的操作。這就要求我們必須要異步處理。
2) 實時性 ： 雖然終端接入了，但是后續的邏輯處理模塊如果處理速度過慢，即使是異步的，也會造成數據在內存中排隊等候處理的情況，這樣當數據傳遞到web用戶面前的時候，就是滯后的，不滿足用戶對實時性的要求。如報警彈窗，位置顯示等都是對實時性有要求的功能。
3) 數據入庫：並發的連接，必然會造成對數據庫並發請求加大，要求及時入庫的GPS數據也是海量的，一分鍾將有幾十萬級別的GPS數據等待入庫，而且根據jt808協議，一條0×0200指令的定位數據包，經過服務器解析和邏輯計算后，又衍生出報警記錄，油量溫度記錄，里程統計記錄等等，數據量也非常的大。雖然並發是提高入庫效率的手段，但是並發過高，超過數據庫服務器承載的能力，又會造成數據庫服務器卡殼，進而造成連鎖反應，web用戶經常會看到頁面打開過慢，數據顯示不出來，其實不是web服務器的問題，是數據庫的壓力太大，難以及時響應。所以一個能承受10萬+終端的部標808服務器，並不簡單的是要求代碼寫的好性能高，前期數據庫的設計和規划能力和實際的承載能力也必須要跟得上，這就是一條流水線，那個環節掉鏈子，都是多米諾效應的崩潰。
在實際的運營中，單台的阿里雲服務器並不貴，帶寬的運營成本要高於服務器的成本，所以我們在設計架構的時候，必須要保證部標808服務器是可以像刀片一樣是可以插拔的，通過分散壓力，來保證系統的穩定運行。當某一個服務器模塊停用或者上線，是不需要整個平台調整或者改造開發的，web平台是無感的。
所以我們不能讓Web平台直接面對808服務器，而是在808服務和Web平台之間，增加一個Redis緩存服務器，808服務器的實時GPS數據直接push到Redis緩存中，web平台獲取實時數據的時候，不是通過RPC調用808服務器的實時服務，而是通過Redis的API，直接從Redis緩存中獲取。利用Redis的Pipeline模式，可以批量獲取所需的實時數據。
在Web平台給終端下發指令的時候，如何知道終端是在那一台服務器上，這個是通過在Redis中緩存一個Sim卡號和部標808服務器Id的映射關系表，當終端接入的某台服務器的時候，808服務器會自動在Redis上更新映射表，這樣web平台下發指令的時候，就知道通過那個部標808服務器下發指令。
由於Redis有消息隊列的功能，對於報警推送等實時性要求高的場合，當部標808服務器解析報警后，可以直接推送給Redis隊列，然后web平台通過訂閱消息隊列，獲取報警消息，然后再經由Websocket推送給前端平台。可以看出整個報警的推送路徑發生了重大改變，不再是從數據庫讀取出來，而是通過典型的分布式內存，不斷的推送。不單提高了報警響應的速度，更重要的是，大部分的GPS平台，報警誤報頻繁，頻繁的插入數據庫，對數據庫壓力非常的大。
