基于java技術(shù)開發(fā)符合jt808標(biāo)準(zhǔn)的GPS部標(biāo)平臺（jt808協(xié)議、jt809協(xié)議、netty框架、springmvc框架)

使用Java語言開發(fā)一個高質(zhì)量和高性能的jt808 協(xié)議的GPS通信服務(wù)器，并不是一件簡單容易的事情，開發(fā)出來一段程序和能夠承受數(shù)十萬臺車載接入是兩碼事，除去開發(fā)部標(biāo)808協(xié)議的固有復(fù)雜性和幾個月長周期的協(xié)議Bug調(diào)試，作為大批量794車載終端接入的服務(wù)端，需要能夠處理網(wǎng)絡(luò)的閃斷、客戶端的重連、安全認(rèn)證和消息的編解碼、半包處理等。如果沒有足夠的網(wǎng)絡(luò)編程經(jīng)驗積累和深入了解部標(biāo)808協(xié)議文檔，自研的GPS服務(wù)器往往需要半年甚至數(shù)年的時間才能最終穩(wěn)定下來，這種成本即便對一個大公司而言也是個嚴(yán)重的挑戰(zhàn)。

1）我們在開發(fā)部標(biāo)協(xié)議的GPS服務(wù)器，需要解決以下幾個問題：

1.      通信服務(wù)器固有的連接管理，能夠處理網(wǎng)絡(luò)的閃斷、客戶端的重連、安全認(rèn)證和消息的編解碼、半包處理；

2.      海量終端接入的高并發(fā)性能；

3.      良好的內(nèi)存管理，車載終端的連接本事是基于GPRS的無線連接，車輛在野外高速移動過程中，信號處于不穩(wěn)定狀態(tài)，雖然是基于長連接，但是這種連接不斷的中斷和接入，服務(wù)器在處理終端接入，數(shù)據(jù)解析，報警分析，批量入庫的時候，能夠內(nèi)存分配合理，不會造成內(nèi)存泄漏，在百萬次的調(diào)用中不會造成內(nèi)存累計上升；

2）要開發(fā)一個高性能的GPS服務(wù)器的三個主題：

1) 傳輸：用什么樣的通道將數(shù)據(jù)發(fā)送給對方，BIO、NIO或者AIO，IO模型在很大程度上決定了框架的性能。 

2) 協(xié)議：采用什么樣的通信協(xié)議，HTTP或者內(nèi)部私有協(xié)議。協(xié)議的選擇不同，性能模型也不同。相比于公有協(xié)議，內(nèi)部私有協(xié)議的性能通常可以被設(shè)計的更優(yōu)。 

3) 線程：數(shù)據(jù)報如何讀取？讀取之后的編解碼在哪個線程進(jìn)行，編解碼后的消息如何派發(fā)，Reactor線程模型的不同，對性能的影響也非常大。

Netty是業(yè)界最流行的NIO框架，可以很好的解決上面三個問題，它的可靠性、高性能和可擴展性已經(jīng)得到了上百上千的商用項目驗證，相對于.NET中的基于完成端口的通信框架，它要優(yōu)越的多，它的優(yōu)點總結(jié)如下：

1.      API使用簡單，開發(fā)門檻低；

2.      功能強大，內(nèi)聚了很多實用的功能，簡化用戶的開發(fā)；

3.      定制性好，通過ChannelPipeline機制可以靈活的進(jìn)行功能定制和擴展；

4.      性能高；

5.      成熟穩(wěn)定，社區(qū)活躍，Bug的修復(fù)周期比較短，新功能不斷的被加入，用戶可以體驗到更多、更實用的功能。

6.      經(jīng)歷了大規(guī)模不同行業(yè)的商用考驗，架構(gòu)質(zhì)量得到了充分的驗證。

Netty為了向使用者屏蔽NIO通信的底層細(xì)節(jié)，在和用戶交互的邊界做了封裝，目的就是為了減少用戶開發(fā)工作量，降低開發(fā)難度。ServerBootstrap是Socket服務(wù)端的啟動輔助類，用戶通過ServerBootstrap可以方便的創(chuàng)建Netty的服務(wù)端。

3）編碼器和解碼器的設(shè)計

