您现在的位置: 论文网 >> 管理学论文 >> 档案管理论文 >> 基于Zookeeper的国土资源档案分布式查询框架设计与实现论文

基于Zookeeper的国土资源档案分布式查询框架设计与实现

出处:论文网
时间:2019-02-17

基于Zookeeper的国土资源档案分布式查询框架设计与实现

  [Abstract] In view of the business development demand, the city bureau of land resources needs to integrate the archive data of the subordinate counties (city)’s bureau and provide the unified view file query to the market. A distributed archives data query framework in which the Zookeeper service registration mechanism and the REST service style are used. By means of RESTful Web Service, the remote distributed data query was resolved. Combined with the full-text index function provided by Lucene search engine, the data query speed and accuracy are enhanced with good application effect in real systems.

  [Key words]Zookeeper REST land archives WebService

  1 引言

  ??土资源档案管理是专业性较强的一项工作,因为其中专业档案较多,特别是地籍资料,具有很高的查找利用价值。近年来,随着城市化进程的加快和新农村建设的推进,拆迁安置中引发的土地纠纷也随之增加。国土档案工作可以为调处土地权属纠纷、土地违法案件、信访案件提供大量证据资料,切实维护土地所有者、使用者的权益,进一步促进社会的和谐稳定;在解决邻里纠纷、民事诉讼、房屋拆迁补偿、办理土地使用权证等方面发挥重要作用。

  随着信息化发展的加快,国土档案管理对象从纸质文档发展到了电子影像文档。档案数据的来源从过去纯粹的单一系统录入,转变到来自不同业务系统。因此迫切地需要集成化的国土档案资源管理系统对数据进行管理。

  当前的档案管理系统在归档时需要二次扫描,重复性工作量大。其次,全市国土档案数据在物理上分布于各个县区,各县市区的档案系统无法提供一个统一的系统入口以供对全市范围的档案数据进行查询,原档案查询过程繁琐。针对这些问题,需要对不同系统的未归档数据和物理上独立分布的已归档数据进行集成,并提供统一的档案查询接口,使档案查询归档更加快捷方便,提高档案的利用率。

  目前基于WebService的面向服务的架构SOA成为人们解决问题的主要途径[1]。近年来,表述性状态转移(REST,Representational State Transfer)作为架构被提出,其高可扩展性和简单的部署方式更适合于轻量级的Web服务,尤其适合面向资源的应用[2]。基于REST风格构建的互联网应用具有方便集成、提高服务器的可扩展性等优点。基于Zookeeper设计和实现服务的注册发现中心,提高了注册中心的一致性和高性能。基于Node.js实现的Service Gateway(服务网关)可解耦服务消费者和服务提供者,对外提供统一的服务调用方式。本文主要研究如何利用REST、注册中心和服务网关实现可扩展性好、稳定性高的分布式查询框架,并在此基础上实现松耦合、易查询的国土资源档案信息系统的建立,解决不同系统之间的资源集成问题,并采用Lucene对部分关键表的重要字段以及部分文档实时建立全文索引,以提高档案资源的利用率[4]。

  2 关键技术

  2.1 面向服务的架构SOA

  SOA的基本概念:面向服务的体系架构是一个组件模型,其架构思想主张系统设计与实现相分离,使系统整体设计不再受制于技术实现因素。面向服务的体系架构设计摆脱技术的束缚,为解决异构系统通信与互操作问题提供了一种行之有效的解决方案[5]。在SOA架构的基础上,利用所提供的面向服务的特性,对原有国土资源局及县市区的应用系统的数据库进行分析,将必要的资源数据转变为可共享的标准服务,然后通过对服务的调用来完成各个应用和系统数据的交互与业务协同,实现异构、分布式应用系统之间的敏捷、快速、松耦合、高可靠的应用集成的体系架构[6]。

  2.2 REST

  REST是2000年Roy Thomas Fielding博士在他的论文中提出的一个术语。其核心思想是将Web应用中所有信息均抽象为“资源”,而所有操作也都是基于资源完成的[7]。在REST中,认为Web是由一系列抽象资源组成的。

  REST并不是一种架构,而是一种约束或者说是设计原则,任何符合该约束的服务或架构都可以称为是RESTful的服务或架构。在RESTful架构中,当客户请求时,返回资源的一种特定表现形式,例如Json、PDF、XML等。这种基于资源的设计改变了传统的基于动作的设计思想。RESTful Web服务是基于HTTP协议的,Web应用程序通过一致的接口(URI)来暴露资源,客户端通过HTTP的四个动作谓词来访问资源[8]。因此可以显式地使用CRUD方法,即创建、读取、更新和删除(CRUD,Create、Read、Update、Delete),从而与HTTP服务建立四种映射。   综上,通过RESTful风格设计国土资源档案管理系统能够赋予其高伸缩性、扩展性和灵活性,通过标准的服务来访问档案资源,使整个架构更加简洁。因此对于国土档案资源在物理上多点分布和系统异构并存的资源环境,使用RESTful Web服务是合适的。

  2.3 Zookeeper分布式服务注册中心

  Zookeeper是一个分布式的框架,应用于解决分布式集群系统的一致性问题。Zookeeper提供了基于类似文件系统的目录节点树方式的数据存储,其不仅是存储这些数据,还可以维护和监控数据的状态变化,并将这些数据的最新状态通知给数据服务的使用者[9]。

  Zookeeper作为分布式服务的注册发现配置中心,可以对服务提供者和服务消费者进行解耦,服务提供者在应用启动时向服务中心注册,服务消费者在应用启动时向服务注册中心拉取当前的提供者基本数据[10]。Zookeeper分布式服务注册中心示意图如图1所示。

  如图1所示,用socket长连接来保持服务提供者、服务消费者(可以是服务网关)和服务注册中心之间的连通性,并通过心跳包来感知服务提供者,服务消费者可及时获取到最新的可用服务列表,确保注册中心服务的可用性以及架构的健壮性和伸缩性。

  (1)健壮性

  1)注册中心宕机后,服务消费者仍能通过本地缓存的服务目录调用服务提供者;

  2)服务提供者无状态,一台宕机后,服务消费者根据拉取到的服务信息仍可调用其他服务。

  (2)伸缩性:服务提供者无状态,可动态增加机器部署实例,注册中心将推送新的服务提供者信息给服务消费者。

  3 需求分析

  3.1 数据和系统现状

  市国土资源局的各个业务系统建立在信息化进程中的不同时期,所采用的技术和架构存在较大差异,早期系统没有解决各系统的数据集成问题,全市档案数据分布于各县市区和市局的档案系统中,由于这些系统采用的技术架构不同,无法很好地集成数据,形成了信息孤岛,从而导致了在档案数据归档时出现重复性工作。加之不动产登记对国土档案数据有着大范围的查档需求,故建立集成化的档案管理系统迫在眉睫。

  对上述现状可归纳为已归档的档案数据在物理上多点分布,需归档的数据存在于异构的系统中,要在数据层面上以服务的形式进行集成[6]。集成后可以提高档案查询的效率,只需打开一个浏览器终端页面就可以对全市档案进行查询,如图2所示:

  3.2 功能需求

  在采用RESTful Web服务解决数据集成问题的基础上,对需求进行分析后得出档案管理系统的功能模块,如表1所示:

  4 系统设计

  4.1 架构设计

  基于RESTful的市国土资源档案管理系统的架构模型如图3所示,大致可以分为6层和一个服务注册中心。

  (1)数据源层

  数据源层主要包括数据资源和相关业务系统。数据来源主要有OA数据库,江北、海曙、江东和高新区的数据库以及ftp服务器上的档案文件。业务系统包括部署在市局的档案、OA系统,地籍系统等,这些系统中的数据正是市档案系统所要集成的。

  (2)索引层

  Lucene是一个高性能的全文搜索引擎工具,在倒排索引的基础上可实现分块索引,提升了索引的速度[8]。系统从数据库中获取数据,对主要的查询字段形成一个全文检索的库,在检索条件模糊的情况下从索引库检索,从而提高档案查询时的查准率。并且每天定时从数据库中拉取增量数据建立全文索引。

  (3)原子服?詹?

  原子服务层的服务是标准的、独立的、细粒度的,原则上原子服务是不依赖于其它任何服务的,运行效率和可复用性高。例如将各个系统的数据表中的档案数据分别建立查询的服务,作为最基本的原子服务,向服务注册中心注册,为上层的组合服务提供基础。

  (4)组合服务层

  组合服务根据档案系统的业务逻辑将原子服务组装成符合业务需求的服务,提供粒度更粗的服务功能,同时能简化客户端的调用逻辑。比如,需要在全市范围内查询一个档案,需要逐个调用5到6个服务,通过服务的组合可以减少业务层在调用服务时的成本。

  (5)服务网关

  Service Gateway封装应用的内部结构,简化客户端的调用过程,相比起直接调用指定的服务,通过Service Gateway实现服务调用更加简便。同时客户端能提供统一的调用接口,减少客户端维护保存服务调用接口地址的成本。

  (6)服务注册中心

  服务注册中心作为整个架构中一个重要的中间件,是整个系统维护各类服务接口的基本数据,在此基础上,基于Zookeeper的注册中心会监听已注册服务的服务器,当监听服务器不可达时,将该服务从注册服务的节点上删除,以保证在注册中心的服务是可用的。

  (7)业务层

  在原子服务和组合服务的基础上,系统通过调用这些服务来实现档案系统的部分重要功能,例如全市范围内档案的搜索和文档影像文件的查看功能,以及文书档案、业务档案和多媒体的归档、整理、借阅管理和利用率统计等功能。

  4.2 架构设计

  (1)注册中心数据存储结构设计

  Zookeeper内部提供了一个基于ZNode节点的树状模型,可以在根节点下方扩展任意的子节点,其子节点分为四种创建模式,包括持久节点、持久顺序节点、临时节点、临时顺序节点[3]。

  根节点是持久节点,可以在根节点下添加其他节点,使用服务名称作为子节点的名称,将该类节点称为服务节点,其同样是持久节点。为了确保服务的高可用性,可以发布多个相同功能的服务到同一个服务节点下。根据业务和架构设计,将节点分为原子服务和组合服务两大类,注册中心存储结构如图4所示。   (2)基于注册中心和服务网关设计实现服务的高可用属性

  每个服务节点下都有多个节点提供同类的服务,当消费者发起调用时,服务网关根据从注册中心拉取到的服务列表逐个调用该类服务直到调用成功,这种错误从试的调用策略提高了服务的可用性和系统稳定性。根据调用策略亦可实现软负载均衡的功能。可用性设计如图5所示:

  4.3 基于Node.js的服务网关的设计

  Node.js是一个基于Chrome V8引擎的JavaScript运行时环境,它使用了一个事件驱动且“异步非阻塞I/O”的模型,使其非常轻量高效,因此可基于Node.js来设计和开发服务网关。

  服务网关(Service Gateway)是服务架构中的核心组件,它是服务请求的门户,是调用具体服务端的桥梁,服务网关类似经典设计模式中的门面模式,它将底层的复杂细节进行屏蔽,解耦服务调用者和服务提供者之间的关系,对外提供简单且统一的调用方式,如HTTP方式。

  服务调用者将服务名放到请求头中,服务网关解析该请求,从注册中心获取该服务的提供者,并根据一定的规则,例如随机、错误从试和随机调用等规则来调用服务提供者,调用过程如图6所示:

  5 系统架构具体实现

  5.1 系统服务化的实现

  (1)资源的分类标准

  标准的Web服务是档案系统查询、管理、归档和集成不同数据源的规范基础,根据REST的设计原则,可以将资源的CRUD操作对应于HTTP的POST、GET、PUT、DELETE四个类型的请求。根据《宁波市国土资源局归档范围、分类方案及保管期限表》,确定档案资源的分类和命名规则,将综合类、会计类、土地类、地籍类、土地规划类、建设用地类、故土资源监察类、科技类、电子声像类和地质矿产类,依次以A到I命名。

  (2)发布接口的定义

  依据REST的设计原则以及档案的分类,部分服务接口的模板定义如表2所示:

  (3)接口的实现

  JAX-RS即Java API for RESTful Web Services,是java实现RESTfulWEB服务的规范,而Apach CXF是对JAX-RS的一种很好的实现,借助于Spring能够较好地将Apach CXF框架集成到项目中。

  5.2 组合服务实现

  组合服务层是根据业务进行组合过的原子服务,可满足复合业务需求。在档案管理系统的查询服务中,由于档案数据所在地不同,需要访问4~5个不同的原子服务接口才能查询全部档案,这增加了客户端调用的成本,故将原子服务组合成一个方便调用的服务接口。例如,客户端请求C类档案的查询服务:

  (1)首先客户端向服务网关请求C类档案的服务,服务名为“queryC”;

  (2)服务网关解析客户端的请求,获得服务名为“queryC”的服务节点的信息;

  (3)服务网关执行反向代理;

  (4)组合服务从注册中心的“/atomService/”路径下获取所有服务名是“queryC”下面的服务提供者节点;

  (5)根据获取到的服务提供者节点,分别调用该服务;

  (6)将原子服务返回的结果合并,并返回给调用者。

  5.3 服务注册实现

  服务注册在应用启动时,自动将要发布的服务注册到服务中心。首先将获取到哪些服务需要注册,借助java的反射扫描指定的包下的Class获取到哪些有“@Path、@GET”等注解的类和方法,这些加了该注解的方法就是需要发布的服务,并获取注解中的服务路径、参数等属性。

  6 结束语

  针对国土档案资源物理上多点分布、归档数据存在于异构系统中的现状。本文设计和实现了基于Zookeeper的档案资源分布式查?框架,并对应实现了的Zookeeper服务注册中心和基于NodeJs的服务网关,使得系统具有了接口统一,以及调用方便、易扩展、松耦合等特性,在此基础上完成了资源的定义、数据的集成,REST服务的发布及其他业务功能的设计和实现。基于上述框架的档案资源管理系统解决了当前遇到的数据集成问题,在实际运行中效果良好。未来还需要增强服务网关的可靠性,增加服务网关对服务的监控功能,包括服务的调用次数和调用耗时等,使能对系统服务运行情况有基本的了解。

基于Zookeeper的国土资源档案分布式查询框架设计与实现

论文搜索
关键字:分布式 国土资源 国土 Zookeeper 框架 分布
最新档案管理论文
人事档案管理信息化建设创新路径研究
浅谈卫生职业院校教师素质的提升
卫生人力资源管理的探讨
钢铁企业档案管理的信息化建设探讨
浅谈新形势下事业单位档案管理的改革方向
浅析档案管理在医院管理中的作用及其策略
浅析新时期农业科研档案价值实现途径
大数据时代背景下档案管理工作的研究
新时期领导干部人事档案规范化建设研究
新时代信息数据化背景下企业档案管理创新思
热门档案管理论文
网络环境下的档案创新服务
如何做好档案管理工作
如何推行档案工作规范化标准化
浅议电子档案的整理与保护
试论档案工作中的保密
推动电子文件归档工作的思考
电子文件对档案工作的影响及对策
试论档案工作中的保密
档案信息自动化系统管理若干问题的思考
谈计算机技术在企业现行文件与档案管理中应