基于osgi技術(shù)的可平行擴展的應(yīng)用服務(wù)器的制造方法
【技術(shù)領(lǐng)域】
[0001]本發(fā)明屬于車聯(lián)網(wǎng)技術(shù)領(lǐng)域，涉及一種應(yīng)用服務(wù)器，尤其涉及一種基于0SGI技術(shù)的可平行擴展的應(yīng)用服務(wù)器。
【背景技術(shù)】
[0002]車聯(lián)網(wǎng)從廣義上講是對車、人、道路、公共信息平臺之間信息廣泛交互通信。車聯(lián)網(wǎng)利用先進的傳感技術(shù)、網(wǎng)絡(luò)技術(shù)、計算技術(shù)及控制等技術(shù)，對道路和交通進行全面感知，實現(xiàn)多個系統(tǒng)間大范圍、大容量數(shù)據(jù)的交互，對每一輛汽車進行交通全程控制，對每一條道路進行交通全時空控制，以提供交通效率和交通安全為主的網(wǎng)絡(luò)與應(yīng)用。
[0003]在國內(nèi)環(huán)境下，各車廠對信息開放方面采取保守態(tài)度，造成了目前多種異構(gòu)平臺多種協(xié)議并存的現(xiàn)狀；另一方面，車聯(lián)網(wǎng)與互聯(lián)網(wǎng)應(yīng)用類似，存在高并發(fā)特性，對數(shù)據(jù)實時性、可靠性的要求甚至超過普通互聯(lián)網(wǎng)應(yīng)用；此外，車聯(lián)網(wǎng)面對的終端除了 tbox外，還有手機、電腦等終端，對多種開發(fā)語言的支持也提出了挑戰(zhàn)。
[0004]有鑒于此，如今迫切需要設(shè)計一種新的車聯(lián)網(wǎng)應(yīng)用服務(wù)器，以便克服現(xiàn)有服務(wù)器的缺陷。

【發(fā)明內(nèi)容】

