基于Dubbo+NoSQL的工業領域大數據平臺研究

趙德基+王力+狄軍峰

摘要：基于Dubbo與NoSQL的工業領域大數據平臺，是在互聯網技術不斷發展的趨勢下，將傳統工業與大數據技術相結合的產物。隨著計算機硬件性能的不斷提升以及互聯網技術的高速發展，以往在工業領域內海量數據無法處理的局面得到了根本性的解決。大數據平臺充分結合了傳統工業領域，尤其包括電力行業、建筑行業、污水處理行業的各自特點。在不同場景的業務需求下，Dubbo+NoSQL的技術提供了對工業領域海量數據進行接收、存儲、計算、分析及展示的解決方案。不僅改變了以往傳統行業技術落后的現狀，平臺更加注重對傳統行業的數據進行專業化處理，對低價值密度的數據進行加工，實現數據的增值。對行業安全、行業發展、行業數字化都具有十分重要的意義。

關鍵詞：Dubbo；NoSQL；MongoDB；工業領域

中圖分類號：TP311 文獻標識碼：A 文章編號：1007-9416（2017）07-0064-04

由于傳統工業領域對海量數據的分析及存儲能力不足，各個領域對上送的數據通常采取舍棄的處理方式。以電力行業新能源領域的集中式光伏電站為例，一個百兆瓦的集中式光伏電站有數以千計的設備，每個設備又有不同數量的遙測、遙信、遙控及遙調信息，大量的設備數據會以每分鐘甚至每秒鐘的頻率進行上送。因此傳統行業管理系統面臨以下問題。

（1）系統性能處理瓶頸。由于需要接收、處理的數據量過大，系統的負荷過高，無法對數據進行實時、可靠、深挖掘的處理，因此傳統領域的系統對海量數據往往只能采取不接收，或者接收不存儲、不分析的解決方案。

（2）系統存儲能力不足。由于大數據在高并發環境下的關系型數據庫應用開發越來越復雜，也越來越具有技術挑戰性。雖然關系型數據庫例如MySQL可以存儲一些大文本字段，但是會導致數據庫表非常的大，不利于快速恢復數據庫。關系型數據庫雖然功能強大，但是已經不能很好的應對所有的應用場景。

（3）系統擴展性差。當需要有新的功能對原系統進行補充時，傳統管理系統的擴展性較差。無法做到功能模塊可插拔，進而無法快速適應業務的不斷變化，增大了開發難度和維護難度。

1 研究內容

針對工業領域傳統系統的不足，本系統采用Dubbo與NoSQL的分布式架構，對工業領域大數據進行處理。系統以Dubbo為大數據處理核心，以NoSQL為大數據存儲核心，使以往工業領域中的海量數據的處理及存儲有了可能。

1.1 Dubbo技術

1.1.1 技術背景

隨著工業領域數據規模不斷擴大，常規的架構已無法應對，急需一個大數據平臺對工業領域數據進行管理。

如圖1所示，當工業領域的數據量很小時，只需要一個應用便可以將所有功能部署在一起，減少部署節點和成本。此時，使用數據訪問框架（ORM）對數據進行增刪改查即可滿足工業領域需求。

隨著數據量越來越大，單一應用通過增加機器的方式帶來的速度提升越來越小，針對此問題的普遍做法是將應用拆分成互不相干的幾個應用，以提升效率。

但當垂直應用越來越多時，應用之間的交互不可避免，因此之后又發展出了用于提高業務復用及整合的分布式服務框架（RPC）。

最后，當服務越來越多時，容量的評估、小服務資源的浪費問題逐漸顯現，此時資源調度和治理中心（SOA）出現，對集群容量進行調度提升集群利用率。

Dubbo便是一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案以及SOA服務治理方案。通過使用Dubbo框架，便可以解決工業領域內海量數據處理以及應用越來越多的問題。

1.1.2 架構及特點

Dubbo架構圖如圖2。

Dubbo有幾個關鍵節點的角色：

（1）Container：服務運行容器。

服務調用時，Container負責啟動、加載，并運行服務提供者。

（2）Provider：暴露服務的服務提供商。

服務提供者在啟動時，向注冊中心注冊自己提供的服務；

（3）Consumer：調用遠程服務的服務消費方。

服務消費者在啟動時，向注冊中心訂閱自己所需的服務；

