一种面向水文预报的通用网络服务构建方法与流程

文档序号:11143599阅读:218来源:国知局
一种面向水文预报的通用网络服务构建方法与制造工艺

本发明涉及一种通用网络服务构建方法,具体是一种面向水文预报的通用网络服务构建方法,属于水文预报技术领域。



背景技术:

一般而言,传统的水文预报计算方式通常是在个人电脑上独立完成。具体而言,以数据库为核心,用户通过计算软件调用存储在数据库中的模型参数和数据,完成计算后将数据存入数据库。如果其他人需要调用计算结果,也是直接通过数据库访问完成。

这种计算模式一方面,会导致数据库压力过大,架构层次不清晰,当系统越来越庞大时,运维成本越来越大,其可控性、安全性、扩展性也相对较差;另一方面,由于计算软件只能运行与封闭环境下的个人电脑,无法满足现在跨平台云计算的发展需求。



技术实现要素:

针对上述现有技术存在问题,本发明提供一种面向水文预报的通用网络服务构建方法,该构建方法能够使得架构层次清晰,避免了数据库的过大压力,并且能够把预报计算方法和模块打包成不同服务,保证该计算模式的可控性、安全性和扩展性。

本发明通过以下技术方案来实现上述目的:一种面向水文预报的通用网络服务构建方法,该构建方法包括如下步骤:

1)对预报计算模型进行封装,满足SOA的需求;

2)通过网络传输协议用于服务的请求和数据的传输;

3)计算服务器部署在分布式计算节点上,利用集群统一管理,通过负载均衡机制,保证用户的请求得到实时的响应。

进一步,所述步骤1)包括预报计算模型解耦和预报计算模型封装。

进一步,所述预报计算模型解耦是将计算模型中的计算过程分成各个子单元,并且每个子单元作为单独的功能封装成服务进行发布;各个子单元完全独立,子单元之间设有功能和调用关系上的依赖和高复用性。

进一步,所述预报计算模型封装采用数据库连接池负责数据库资源的分配,并且所述预算计算模型中的所有模块均可独立访问数据库。

进一步,所述步骤2)中的网络传输协议采用HTTP协议请求中的GET和POST两种请求完成服务操作;其中,GET请求用来表示发送的参数只包含基本数据类型的服务,POST请求用来表示发送的参数包含复杂数据类型的服务。

进一步,所述步骤2)中,在数据的传输之前,对原始的数据集进行序列化,再将得到的字节流进行压缩运算;其中,数据的传输采用JSON格式传递,压缩运算采用gzip压缩方式。

进一步,所述步骤3)具体为:

a)计算服务器作为所有服务的访问入口,负责服务的分发以及集群的管理;

b)分布式计算节点上部署着所有的预报计算、防洪调度以及各类查询的计算服务;

c)用户的请求通过网页或其他系统传递到计算服务器,计算服务器的负载均衡机制实时监视所有计算节点的运行状况,找到负载最小的节点分发请求,当计算节点完成计算后再逐层返回。

有益效果:该构建方法采用SOA框架,利用契约将各个子系统解耦,把所有预报计算方法和模块打包成不同服务,通过通用的Http协议发布到网络上,构建了一种以服务为中心的水文预报计算方法。该方法摆脱了传统预报计算软件的限制,直接为跨平台应用(传统软件、Web、iOS、安卓)提供通用的服务接口,确保了预报计算的一致性和通用性。同时,服务计算采用分布式部署,有效的提高了预报计算的效率,降低了系统的耦合性,扩展性和可控性得到加强。

附图说明

图1为本发明整体流程示意图;

图2为本发明具体操作流程示意图。

具体实施方式

下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。

如图1所示:一种面向水文预报的通用网络服务构建方法,该构建方法包括如下步骤:

A)对预报计算模型进行封装,满足SOA的需求。

面向服务的架构(Service-Oriented Architecture,SOA)是一种以“服务”为基本元素来组建的IT架构,通过预先定义的规范接口和契约,把应用程序的不同功能(即服务)联系起来,构成一套松耦合,独立于硬件系统、编程语言、使用环境的交互平台。

为了使得传统的水文预报程序能够服务化,需要对当前的程序进行解耦并重新封装,以满足SOA无状态和独立自治的原则。

所述预报计算模型包括预报计算模型解耦和预报计算模型封装。其中,所述预算计算模型解耦按照水文预报的流程,将计算过程分解成各个子单元,每个子单元作为单独的功能封装成服务进行发布。分类的要求是每个子单元完全独立,子单元之间没有功能和调用关系上的依赖,同时具有高复用性。本方法从两个维度把预报计算分为9类。在业务层面上分为雨情、水情和其他三个部分,在数据层面上,分为取数、计算和保存三个部分。具体分类见表一。

表一:数据层面分类表

所述预报计算模型封装的目的是为了让之前相互依赖的功能独立的运行。预报模型计算需要进行大量的数据库操作,所以封装的重要一点是所有模块都可以独立的访问数据库,由于数据库的连接占用了大量的时间,为了提高效率,采用了数据库连接池来负责数据库资源的分配,在系统初始化的时候统一建立连接,当服务需要使用数据库时,直接从连接池中获取资源,使用完后由连接池回收便于循环利用。