對于808協(xié)議的解析處理，需要編寫自定義的解碼器了，目前Netty提供了多個基礎(chǔ)編碼器可以供開發(fā)者進(jìn)行繼承和拓展，開發(fā)的時候，需要了解這幾個解碼器的主要作用，主要用于那些通信數(shù)據(jù)傳輸?shù)膱鼍啊?/span>

為了降低用戶的開發(fā)難度，Netty對常用的功能和API做了裝飾，以屏蔽底層的實現(xiàn)細(xì)節(jié)。編解碼功能的定制，對于熟悉Netty底層實現(xiàn)的開發(fā)者而言，直接基于ChannelHandler擴展開發(fā)，難度并不是很大。但是對于大多數(shù)初學(xué)者或者不愿意去了解底層實現(xiàn)細(xì)節(jié)的用戶，需要提供給他們更簡單的類庫和API，而不是ChannelHandler。

Netty在這方面做得非常出色，針對編解碼功能，它既提供了通用的編解碼框架供用戶擴展，又提供了常用的編解碼類庫供用戶直接使用。在保證定制擴展性的基礎(chǔ)之上，盡量降低用戶的開發(fā)工作量和開發(fā)門檻，提升開發(fā)效率。

通常我們也習(xí)慣將編碼（Encode）稱為序列化（serialization），它將對象序列化為字節(jié)數(shù)組，用于網(wǎng)絡(luò)傳輸、數(shù)據(jù)持久化或者其它用途。

反之，解碼（Decode）/反序列化（deserialization）把從網(wǎng)絡(luò)、磁盤等讀取的字節(jié)數(shù)組還原成原始對象（通常是原始對象的拷貝），以方便后續(xù)的業(yè)務(wù)邏輯操作。

Netty預(yù)置的編解碼功能列表如下：base64、Protobuf、JBoss Marshalling、spdy等。

在GPS行業(yè)當(dāng)中，對于終端通信協(xié)議的設(shè)計有多種：

1）基于字符串設(shè)計的方式，這種方式就是終端發(fā)送一個ASCII字符串，然后服務(wù)器獲取后基于約定的分隔符分割為一個數(shù)組，再依次從數(shù)組中獲取對應(yīng)下標(biāo)的數(shù)據(jù)，這種方式通常是深圳小的硬件公司的技術(shù)水平較低的開發(fā)團隊喜歡采用，這種方式容易理解，但傳輸字節(jié)較多，效率較低，比較占用流量，不適用于基于流量套餐的無線卡傳輸。

2）基于定長協(xié)議的傳輸。

①　消息定長，例如每個報文的大小為固定長度200字節(jié)，如果不夠空位補空格。 ②　在包尾增加回車換行符進(jìn)行分割，例如FTP協(xié)議。

③　將消息分為消息頭和消息體，消息頭中包含表示消息總長度（或者消息體總體長度） 的字段，通常涉及思路為消息頭的第一個字段使用init32來表示消息的總長度。

④　更復(fù)雜的應(yīng)用層協(xié)議，例如部標(biāo)808協(xié)議

部標(biāo)協(xié)議數(shù)據(jù)包設(shè)計的特點：

1) 基于分隔符，包頭和包圍用0x7E來區(qū)分一個完整的數(shù)據(jù)包；

2) 動態(tài)包頭，不想其他協(xié)議在設(shè)計的時候，包頭長度都是固定長度，而808協(xié)議的包頭長度是不固定的；

3) 包體是動態(tài)長度，長度從包頭中讀取。

 解碼器就是要根據(jù)協(xié)議設(shè)計的數(shù)據(jù)包的規(guī)則，來對字節(jié)流進(jìn)行解析，解碼成完整的數(shù)據(jù)包。Netty提供了一下幾種基礎(chǔ)的解碼器提供給我們，供繼承或直接使用：

1）LineBasedFrameDecoder的工作原理是它依次便利ByteBuf中的可讀字節(jié)，判斷看是否有“\n”或者“\r\n”，如果有就以此位置為結(jié)束位置，從可讀索引到結(jié)束位置區(qū)間的字節(jié)就組成了一行。他是以換行符為結(jié)束標(biāo)志的解碼器，支持?jǐn)y帶結(jié)束符或者不攜帶結(jié)束符兩種解碼方式，同時支持配置當(dāng)行的最大長度。如果連續(xù)讀取帶最大長度后任然沒有發(fā)現(xiàn)換行符，就會拋出異常，同時忽略掉之前讀到的異常碼流。