（4）Registry：服務注冊于發現的注冊中心。

注冊中心返回服務提供者地址列表給消費者，如果有變更，將基于長連接推送變更數據給消費者；

（5）Monitor：監控中心。

用于統計服務的調用次數和調用時間。

其中，服務消費者基于軟負載均衡算法，從提供者地址列表中選一臺提供者進行調用，如果調用失敗，再選另一臺調用。服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

Dubbo透明化的遠程方法調用，就像調用本地方法一樣，只需簡單配置，不需要任何API侵入；軟負載均衡及容錯機制，可以內網代替硬件負載均衡器，降低成本，減少單點；服務自動注冊與發現，不需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。需要添加新的應用模塊時，不用修改舊的系統代碼，只需簡單修改配置文件即可實現。降低了工業領域內系統升級或整合的難度。

以服務提供者為例，Sping配置如下：

<？xml version="1.0" encoding="UTF-8"？>

xmlns：xsi=http：//Data.w3.org/2001/XMLSchema-instance xmlns：dubbo ="http：//code.alibabatech.com/schema/dubbo"

xsi：schemaLocation="http：//Data.springframework.org/schema/beans

http：//Data.springframework.org/schema/beans/spring-beans.xsd

http：//code.alibabatech.com/schema/dubbo

http：//code.alibabatech.com/schema/dubbo/dubbo.xsd">

<！-- 提供方應用信息，用于計算依賴關系 -->

<！--multicast廣播注冊中心暴露服務地址-->

<！-- 用dubbo協議在20880端口暴露服務 -->

<！-- 聲明需要暴露的服務接口 -->

<！-- 和本地bean一樣實現服務 -->

1.2 NoSQL技術

1.2.1 技術背景

傳統工業領域一般使用關系型數據庫進行數據存儲和管理。關系型數據庫性能可靠、使用簡單、功能強大，當數據量不大時，關系型數據庫可以滿足存儲及增刪改查的需求。但當數據量不斷增加，系統面臨數據處理的性能瓶頸。首先，數據的高并發寫入，會使關系型數據庫寫入壓力增加，甚至出現嚴重的鎖問題，造成數據丟失。其次，當關系型數據庫存儲的數據量越來越大時，多表關聯進行的查詢也會受到影響。同時當存儲一些大文本字段時，會導致數據庫表非常的大，不易快速恢復數據庫。

因此傳統工業領域亟待NoSQL的引入，對不斷增加的業務數據進行存儲和管理。NoSQL指非關系型數據庫，是對不同于傳統關系型數據庫管理系統的統稱，用于大規模數據的存儲。這些類型的數據不需要固定的模式，無需多余操作就可以橫向擴展。本系統采用NoSQL中MongoDB對數據進行存儲。

1.2.2 技術實現

MongoDB是一個基于分布式文件存儲的開源數據庫系統。在高負載的情況下，可以添加更多的節點，保證服務器性能。當工業數據不斷增加時，MongoDB本身的特點決定了MongoDB可以很好的支持傳統工業領域的數據存儲要求。

（1）實用性。MongoDB是一個面向文檔的數據庫，直接存取BSON，這意味著MongoDB更加靈活，因為它可以在文檔中直接插入數組之類的復雜數據類型。同時文檔的key和value不是固定的數據類型和大小，所以使用MongoDB時無須預定義關系型數據庫中的”表”等數據庫對象，設計數據庫將變得非常方便，可以大大地提升系統開發進度；

（2）擴展性。MongoDB可以非常有效的對數據庫進行擴展，通過自帶的MongoDB集群，只需要在適當的時候繼續添加Mongo分片，既可以實現程序段自動水平擴展和路由，不但緩解了單個節點的讀寫壓力，并且可以有效地均衡磁盤容量的使用情況；

（3）負載均衡。MongoDB通過自帶副本集做到對數據的備份，同時通過設計適合自己業務的副本集驅動程序，非常有效和方便的實現高可用及讀負載均衡。這一點其他的數據庫會比較難以實現，往往需要額外的中間件，進而造成了系統的復雜度；

（4）其他特性。MongoDB保留了一些SQL的友好特性，例如查詢和索引，因此可以支持任何屬性的索引來實現更快的排序，最終獲得用戶需要的數據。

