一种内外网通信方法及系统与流程

文档序号:22622581发布日期:2020-10-23 19:28阅读:174来源:国知局
一种内外网通信方法及系统与流程

本申请涉及通信领域,尤其涉及一种内外网通信方法及系统。



背景技术:

在特定的a类网络(ip地址为a类地址且只有穿透预设的强隔离装置和数据库才可以访问的网络,为了描述方便,以下称为“内网”)与外网(互联网)间的通讯中,内网应用与外网应用中都配置有内网数据库的相关信息,其中,内网应用调用内网数据库,把产生的信息写进内网数据库。外网应用通过强隔离装置访问内网数据库,获取内网应用产生的信息。

由于内网应用与外网应用都配置有内网数据库的相关信息,在内网数据库发生改变时,内网应用与外网应用不能正常工作,进而,降低内外网之间的通信效率。使得随着互联网业务及需求越来越多,内外网之间通过数据库进行通信的方式已不适应目前的业务需要。



技术实现要素:

本申请提供了一种内外网通信方法及系统,目的在于解决内外网通信效率低的问题。

为了实现上述目的,本申请提供了以下技术方案:

本申请提供了一种内外网通信方法,应用于内外网通信系统中的网关;所述内外网通信系统包括:第一网关、第二网关、强隔离装置和内网数据库;所述第一网关和所述第二网关中,一个网关为内网网关,另一个网关为外网网关;所述内网网关与所述内网数据库的第一地址连接;所述外网网关与所述内网数据库的第二地址连接;所述内网数据库的第二地址为所述第一地址经过所述强隔离装置得到的地址;

所述方法包括:

所述第一网关在接收到应用发送的用于指示访问端访问对端网络的http请求的情况下,将所述http请求保存在所述内网数据库;

所述第二网关在查询到所述内网数据库中的待处理http请求的情况下,将获取的所述待处理http请求的请求结果写入所述内网数据库中;所述待处理http请求为所述第一网关存储于所述内网数据库中的用于访问所述第二网关所在网络的未响应http请求;

所述第一网关在检测到所述内网数据库中存储有所述http请求的请求结果的情况下,输出所述请求结果给所述应用。

可选的,所述第二网关包括多个查询进程;任一查询进程用于查询所述内网数据库中的所述待处理http请求;所述方法还包括:

所述第二网关在任一所述查询进程查询到任一所述待处理http请求的情况下,为该待处理http请求设置预设标识;所述预设标识用于标记该待处理http请求正在被响应。

可选的,还包括:

所述第一网关每隔预设时长,将所述内网数据库中的已反馈请求结果的http请求进行迁移。

可选的,所述已反馈请求结果的http请求被迁移到预设表中;所述方法还包括:

所述第一网关在接收到对任一所述已反馈请求结果http请求的追溯指令的情况下,从所述预设表中查询该已反馈请求结果http请求。

本申请还提供了一种内外网通信系统,包括:第一网关、第二网关、强隔离装置和内网数据库;所述第一网关和所述第二网关中,一个网关为内网网关,另一个网关为外网网关;所述内网网关与所述内网数据库的第一地址连接;所述外网网关与所述内网数据库的第二地址连接;所述内网数据库的第二地址为所述第一地址经过所述强隔离装置得到的地址;

所述第一网关,用于在接收到应用发送的用于指示访问端访问对端网络的http请求的情况下,将所述http请求保存在所述内网数据库;

所述第二网关,用于在查询到所述内网数据库中的待处理http请求的情况下,将获取的所述待处理http请求的请求结果写入所述内网数据库中;所述待处理http请求为所述第一网关存储于所述内网数据库中的用于访问所述第二网关所在网络的未响应http请求;

所述第一网关,还用于在检测到所述内网数据库中存储有所述http请求的请求结果的情况下,输出所述请求结果给所述应用。

可选的,所述第二网关包括多个查询进程;任一查询进程用于查询所述内网数据库中的所述待处理http请求;

所述第二网关,还用于在任一所述查询进程查询到任一所述待处理http请求的情况下,为该待处理http请求设置预设标识;所述预设标识用于标记该待处理http请求正在被响应。

可选的,所述第一网关,还用于每隔预设时间,将所述内网数据库中的已反馈请求结果的http请求进行迁移。

可选的,所述第一网关与所述第二网关分别至少由admin程序和bootstrap程序两个程序组成;

所述admin程序,用于配置网关的预设规则;所述预设规则包括:路由规则、限流规则和路径重写规则;

所述bootstrap程序,用于按照所述预设规则,接收所述http请求,并对所述http请求进行响应。