2）StringDecoder的功能非常簡單，就是將接收到的對象轉(zhuǎn)換成字符串，然后繼續(xù)調(diào)用后面的handler。LineBasedFrameDecoder+StringDecoder組合就是按行切換的文本解碼器，它被設(shè)計用來支持TCP的粘包和拆包。

3）DelimiterBasedFrameDecoder特殊符號解碼器，其已經(jīng)過濾掉了分隔符。

4）FixedLengthFrameDecoder固定長度解碼器，它能夠按照指定的長度對消息進(jìn)行自動解碼。利用FixedLengthFrameDecoder解碼器無論一次接受到多少數(shù)據(jù)報，它都會按照構(gòu)造函數(shù)中設(shè)置的固定長度進(jìn)行解碼，如果是半包消息，FixedLengthFrameDecoder會緩存半包消息并等待下個包到達(dá)后進(jìn)行拼包，直到取到一個完整的包。

4）基于Netty開發(fā)一個部標(biāo)808協(xié)議的服務(wù)器，具體的步驟如下：

1）我們使用Netty要做的工作就是編寫編碼器和解碼器，然后按照Netty的要求來編寫調(diào)用，最后得到一個完整的808協(xié)議的數(shù)據(jù)包。

2）按照數(shù)據(jù)處理鏈條，分工職責(zé)，為了提高終端接入能力和數(shù)據(jù)分析、入庫能力，將終端消息的處理分成獨立的五級處理模塊，每個處理模塊都是異步獨立的，每個模塊內(nèi)都含有獨立的處理隊列，互不影響，提高數(shù)據(jù)的吞吐量和系統(tǒng)的響應(yīng)能力。

1）第一級：實時數(shù)據(jù)解析入庫，入庫能力決定了客戶端所看到的實時數(shù)據(jù)是否延遲；

2）第二級：報警分析并入庫（包括32種808協(xié)議規(guī)定的報警、停車報警和路線偏移報警)，報警分析只有快速分析才能快速的推送到前端客戶端；

3)  第三級：消息應(yīng)答和指令下發(fā)，應(yīng)答可以有一定的延遲，而不影響整個系統(tǒng)性能。

4）第四級：報表統(tǒng)計，由于油量統(tǒng)計、里程統(tǒng)計、上線率統(tǒng)計，需要定時掃描數(shù)據(jù)庫，生成每個時段的數(shù)據(jù)統(tǒng)計提供給報表查詢使用.

5）第五級：日志記錄和顯示

由于netty和Mina都能非常好的和spring容器集成在一起，引入spring框架，基于面向接口編程，系統(tǒng)可以同時支持netty和mina兩種通信框架，用戶可以根據(jù)自己的環(huán)境，通過配置決定是用mina或者是netty。

5）連接管理和日志報文監(jiān)控

在windows系統(tǒng)，可以運行swing界面進(jìn)行監(jiān)控，如果運行在阿里云的linux系統(tǒng)上，可以直接編寫java shell腳本，基于后臺服務(wù)運行，通過java 命令來調(diào)用當(dāng)前的連接，日志監(jiān)控，主要依賴于log文件。

jt808服務(wù)器代碼都是經(jīng)過眾多客戶使用檢驗過的千錘百煉的成熟的版本，協(xié)議解析、命令下發(fā)、報警解析、數(shù)據(jù)庫入庫、數(shù)據(jù)統(tǒng)計、壓力測試等各方面都考慮的非常充分完善，808協(xié)議全協(xié)議棧的實現(xiàn)，拿到手后，直接就可以使用了，帶有庫表文檔和字段說明。

需要JT 808 源碼(java和C#兩版本可選其一)+808模擬測試終端工具 +壓力測試工具  的請聯(lián)系我購買1200元(2379423771@qq.com), Java Mina框架版本參見:基于Java Mina框架的部標(biāo)GPS服務(wù)器

808服務(wù)器主要用的庫表： 

6)  本808服務(wù)器對于部標(biāo)808全部協(xié)議棧都進(jìn)行了充分的支持：