在封装时,选用了WCF(Windows Communication Foundation:微软数据通信框架)作为服务框架。WCF是Windows平台上开发分布式应用最佳的实践方式,该框架使用.NET环境,能够很好的集成原来C#以及Visual Basic的预报计算程序,同时提供广泛的网络服务协议支持,在安全性上也有相应的模块作为保证。

WCF通过契约来定义不同的服务,契约主要由操作契约和数据契约组成,操作契约即服务提供的方法,数据契约即服务与客户沟通时的数据格式。

(1)操作契约

在本方法中,操作契约为预报模块解耦出来的若干预报方法,契约的命名方式按照“操作+功能”的方式命名,比如取数操作以“Get”开头,保存操作以“Save”开头,计算操作以“Calc”开头,后面加服务的内容来构成服务名称,下面给出了具体操作契约的例子:

[OperationContract]

//获取区域面雨量

RainRegionDtP GetRainRegionDtP(string basinId,int workDt,int foreSpan,int caseNo,string st,string et);

[OperationContract]

//保存预报结果

Stream SaveForeResultData(ForecastStationInfo foreStationInfo,int workDt,int addpNum,string baseTime,string userName);

[OperationContract]

//计算最大洪量

Stream CalcHQFlood(HQVAL q,string st,string et,int dt);

(2)数据契约

数据契约定义了数据交换格式,本方法把水文预报计算中的每一种参与计算的单元都作为单独的类型,指定数据契约,比如:雨量站、水文站、水库站、河道特征、蓄滞洪区等,并按照每种类型的特性,根据属性来定义数据契约,下例为蓄滞洪区的数据契约。

B)通过网络传输协议用于服务的请求和数据的传输。

目前很多的网络传输协议都可以用于服务的请求以及数据传输,包括HTTP、CP、MQ等等。考虑到本方法的通用性以及对多终端支持性,这里选择了HTTP协议作为数据传输协议。因为几乎所有操作系统和设备都支持HTTP协议,同时交互报文也比较简单。

由于利用了HTTP协议,本方法使用了类似REST(Representational State Transfer,表述性状态传递)的风格来调用服务,即所有的服务都是通过URL链接的形式发布,用户在调用时只需请求URL地址,填入相应的参数,就可以获得服务器的返回结果。比如访问“http://localhost:12079/Service1.svc/GetForecastStaionData”即可以获得所有预报站点信息。

此外,考虑到水文预报信息传输的特点,本方法并没有按照REST规定的四种HTTP协议请求(即:GET、PUT、POST、DELETE)来对应相关操作。由于水文预报需要进行大量的数据交互,传统的REST风格无法满足复杂结构的服务请求。因此本方法只使用了GET和POST两种请求来完成服务操作,其中GET请求用来表示发送的参数只包含基本数据类型的服务,POST请求用来表示发送的参数包含复杂数据类型的服务。

同时,考虑到数据传输量较大,本方法使用JSON格式来传递数据,减少不必要的信息量。JSON(JavaScript Object Notation)是一种轻量级的数据交换格式,相比XML数据传输量少,并且原生支撑JavaScript,方便取得数据后的解析工作。此外,在传输前,对原始的数据集进行序列化,再将得到的字节流进行压缩运算,来进一步减少传输的数据量,加快请求的响应速度。

压缩时采用了gzip压缩方式,gzip是前端比较常用的压缩方式,支持各种类型的Web服务和浏览器。gzip压缩率较高,对于普通的文本文件能够有70%~80%的压缩率,同时压缩带来的服务器开销很小。

服务描述为了让用户了解所有发布出来的服务的使用规范,本方法使用单独的帮助网页来详细描述服务的使用方法。包括服务的名称、地址、请求方式、参数等等。

C)计算服务器部署在分布式计算节点上,利用集群统一管理,通过负载均衡机制,保证用户的请求得到实时的响应。

本方法在部署时采用了分布式方案,提高计算的速度和处理效率。为了满足多用户对系统的大量请求,所有的计算服务都部署在分布式计算节点上,利用集群进行统一管理,通过负载均衡机制,保证用户的请求可以得到实时的响应。

计算服务器作为所有服务的访问入口,负责服务的分发以及集群的管理,分布式计算节点上部署着所有的预报计算、防洪调度以及各类查询的计算服务。用户的请求通过网页或其他系统传递到计算服务器,计算服务器的负载均衡机制实时监视所有计算节点的运行状况,找到负载最小的节点分发请求,当计算节点完成计算后再逐层返回。

实施例,如图2所示:

1、用户通过服务描述文档,获取所需服务的URL、报文协议以及数据结构,通过HTTP请求发送给计算服务器;

2、计算服务器在收到请求后,通过监视所管理的所有计算节点,找到当前负载最小的节点,转发服务请求;

3、计算节点收到数据后,调用计算模块进行计算,需要查询和存储数据则通过数据库连接池访问数据库进行数据的查询和保存,在计算完成后将计算结果返回计算服务器;

4、计算服务器在得到数据后,首先对数据进行系列化,然后对数据流进行压缩,压缩采用gzip压缩,保证兼容性。随后,将压缩后的数据返回给用户。

以上所举实施例为本发明的较佳实施方式,仅用来方便说明本发明,并非对本发明作任何形式上的限制,任何所属技术领域中具有通常知识者,若在不脱离本发明所提技术特征的范围内,利用本发明所揭示技术内容所作出局部变动或修饰的等效实施例,并且未脱离本发明的技术特征内容,均仍属于本发明技术特征的范围内。

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1