可选的,所述admin程序,还用于在所述预设规则被重新配置后,将重新配置的规则,同步缓存在所述bootstrap程序中。

可选的,所述内网数据库为mysql数据库。

本申请所述的内外网通信方法及系统,第一网关在接收到应用发送的用于指示访问端访问对端网络的http请求的情况下,将http请求保存在内网数据库;第二网关在查询到内网数据库中的待处理http请求的情况下,将获取的待处理http请求的请求结果写入内网数据库中;第一网关在检测到内网数据库中存储有所述http请求的请求结果的情况下,输出请求结果给应用。

即本申请中,第一网关侧的应用只需将http请求发送给第一网关,并接收第一网关输出的请求结果,即第一网关侧的应用与内网数据库之间没有直接调用关系。第二网关获取待处理http请求的请求结果,并写入内网数据库中,即第二网关侧的应用无需直接调用内网数据库,将产生的消息写入内网数据库。即在本申请中,内网应用与外网应用都与内网数据库无直接关系,使得在数据库改变时,内网应用和外网应用还可以正常运转,因此,采用本申请的方案,在数据库发生改变时,可以提高内外网的通信效率,进而,适应目前的业务需求。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。

图1为本申请实施例公开的一种应用场景示意图;

图2为本申请实施例公开的一种内外网通信系统的结构示意图;

图3为本申请实施例公开的一种第一网关与第二网关的通信过程的流程图;

图4为本申请实施例公开的一种内外网通信方法的流程图。

具体实施方式

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

申请人在研究中发现,本申请实施例需要应用于特殊的网络环境,即内网和外网之间必须通过强隔离装置进行通信,由于强隔离装置必须以内网数据库为基础,因此,内网和外网之间必须基于强隔离装置和内网数据库进行通信,因此,传统的网关产品不适用于本申请的网络环境。因此,需要开发一种可以避免内外网应用的正常运行受数据库影响,并且,可以在内外网网络之间正常采用http协议进行通信的内外网通信系统。

图1为本申请实施例提供的一种应用场景示意图,包括:内网客户端、内网服务端、内外网通信系统、外网客户端和外网服务端。其中,内网客户端与内网服务端连接,外网客户端与外网服务端连接,并且,内网服务端与外网服务端分别与内外网通信系统连接。其中,连接可以为无线连接也可以为有线连接,本申请实施例不对具体的连接方式作限定。

其中,内网可以访问系统,外网也可以访问内网。对于外网访问内网,外网客户端向外网服务端发送请求,外网服务端通过内外网通信系统,获取到对内网的访问结果。对于内网访问外网,内网客户端向内网服务端发送访问请求,内网服务端通过内外网通信系统,获取到对外网的访问结果。即内外网通信系统实现内网服务端与外网服务端之间的通信。

图2为本申请实施例提供的一种内外网通信系统,包括:第一网关、第二网关、强隔离装置和内网数据库;其中,第一网关和第二网关中,一个网关为内网网关,另一个网关为外网网关。其中,内网网关与内网数据库的第一地址连接;外网网关与内网数据库的第二地址连接。其中,内网数据库的第二地址为第一地址经过该强隔离装置得到的地址。

目前,主流的数据库有两种oracle和mysql。由于本实施例所面临的使用环境比较复杂(内网和外网之间必须通过强隔离装置进行通信,由于强隔离装置必须以内网数据库为基础,因此,内网和外网之间必须基于强隔离装置和内网数据库进行通信),可能需要在多场景部署该通信系统,以及数据的绝对分离,所以需要一个轻量级的数据库。由于mysql为关系型数据库,适用于本申请实施例的应用场景,因此,本实施例的数据库选择mysql数据库,作为消息数据的存储载体。

在本实施例中,第一网关和第二网关也可称为indb-gateway。在本实施例中,无论是第一网关还是第二网关都至少包括admin程序(indb-gateway-admin)和bootstrap程序(indb-gateway-bootstrap)这两个程序。其中,这两个程序之间可以通过http轮询和websocket长连接等方式保持数据同步。

其中,admin程序用于配置网关的预设规则,其中,预设规则可以包括:路由规则、限流规则和路径重写规则,当然,在实际中,预设规则还可以包括其他内容,本实施例不对预设规则的具体内容作限定。bootstrap程序用于按照预设规则,接收http请求,并对http请求进行响应。具体的,bootstrap程序用来接收http请求,将http请求转发至indb-gateway-admin,indb-gateway-admin再按照在配置好的路由规则穿透强隔离发送至对应的内网或外网服务。