因此，本系統使用MongoDB數據庫對工業領域內不斷增加的海量數據進行存儲管理，其完全滿足工業領域內的各個場景。不同領域的數據都可以借助MongoDB以上的各種特性，實現數據的分布式存儲、備份冗余、動態查詢、故障轉移等功能。

以MongoDB分片為例：MongoDB集群示意圖如圖3所示。

本系統通過對MongoDB進行分片，實現對工業領域內海量數據的分布式存儲。系統部署四個分片，并部署配置服務器和路由服務器：

Shard Server 1：27000 #分片服務器1

…

Shard Server 4：27003 #分片服務器4

Config Server ：27100 #配置服務器

Route Process：40000 #路由服務器

啟動各個服務器后，便可將MongoDB與Dubbo框架進行對接，或者通過第三方的MongoDB客戶端對MongoDB進行操作：

[root@100 /]# mkdir -p /Data/mongoDB/shard/s0

…

[root@100 /]# mkdir -p /Data/mongoDB/shard/s3

[root@100 /]# mkdir -p /Data/mongoDB/shard/log

[root@100 /]# /usr/local/mongoDB/bin/mongod --port 27000 --dbpath=/Data/mongoDB/shard/s0 --logpath=/Data/mongoDB/shard/log/s0.log --logappend --fork

…

[root@100 /]# /usr/local/mongoDB/bin/mongod --port 27003 --dbpath=/Data/mongoDB/shard/s3 --logpath=/Data/mongoDB/shard/log/s3.log --logappend –fork

root@100 /]# mkdir -p /Data/mongoDB/shard/config

[root@100 /]# /usr/local/mongoDB/bin/mongod --port 27100 --dbpath=/Data/mongoDB/shard/config --logpath=/Data/mongoDB/shard/log/config.log --logappend --fork

/usr/local/mongoDB/bin/mongos --port 40000 --configdb localhost：27100 --fork --logpath=/Data/mongoDB/shard/log/route.log --chunkSize 500

2 結語

Dubbo+NoSQL工業領域大數據平臺可以解決傳統工業領域中存在的數據處理和存儲面臨的問題。當需要長時間處理一些復雜算法時，可以利用Dubbo進行負載均衡，提高運行速度并降低每個服務器節點的負載壓力。當由于業務需要擴展系統時，也只需水平增加機器即可達到性能的提升，不需要購置性能更強勁同時更昂貴的服務器，從而減少了企業的成本。另外MongoDB本身具備的彈性擴容、備份管理、監控告警及故障處理等功能，也很好的為工業領域不斷增長的數據提供了解決方案。

綜上所述，Dubbo+NoSQL工業領域大數據平臺體現了互聯網技術與傳統工業領域業務的良好結合，為傳統工業挖掘了更多的數據價值并開拓了更多應用上的可能性。

由于業務場景在不斷發生變化，本系統架構還會遇到新的挑戰，需要不斷的優化和改進。

參考文獻

[1]霍多羅夫，迪洛爾夫.MongoDB權威指南[M].北京：人民郵電出版社，2011：50.

[2]任女爾，張慶余，林盛海.基于Dubbo+ZooKeeper的CAMDS協同業務改造[J].電腦知識與技術，2016，11（2）：35-38.

[3]陸操.阿里巴巴聯盟引流系統的設計與實現[J].南京大學， 2015，5（1）：10.

[4]劉嘉俊.基于SOA架構的ERP與電子商務系統研究[J].企業經濟，2011（5）：88-90.

[5]陳裕，林輝.基于SOA的ERP系統架構模型研究[J].信息經濟學與電子商務：中國信息經濟學會學術年會，2008，11（1）：20.

[6]汪清明.基于SOA的ERP系統體系結構的研究[J].計算機應用，2007，5（2）：412-414.

[7]A Boicea，F Radulescu，LI Agapin. MongoDB vs Oracle -- Database Comparison[J]. International Conference on Emerging Intelligent Data & Web Technologies，2012，11（1）：20.

[8]Z Parker，S Poe， SV Vrbsky. Comparing NoSQL MongoDB to an SQL DB[J]. Acm Southeast Conference， 2013.11（1）：1-6.

[9]JR Loureno，B Cabral，P Carreiro，M Vieira，J Bernardino.Choosing the right NoSQL database for the job： a quality attribute evaluation[J].Journal of Big Data，2015，2（1）：18.endprint