[0005]本發(fā)明所要解決的技術(shù)問題是:提供一種基于0SGI技術(shù)的可平行擴展的應(yīng)用服務(wù)器，可集群、可平行擴展、支持車聯(lián)網(wǎng)行業(yè)與車輛Tbox通訊的ACP協(xié)議、支持異構(gòu)平臺之間的高效二進制協(xié)議，并能夠適應(yīng)車聯(lián)網(wǎng)汽車數(shù)據(jù)采集的高并發(fā)需求。
[0006]如今的車聯(lián)網(wǎng)的現(xiàn)狀，對應(yīng)用服務(wù)器中間件提出了一系列的要求，包括:兼容異構(gòu)平臺之間的多種協(xié)議，對多種開發(fā)語言提供支持，高性能、高并發(fā)、可快速集群平行擴展及業(yè)務(wù)監(jiān)控等。傳統(tǒng)的應(yīng)用服務(wù)器中間件運行于服務(wù)器操作系統(tǒng)之上，管理計算資源、網(wǎng)絡(luò)通訊及數(shù)據(jù)服務(wù)，屏蔽了底層網(wǎng)絡(luò)和操作系統(tǒng)的復(fù)雜與異構(gòu)，提供標(biāo)準(zhǔn)的服務(wù)集，使得整個系統(tǒng)對于其上運行的應(yīng)用是透明的。傳統(tǒng)應(yīng)用服務(wù)器在異構(gòu)系統(tǒng)之間交互數(shù)據(jù)都是基于Http協(xié)議的Webservice或RestFul實現(xiàn)，網(wǎng)絡(luò)傳輸效率低下，系統(tǒng)資源消耗高，對硬件要求相對更高。傳統(tǒng)的應(yīng)用服務(wù)器中間件在集群支持和平行擴展方面存在不足，在集群配置方面極為繁瑣，又或是依賴外部系統(tǒng)負(fù)載調(diào)度，需自行整合設(shè)計方案；在協(xié)議兼容方面，缺乏靈活性；在應(yīng)用部署方面，不能根據(jù)需求熱部署動態(tài)添加；在監(jiān)控方面，如果要對業(yè)務(wù)層面進行監(jiān)控，需要進行二次開發(fā)。在車聯(lián)網(wǎng)領(lǐng)域能夠滿足這些需求的應(yīng)用服務(wù)器中間件更是鳳毛麟角。
[0007]為解決上述技術(shù)問題，本發(fā)明采用如下技術(shù)方案:
[0008]一種基于0SGI技術(shù)的可平行擴展的應(yīng)用服務(wù)器，所述應(yīng)用服務(wù)器包括:
[0009]網(wǎng)絡(luò)通信模塊、協(xié)議轉(zhuǎn)換模塊、集群管理模塊、模塊化服務(wù)容器、監(jiān)控管理模塊；
[0010]1)網(wǎng)絡(luò)通信模塊用以實現(xiàn)應(yīng)用服務(wù)器與終端設(shè)備的連接；
[0011]使用ΝΙ0網(wǎng)絡(luò)API實現(xiàn)的網(wǎng)絡(luò)底層通信功能，能夠更高效的處理大量的網(wǎng)絡(luò)請求，基于通用的Tcp協(xié)議，能夠更加靈活的處理來自各種終端的網(wǎng)絡(luò)請求；使得本應(yīng)用服務(wù)器擁有了能夠更穩(wěn)定高效的處理大規(guī)模的網(wǎng)絡(luò)請求的能力；應(yīng)用服務(wù)器基于事件驅(qū)動模型設(shè)計，并通過管道來控制事件分發(fā)和傳遞；
[0012]2)協(xié)議轉(zhuǎn)換模塊用以實現(xiàn)客戶端與服務(wù)器之間的協(xié)議轉(zhuǎn)換；具體包括:業(yè)務(wù)請求消息單元、平臺統(tǒng)一消息接口、ProtoBuffer協(xié)議單元、TCP協(xié)議單元；
[0013]業(yè)務(wù)請求消息單元用以發(fā)送業(yè)務(wù)請求消息；平臺統(tǒng)一消息接口單元用以將消息轉(zhuǎn)化為統(tǒng)一的格式；ProtoBuffer協(xié)議消息單元用以將消息按照ProtoBuffer協(xié)議的要求進行轉(zhuǎn)化；TCP協(xié)議單元用以將消息按照TCP協(xié)議進行轉(zhuǎn)化；
[0014]3)集群管理模塊用以將分布式協(xié)調(diào)組件Zooke印er組件整合到應(yīng)用服務(wù)器中，使得應(yīng)用服務(wù)器擁有的動態(tài)集群的能力；本應(yīng)用服務(wù)器使用Zookeeper的特性，使得服務(wù)器在啟動時能夠自動的加入集群、停止時能夠自動從集群脫離，能夠無限擴展集群節(jié)點；使得本應(yīng)用服務(wù)器擁有了基于集群的平行擴展能力；
[0015]實現(xiàn)方法:當(dāng)每個服務(wù)器節(jié)點在啟動時，會在zookeeper中創(chuàng)建兩個存儲節(jié)點ClusterA/members/N和 /ClusterA/available/N,其中 members/N將永久存在，表不集群中的節(jié)點，available/N將會根據(jù)網(wǎng)絡(luò)中斷或者集群節(jié)點服務(wù)停止shutdown指令時消失；它的消失將實時通過各個客戶端的Watcher通知到集群客戶端，同時當(dāng)網(wǎng)絡(luò)恢復(fù)時,節(jié)點將重新回到可用節(jié)點available列表中，這個機制能保證集群客戶端的available列表中將總是可以的服務(wù)器集群節(jié)點；當(dāng)網(wǎng)絡(luò)斷開時，所有集群客戶端的監(jiān)視器Watcher將收到某個節(jié)點脫離集群的事件，則這個節(jié)點將不在作用于集群；
[0016]4)模塊化服務(wù)容器用以將所有來自網(wǎng)絡(luò)通信模塊的網(wǎng)絡(luò)請求會先進入線程池，待線程池中的任務(wù)執(zhí)行時，請求會被分發(fā)到不同的業(yè)務(wù)服務(wù)處理器，業(yè)務(wù)服務(wù)處理器會從osgi容器中查找到對應(yīng)的服務(wù)，來完成相關(guān)的業(yè)務(wù)處理；基于由于Osgi容器的特性，這些業(yè)務(wù)組件包bundle，在運行時環(huán)境中動態(tài)的加載和移除；使得服務(wù)容器擁有更大的靈活性，以及服務(wù)的熱部署能力；
[0017]5)監(jiān)控管理模塊用以對業(yè)務(wù)模塊進行監(jiān)控；包括:
[0018]客戶端請求調(diào)用分布式協(xié)調(diào)組件ZooKeeper集群，ZooKeeper集群檢查業(yè)務(wù)模塊的服務(wù)容器SP是否還在集群中，若在集群中，則返回業(yè)務(wù)模塊服務(wù)容器SP訪問接口給客戶端;
[0019]客戶端調(diào)用SP組件的方法被服務(wù)容器SP的業(yè)務(wù)方法攔截器捕獲，攔截器進行如下操作:將方法調(diào)用計數(shù)器做加1操作，記錄開始調(diào)用時間；
[0020]業(yè)務(wù)方法攔截器調(diào)用0SGI容器中的SP組件方法，方法返回結(jié)果或發(fā)送異常至所述業(yè)務(wù)方法攔截器；業(yè)務(wù)方法攔截器進行如下操作:計算處理時間；如果有錯誤，將錯誤次數(shù)做加1操作；如果當(dāng)前最大處理時間和前一個最大處理時間變量進行比較，若當(dāng)前最大處理時間更大,則將最大處理時間修改為當(dāng)前最大處理時間；
[0021]指標(biāo)采集開始需要獲取業(yè)務(wù)模塊SP組件的業(yè)務(wù)方法列表；通過監(jiān)控模塊從業(yè)務(wù)方法攔截器獲?。槐O(jiān)控模塊是基于JMX開發(fā)的管理組件，運行在SP-Server中，用于匯總各種指標(biāo)數(shù)據(jù)同時向指標(biāo)采取器提供接口 ；監(jiān)控模塊向采集器提供:業(yè)務(wù)方法列表接口、指標(biāo)獲取接口、指標(biāo)重置接口、業(yè)務(wù)組件控制接口 ；
[0022]循環(huán)每個業(yè)務(wù)方法條目，根據(jù)方法的標(biāo)識發(fā)起指標(biāo)獲取請求，一個業(yè)務(wù)方法包含:處理次數(shù)、處理時間合計、最大一次處理事情、錯誤次數(shù)；
[0023]一次業(yè)務(wù)方法的指標(biāo)采集完，調(diào)用重置接口，把上次所有指標(biāo)清零；各項指標(biāo)保存到時間序列數(shù)據(jù)庫tsdb中后，表現(xiàn)為一定時間間隔的指標(biāo)數(shù)值；
[0024]采集程序通過控制接口，向ZooKe印er集群發(fā)送脫離SP組件指令，SP組件集群后，業(yè)務(wù)調(diào)用將不會分發(fā)給SP組件集群；
[0025]業(yè)務(wù)指標(biāo)的分析及報警步驟；
[0026]信息展示步驟:有配置關(guān)系的支撐數(shù)據(jù)，展示在某時間點上，包括業(yè)務(wù)方法請求數(shù)量、集群規(guī)模、JVM的線程數(shù)量、JVM堆內(nèi)存大小、服務(wù)器的會話數(shù)量、服務(wù)器連接數(shù)量、CPU利用率、內(nèi)存使用率、進程數(shù)量、網(wǎng)絡(luò)帶寬情況；通過綜合環(huán)境參數(shù)的展示運維人員準(zhǔn)確及時的協(xié)調(diào)資源，滿足系統(tǒng)峰值需求；同時在系統(tǒng)閑時削減資源，節(jié)約運營成本；
[0027]其中，業(yè)務(wù)指標(biāo)的分析及報警步驟具體包括:
[0028]步驟S81、提取各報警對象的的報警指標(biāo)，包括集群本身的指標(biāo)、集群各類型節(jié)點的指標(biāo)、JVM的指標(biāo)；
[0029]步驟S82、根據(jù)集群-服務(wù)器關(guān)系提取各集群的成員服務(wù)器；
[0030]步驟S83、循環(huán)各集群服務(wù)器，從時間序列數(shù)據(jù)庫tsdb中獲取各指標(biāo)的值；
[0031]步驟S84、對每項指標(biāo)逐一檢查配置的報警閥值；
[0032]步驟S85、報警分為兩種:中斷性報警，tsdb中沒有取出記錄；指標(biāo)超閥值類報警，超出了報警閥值的范圍；
[0033]步驟S86、報警成員的提取:Sp集群的報警根據(jù)主機、集群、渠道提取相關(guān)的報警組成員；Hadoop、Hbase、Mysql、Zookeeper集群提取集群和主機管理員；
[0034]步驟S87、報警的重復(fù)提醒問題:如果10分鐘后沒有人處理繼續(xù)產(chǎn)生同樣的報警信息；
[0035]步驟S88、獲取報警的郵件發(fā)送列表，發(fā)送報警郵件。
[0036]一種基于0SGI技術(shù)的可平行擴展的應(yīng)用服務(wù)器，所述應(yīng)用服務(wù)器包括:網(wǎng)絡(luò)通信模塊、協(xié)議轉(zhuǎn)換模塊、集群管理模塊、模塊化服務(wù)容器、監(jiān)控管理模塊；
[0037]所述網(wǎng)絡(luò)通信模塊用以實現(xiàn)應(yīng)用服務(wù)器與終端設(shè)備的連接；
[0038]所述協(xié)議轉(zhuǎn)換模塊用以實現(xiàn)客戶端與服務(wù)器之間的協(xié)議轉(zhuǎn)換；具體包括:業(yè)務(wù)請求消息單元、平臺統(tǒng)一消息接口、ProtoBuffer協(xié)議單元、TCP協(xié)議單元；業(yè)務(wù)請求消息單元用以發(fā)送業(yè)務(wù)請求消息；平臺統(tǒng)一消息接口單元用以將消息轉(zhuǎn)化為統(tǒng)一的格式；ProtoBuffer協(xié)議消息單元用以將消息按照ProtoBuffer協(xié)議的要求進行轉(zhuǎn)化；TCP協(xié)議單元用以將消息按照TCP協(xié)議進行轉(zhuǎn)化；
[0039]所述集群管理模塊用以將分布式協(xié)調(diào)組件Zooke印er組件整合到應(yīng)用服務(wù)器中，使得應(yīng)用服務(wù)器擁有的動態(tài)集群的能力；本應(yīng)用服務(wù)器使用Zoo