即本实施例对数据库和强隔离装置进行了统一封装。可以让内网的服务通过内网网关的indb-gateway-admin的配置向外网暴露,同时外网的服务也可以通过外网网关向内网直接暴露,暴露后可直接通过网关进行http的调用,使得互联网常用的http接口调用技术得以广泛应用,不再需要内网应用与外网应用通过调用数据库等方式进行通信。从而,本实施例提供的内外网通信系统能够高效率、低延迟、高并发和高稳定性的处理内外网间的通信。

由于本实施例可以利用http请求的特性,从而,实现了图片、文本在内外网之间的实时传输,从而丰富了内外网之间消息的传输类型。

基于上述关于内外网通信系统的结构,以下介绍内外网通信系统中第一网关和第二网关之间的通信过程。在本实施例中,第一网关和第二网关中一个网关为内网网关,另一个网关为外网网关。具体的,可以为第一网关为外网网关,第二网关为内网网关,当然,也可以为第一网关为内网网关,第二网关为外网网关,本实施例不对具体形式作限定。即本申请实施例提供的第一网关与第二网关之间的通信过程,即可以看作是内网访问外网的过程,可以看作是外网访问内网的过程。为了描述方便,本实施例以第一网关为外网网关,第二网关为内网网关为例,进行介绍。具体的,第一网关与第二网关之间的通信流程如图3所示,可以包括以下步骤:

s301、第一网关在接收到应用发送的用于指示访问端访问对端网络的http请求的情况下,将该http请求保存在内网数据库。

在本实施例中,向第一网关发送http请求的应用为第一网关侧的服务端。即外网服务端在接收到客户端发送的http请求的情况下,将该http请求发送给第一网关。

在本步骤中,第一网关将该http请求保存在内网数据库。

具体的,由于第一网关由admin程序和bootstrap程序组成,在本步骤中,bootstrap程序接收http请求,并按照admin程序配置的预设规则,将接收的http请求保存在内网数据库中。

s302、第一网关挂起该http请求。

在本实施例中,挂起该http请求的具体实现方式为现有技术,这里不再赘述。

s303、第二网关在查询到内网数据库中的待处理http请求的情况下,获取待处理http请求的请求结果。

在本实施例中,待处理http请求为第一网关存储于内网数据库中的用于访问第二网关所在网络的未响应http请求。需要说明的是,待处理http请求可能是多个http请求,包括第一网关存储于内网数据库的http请求。

可选的,在本实施例中,第二网关中的bootstrap程序对内网数据库中的http请求进行扫描,扫描出待处理http请求。对于扫描出的任意一个http请求,依据admin程序配置的预设规则,获取该http请求的请求结果。

可选的,bootstrap程序可以包括多个查询进程,其中,任一查询进程用于查询内网数据库中的待处理http请求。在实际中,不同的查询进程可能扫描到同一个待处理http请求,从而,出现多个不同的查询进程对一个待处理http请求的重复响应。为了避免该问题,在本实施例中,第二网关使用了在redis上做分布式锁的方式,保证了http请求只能被响应一次。具体的,第二网关在任一查询进程查询到任一待处理http请求的情况下,为该待处理http请求设置预设标识。其中,预设标识用于标记该待处理http请求正在被响应,从而,避免了其他查询进程查询到该待处理http请求进行响应。

s304、第二网关将获取的待处理http请求的请求结果写入内网数据库中。

在本实施例中,第二网关将获取的待处理http请求的请求结果写入内网数据库中,以便第一网关提取该http请求的请求结果。

s305、第一网关在检测到内网数据库中存储有该http请求的请求结果的情况下,输出请求结果给应用。

在本实施例中,第一网关在挂起该http请求后,检测内网数据库中是否存储有该http请求的请求结果,如果检测到,则将该http请求的请求结果反馈给外网的服务端。

具体的,由于第一网关包括admin程序和bootstrap程序,在本步骤中,第一网关中的bootstrap程序通过查询内网数据库是否存储有该http请求的请求结果。其中,bootstrap程序的具体查询实现方式为现有技术,这里不再赘述。

通过上述s301~s305可以看出,本申请中,第一网关侧的应用只需将http请求发送给第一网关,并接收第一网关输出的请求结果,即第一网关侧的应用与内网数据库之间没有直接调用关系。第二网关获取待处理http请求的请求结果,并写入内网数据库中,即第二网关侧的应用无需通过调用内网数据库,将产生的消息写入内网数据库。即在本申请实施例中,内网应用与外网应用都与内网数据库无直接关系,使得在数据库改变时,内网应用和外网应用还可以正常运转,因此,采用本申请的方案,在数据库发生改变时,可以提高内外网的通信效率,进而,适应目前的业务需求。

