基于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