同时,由于内网应用和外网应用无需直接调用内网数据库,使得内网系统(内网应用和内网客户端)与外网系统(外网应用与外网客户端)之间不存在由于都调用内网数据库进行通信所导致的强耦合关系,因此,采用本申请实施例提供的内外网通信系统,可以降低内网系统和外网系统之间的耦合度。

s306、第一网关每隔预设时长,将内网数据库中已反馈请求结果的http请求进行迁移。

在本实施例中,在第一网关和第二网关运行一段时间后,出现对数据库的检索压力问题。因为随着时间的推移,内网数据库中的数据量会逐渐增大,使得对内网数据库检索压力也会逐渐增大。为了减小对内网数据库的检索压力,在本实施例中,第一网关每隔预设时长,将内网数据库中的已经处理完成的http请求迁移出内网数据库,即将内网数据库中的已反馈请求结果的http请求进行迁移。

需要说明的是,在本实施例中,本步骤是可选步骤。

可选的,可以迁移到预设表中,当然,在实际中,还可以迁移到其他空间,本实施例不对具体方式作限定。

其中,对于迁移到预设表中,可以实现在特定场景下,对某个已反馈请求结果的http请求进行追溯提供方便,从而保证业务的安全性。具体的,第一网关可以在接收到对任一已反馈请求结果http请求的追溯指令的情况下,从预设表中查询该已反馈请求结果http请求。

可选的,在本实施例中,为了保证第一网关和第二网关的扩展性和高并发性能。由于第一网关和第二网关都可以由两部分构成:indb-gateway-admin和indb-gateway-bootstrap。在实际中,无论是第一网关还是第二网关,如果访问压力持续增大时,可以采用多indb-gateway-admin和indb-gateway-bootstrap节点部署的方式,多个bootstrap节点通过http轮询和websocket长连接等与admin保持连接,这样就可以把访问压力分散到每个不同的bootstrap节点上,从而减轻单个bootstrap节点的访问压力。当调用压力增大时,还可以对bootstrap和admin进行集群化部署,以减轻调用压力。

可选的,在本实施例中,admin程序还用于在预设规则被重新配置后,将重新配置的规则,同步缓存在bootstrap程序中,使得本实施例中在对indb-gatewy-admin进行路由转发、限流、鉴权等配置内容热配置,点击发布后规则即可实时生效,无需再重启网关系统,进而可以适用于更多的应用场景。

可选的,本实施例提供的内外网通信系统中的第一网关和第二网关还可以支持sdk快速接入,这样可以节省学习成本,上手更快。并且,开发者只关注消息队列中间件本身问题。无需关注内外网问题。

可选的,相比于普通网关仅有转发等功能,本申请是实例提供的内外网通信系统中的第一网关和第二网关还支持接口的鉴权、接口的限流、dubbo接口的支持等功能。

图4为本申请实施例提供的一种内外网通信方法,该方法应用于图2所示的内外网通信系统,可以包括以下步骤:

s401、第一网关在接收到应用发送的用于指示访问端访问对端网络的http请求的情况下,将http请求保存在内网数据库。

本步骤的具体实现过程可以参考s301,这里不再赘述。

s402、第二网关在查询到内网数据库中的待处理http请求的情况下,将获取的待处理http请求的请求结果写入内网数据库中。

在本步骤中,待处理http请求为第一网关存储于内网数据库中的用于访问第二网关所在网络的未响应http请求。

其中,本步骤的具体实现方式可以参考s303,这里不再赘述。

s403、第一网关在检测到内网数据库中存储有http请求的请求结果的情况下,输出请求结果给所述应用。

本步骤的具体实现可以参考s305,这里不再赘述。

本申请实施例方法所述的功能如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算设备可读取存储介质中。基于这样的理解,本申请实施例对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该软件产品存储在一个存储介质中,包括若干指令用以使得一台计算设备(可以是个人计算机,服务器,移动计算设备或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:u盘、移动硬盘、只读存储器(rom,read-onlymemory)、随机存取存储器(ram,randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。

本说明书中各个实施例采用递进的方式描述,每个实施例重点说明的都是与其它实施例的不同之处,各个实施例之间相同或相似部分互相参见即可。

对所公开的实施例的上述说明,使本领域专业技术人员能够实现或使用本申请。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的,本文中所定义的一般原理可以在不脱离本申请的精神或范围的情况下,在其它实施例中实现。因此,本申请将不会被限制于本文所示的这些实施例,而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

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