CN114374743B - 支持多种服务发现机制的网关路由规则生成方法和系统 - Google Patents
支持多种服务发现机制的网关路由规则生成方法和系统 Download PDFInfo
- Publication number
- CN114374743B CN114374743B CN202210039004.5A CN202210039004A CN114374743B CN 114374743 B CN114374743 B CN 114374743B CN 202210039004 A CN202210039004 A CN 202210039004A CN 114374743 B CN114374743 B CN 114374743B
- Authority
- CN
- China
- Prior art keywords
- service
- area
- containerized
- routing rule
- gateway
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
本发明公开了一种支持多种服务发现机制的网关路由规则生成方法和系统，能够支持容器化区域和非容器化区域的服务发现，以实现容器化区域和非容器化区域之间服务访问互联互通。其技术方案为：一方面同时支持容器化区域和非容器化区域的服务发现机制，在容器化区域基于kubernetes dns实现服务注册与发现，在非容器化区域基于zookeeper实现服务注册与发现，然后支持在这两种模式下分别生成并建立网关路由规则，向服务注册中心(kubernetes dns或zookeeper)创建外部服务。另一方面在支持并兼容容器化和非容器化区域的两种服务发现机制的基础上，通过建立各区域网关路由规则，能够支持任意两个区域之间，尤其是容器化区域和非容器化区域之间的服务访问互联互通。
Description
技术领域
本发明涉及网关路由技术，具体涉及一种可支持多种服务发现机制的网关路由规则生成方法和系统。
背景技术
由于金融企业对网络安全的要求较高，在金融企业内部，一般会按照安全等级划分形成多个网络区域，每个网络区域分别有多个服务，这些服务之间存在着大量的访问调用，既有同一网络区域内部的服务访问调用，也有跨网络区域的服务访问调用。各网络区域互联互通的场景如图1所示，为了避免跨网络区域的服务访问关系过于复杂，考虑在每个网络区域部署网关，要求所有跨网络区域的访问进出流量必须通过所部署的网关，这样网关成为了各个网络区域之间互联互通的重要枢纽，同时，它也承担着服务发现和路由转发的重要作用。
如图2所示，由于目前众多金融企业都在推进应用容器化技术落地，该过程将是一个持续而漫长的架构转型升级过程，对于企业内部多个网络区域而言，有些网络区域已完成应用容器化架构转型，有些网络区域内仍然部署传统应用，而且容器化区域应用和非容器化区域应用之间必然存在着大量的访问调用，这样就需要网关同时支持容器化区域和非容器化区域的服务发现机制，同时实现容器化区域和非容器化区域之间的消息路由转发功能。
市场上有很多网关以消息中间件产品来实现，由于容器化区域和非容器化区域内部服务注册与发现机制存在较大差异，通常只能支持一种特定区域内部(容器化区域或非容器化区域)的服务发现机制。因此，对于网关而言，同时支持容器化区域和非容器化区域的服务发现，并在此基础上实现容器化区域和非容器化区域之间服务访问互联互通，在技术实现上是存在一定困难的。
因此，考虑研发一种支持多种服务发现机制的网关路由技术，支持容器化区域和非容器化区域的服务发现，以实现容器化区域和非容器化区域之间服务访问互联互通，是业内亟待解决的问题。
发明内容
以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。
本发明的目的在于解决上述问题，提供了一种支持多种服务发现机制的网关路由规则生成方法和系统，能够支持容器化区域和非容器化区域的服务发现，以实现容器化区域和非容器化区域之间服务访问互联互通。
本发明的技术方案为：本发明揭示了一种支持多种服务发现机制的网关路由规则生成方法，方法包括：
步骤1：获取全局区域服务信息，以键值对形式保存在缓存中，键值对中的键为服务名，值为服务所在的区域；
步骤2：判断当前网关运行模式是否是容器化模式，如果是容器化模式则跳转到步骤8，如果不是容器化模式则执行步骤3；
步骤3：查询当前区域服务注册中心的所有本区域服务，再执行步骤4；
步骤4：创建当前非容器化区域内部服务路由规则，再执行步骤5；
步骤5：向当前区域服务注册中心注册外部区域服务，再执行步骤6；
步骤6：创建跨区域服务路由规则，再执行步骤7；
步骤7：汇总非容器化区域的服务路由规则；
步骤8：查询当前区域服务注册中心的所有本区域服务，再执行步骤9；
步骤9：创建当前容器化区域内部服务路由规则，执行步骤10；
步骤10：向当前区域服务注册中心注册外部区域服务，执行步骤11；
步骤11：创建跨区域服务路由规则，执行步骤12；
步骤12：汇总容器化区域的服务路由规则。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤3中的服务注册中心是通过zookeeper的分布式服务框架来实现，zookeeper内部以键值对的形式存放服务地址信息，其中键值对中的键为服务名，值为服务所在的服务器地址和监听端口。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤4中的非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，对于步骤5中的外部区域服务，在zookeeper内部以键值对的形式来实现，其中键值对中的键为外部区域服务的服务名，值为当前区域网络的IP地址和端口。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤6中的创建是基于传统应用来实现，步骤6中的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤8中的服务注册中心是通过kubernetes dns来实现，kubernetes dns内部以键值对形式存放服务地址信息，其中键为服务名.名称空间名，值为服务对应的集群内部虚地址和pod端口。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤9中的容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名。
根据本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例，步骤11中的创建是基于kubernetes集群实现，所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
本发明还揭示了一种支持多种服务发现机制的网关路由规则生成系统，系统包括全局区域服务信息获取模块、网关运行模式判断模块、容器化模式处理模块、非容器化模式处理模块，其中：
全局区域服务信息获取模块，配置为获取全局区域服务信息，以键值对形式保存在缓存中，键值对中的键为服务名，值为服务所在的区域；
网关运行模式判断模块，配置为判断当前网关运行模式是否是容器化模式，如果是容器化模式则运行容器化模式处理模块，如果是非容器化模式则运行非容器化模式处理模块；
非容器化模式处理模块，用于实现服务应用在非容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前非容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总非容器化区域的服务路由规则；
容器化模式处理模块，用于实现服务应用在容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总容器化区域的服务路由规则。
根据本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例，非容器化模式处理模块的配置中，服务注册中心是通过zookeeper的分布式服务框架来实现，zookeeper内部以键值对的形式存放服务地址信息，其中键值对中的键为服务名，值为服务所在的服务器地址和监听端口。
根据本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例，非容器化模式处理模块的配置中，非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
根据本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例，非容器化模式处理模块的配置中，外部区域服务在zookeeper内部以键值对的形式来实现，其中键值对中的键为外部区域服务的服务名，值为当前区域网络的IP地址和端口。
根据本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例，容器化模式处理模块的配置中，服务注册中心是通过kubernetes dns来实现，kubernetes dns内部以键值对形式存放服务地址信息，其中键为服务名.名称空间名，值为服务对应的集群内部虚地址和pod端口。
根据本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例，容器化模式处理模块的配置中，容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
本发明对比现有技术有如下的有益效果：本发明一方面同时支持容器化区域和非容器化区域的服务发现机制，在容器化区域基于kubernetes dns实现服务注册与发现，在非容器化区域基于zookeeper实现服务注册与发现，然后支持在这两种模式下分别计算并建立网关路由规则，向服务注册中心(kubernetes dns或zookeeper)创建外部服务。另一方面在支持并兼容容器化和非容器化区域的两种服务发现机制的基础上，通过建立各区域网关路由规则，能够支持任意两个区域之间，尤其是容器化区域和非容器化区域之间的服务访问互联互通。
附图说明
在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。
图1示出了各网络区域互联互通的场景的示意图。
图2示出了容器化区和非容器化区域互联互通的场景的示意图。
图3示出了服务注册与发现机制在非容器化区域的实现的示意图。
图4示出了服务注册与发现机制在容器化区域的实现的示意图。
图5示出了本发明的支持多种服务发现机制的网关路由规则生成方法的一个应用示例的示意图。
图6示出了本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例的流程图。
图7示出了本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例的原理图。
具体实施方式
以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。
图6示出了本发明的支持多种服务发现机制的网关路由规则生成方法的一实施例的流程。请参见图6，本实施例的方法的实施步骤详述如下。
步骤1：获取全局区域服务信息，以key-value(键值对)形式保存在缓存中，键值对中的键(key值)为服务名，值(value)为服务所在的区域。
其中，全局区域服务信息包含所有网络区域内的服务，通常是从数据库表或其他配置文件中获取。
步骤2：判断当前网关运行模式是否是容器化模式，如果是容器化模式则跳转到步骤8以实现服务应用在容器化模式下的服务注册与发现机制；如果不是容器化模式则执行步骤3以实现服务应用在非容器化模式下的服务注册与发现机制。
步骤3：查询当前区域服务注册中心(zookeeper)的所有本区域服务，执行步骤4。
服务应用在非容器化模式下的服务注册与发现机制通过zookeeper(分布式服务框架)来实现，zookeeper内部以key-value形式存放服务地址信息，其中key为服务名，value为服务所在的服务器地址和监听端口。
如图3所示，服务a-2分别向服务注册中心(zookeeper)注册它自己的IP地址和端口，当服务a-1需要访问服务a-2时，服务a-1从服务注册中心(zookeeper)获取到服务a-2的IP地址和端口，然后完成访问调用。
本步骤3中的本区域服务是指当前网络区域内的服务，而步骤1中所指的全局区域是所有区域，N个本区域服务的汇总就是全局区域服务；如果将全局区域的服务减去本区域的服务，就是外部区域服务。
对于本区域服务，从本区域(即当前区域)的zookeeper和kubernetes dns自动发现；对外部区域服务(即全局区域减去本区域的部分)，是由网关主动向zookeeper和kubernetes dns注册，具体分别参见步骤5和步骤10。
步骤4：创建当前非容器化区域内部服务路由规则，执行步骤5。
其中，非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口。
服务间访问调用一般通过http协议来实现，例如：某服务名为mics，访问该服务的url请求路径为http://172.31.203.201:32300/mics/xxx，访问该服务的请求头的path字段为“/mics/xxx”。
非容器化区域内部服务路由规则是：通过截取http请求头的path字段内容来进行路由匹配，因此，匹配条件为/服务名，即/mics，路由下一跳服务是目标服务mics的IP地址和端口。
步骤5：向当前区域服务注册中心(zookeeper)注册外部区域服务，其中键值对中的key值为外部区域服务的服务名，value值为当前区域网关的IP地址和端口，执行步骤6。
步骤6：创建跨区域服务路由规则，执行步骤7。
其中，创建是基于传统应用来实现，跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
步骤7：汇总非容器化区域的服务路由规则，整个方法的处理完成。
步骤8：查询当前区域服务注册中心(kubernetes dns)的所有本区域服务，执行步骤9。
容器化应用部署运行在docker+kubernetes容器云集群中，在容器云集群内部，服务应用的服务注册与发现机制一般通过kubernetes dns来实现，kubernetes dns内部以键值对(key-value)形式存放服务地址信息，其中key为服务名.名称空间名，value为服务对应的集群内部虚地址(集群cluster IP地址)和pod端口。如图4所示，服务b-2分别向服务注册中心(kubernetes dns)注册它自己的域名地址(服务名.名称空间名)，当服务b-1需要访问服务b-2时，服务b-1从服务注册中心(kubernetes dns)获取到服务b-2的cluster IP地址和pod端口，然后完成访问调用。
步骤9：创建当前容器化区域内部服务路由规则，执行步骤10。
其中，容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名。
步骤10：向当前区域服务注册中心(kubernetes dns)注册外部区域服务，执行步骤11。
步骤11：基于kubernetes集群创建跨区域服务路由规则，执行步骤12。
其中，跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
步骤12：汇总容器化区域的服务路由规则，整个方法的处理完成。
以下用图5所示的一个示例来说明算法的实现过程。
本发明的支持多种服务发现机制的网关路由规则生成方法，用以实现容器化区域与非容器化区域之间服务访问互联互通。以图5为例，假设存在以下2个跨区域调用链，分别来说明这两条请求调用链的处理逻辑。
调用链1(非容器化区域→容器化区域)：服务a-1→区域a网关→区域b网关→服务b-1；
调用链2(容器化区域→非容器化区域)：服务b-2→区域b网关→区域a网关→服务a-2。
本发明的支持多种服务发现机制的网关路由规则生成方法的前置条件如下：
条件1：每个区域的网关能够获取全局区域服务信息，其中key值为服务，value值为区域，即在处理跨区域请求时，可以从一个区域的网关上获取到目标服务所在的区域，然后将请求发给目标服务所在区域的网关。
条件2：服务a-1和服务a-2启动后向服务注册中心(zookeeper)注册本服务的IP地址和端口，非容器化区域a网关启动时，从服务注册中心(zookeeper)自动查找发现区域a中服务a-1和服务a-2的IP地址和端口；同时，区域a网关还会向服务注册中心(zookeeper)注册一条区域b中服务b-1的外部服务记录，这条记录的key值为b-1，value值为区域a网关的IP地址和端口。
条件3：服务b-1和服务b-2启动后向服务注册中心(kubernetes dns)注册本服务的kubernetes域名(其中key为服务名.名称空间名，value为虚拟集群cluster IP地址和pod端口)，容器化区域b网关启动时，从服务注册中心(kubernetes dns)自动查找发现区域b中服务b-1和服务b-2的kuebernetes域名；同时，区域b网关还会向服务注册中心(kubernetes dns)注册一条区域a中服务a-2的外部服务记录，这条记录的key值为a-2，value值为区域b网关的kubernetes域名。
上述的两个调用链(调用链1和调用链2)的处理流程如下。
调用链1(服务a-1→区域a网关→区域b网关→服务b-1，非容器化区域→容器化区域)的处理流程如下：
步骤1：服务a-1→区域a网关：服务a-1通过服务注册中心(zookeeper)找到服务b-1的记录(其实是区域a网关的IP地址和端口)，然后将请求发往区域a网关；
步骤2：区域a网关收到请求后，首先检查确认目标服务b-1不在本区域，然后找到目标服务b-1所在的区域是区域b，接着将请求发往区域b的网关上；
步骤3：区域b收到请求后，首先检查确认目标服务b-1在本区域，然后找到服务b-1的kuebernetes域名，将请求发往服务b-1完成调用访问。
调用链2(服务b-2→区域b网关→区域a网关→服务a-2，容器化区域→非容器化区域)的处理流程如下：
步骤1：服务b-2→区域b网关：服务b-2通过服务注册中心(kubernetes)找到服务a-2的记录(其实是区域b网关的域名)，然后将请求发往区域b网关；
步骤2：区域b网关收到请求后，首先检查确认目标服务a-2不在本区域，然后找到目标服务a-2所在的区域是区域a，接着将请求发往区域a的网关上；
步骤3：区域a收到请求后，首先检查确认目标服务a-2在本区域，然后找到服务a-2的IP地址和端口，将请求发往服务a-2完成调用访问。
图7示出了本发明的支持多种服务发现机制的网关路由规则生成系统的一实施例的原理。请参见图7，本实施例的系统包括：全局区域服务信息获取模块、网关运行模式判断模块、容器化模式处理模块、非容器化模式处理模块。
全局区域服务信息获取模块配置为获取全局区域服务信息，以键值对形式保存在缓存中，其中键(key)为服务，值(value)为服务所在的区域。
网关运行模式判断模块配置为判断当前网关运行模式是否是容器化模式，如果是容器化模式则运行容器化模式处理模块，如果是非容器化模式则运行非容器化模式处理模块。
非容器化模式处理模块用于实现服务应用在非容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前非容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总非容器化区域的服务路由规则。
非容器化模式处理模块的配置中，服务注册中心是通过zookeeper的分布式服务框架来实现，zookeeper内部以键值对的形式存放服务地址信息，其中键值对中的键为服务名，值为服务所在的服务器地址和监听端口。
非容器化模式处理模块的配置中，非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
非容器化模式处理模块的配置中，外部区域服务在zookeeper内部以键值对的形式来实现，其中键值对中的键为外部区域服务的服务名，值为当前区域网络的IP地址和端口。
容器化模式处理模块用于实现服务应用在容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总容器化区域的服务路由规则。
容器化模式处理模块的配置中，服务注册中心是通过kubernetes dns来实现，kubernetes dns内部以键值对形式存放服务地址信息，其中键为服务名.名称空间名，值为服务对应的集群内部虚地址和pod端口。
容器化模式处理模块的配置中，容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。
本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。
结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如DSP与微处理器的组合、多个微处理器、与DSP核心协作的一个或多个微处理器、或任何其他此类配置。
结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动盘、CD-ROM、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在ASIC中。ASIC可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。
在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(DSL)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、DSL、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(CD)、激光碟、光碟、数字多用碟(DVD)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。
提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。
Claims (14)
1.一种支持多种服务发现机制的网关路由规则生成方法，其特征在于，方法包括：
步骤1：获取全局区域服务信息，以键值对形式保存在缓存中，键值对中的键为服务名，值为服务所在的区域；
步骤2：判断当前网关运行模式是否是容器化模式，如果是容器化模式则跳转到步骤8，如果不是容器化模式则执行步骤3；
步骤3：查询当前区域服务注册中心的所有本区域服务，再执行步骤4；
步骤4：创建当前非容器化区域内部服务路由规则，再执行步骤5；
步骤5：向当前区域服务注册中心注册外部区域服务，再执行步骤6；
步骤6：创建跨区域服务路由规则，再执行步骤7；
步骤7：汇总非容器化区域的服务路由规则；
步骤8：查询当前区域服务注册中心的所有本区域服务，再执行步骤9；
步骤9：创建当前容器化区域内部服务路由规则，执行步骤10；
步骤10：向当前区域服务注册中心注册外部区域服务，执行步骤11；
步骤11：创建跨区域服务路由规则，执行步骤12；
步骤12：汇总容器化区域的服务路由规则。
2.根据权利要求1所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤3中的服务注册中心是通过zookeeper的分布式服务框架来实现，zookeeper内部以键值对的形式存放服务地址信息，其中键值对中的键为服务名，值为服务所在的服务器地址和监听端口。
3.根据权利要求2所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤4中的非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口。
4.根据权利要求3所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，对于步骤5中的外部区域服务，在zookeeper内部以键值对的形式来实现，其中键值对中的键为外部区域服务的服务名，值为当前区域网络的IP地址和端口。
5.根据权利要求4所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤6中的创建是基于传统应用来实现，步骤6中的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
6.根据权利要求1所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤8中的服务注册中心是通过kubernetes dns来实现，kubernetes dns内部以键值对形式存放服务地址信息，其中键为服务名.名称空间名，值为服务对应的集群内部虚地址和pod端口。
7.根据权利要求6所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤9中的容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名。
8.根据权利要求7所述的支持多种服务发现机制的网关路由规则生成方法，其特征在于，步骤11中的创建是基于kubernetes集群实现，所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
9.一种支持多种服务发现机制的网关路由规则生成系统，其特征在于，系统包括全局区域服务信息获取模块、网关运行模式判断模块、容器化模式处理模块、非容器化模式处理模块，其中：
全局区域服务信息获取模块，配置为获取全局区域服务信息，以键值对形式保存在缓存中，键值对中的键为服务名，值为服务所在的区域；
网关运行模式判断模块，配置为判断当前网关运行模式是否是容器化模式，如果是容器化模式则运行容器化模式处理模块，如果是非容器化模式则运行非容器化模式处理模块；
非容器化模式处理模块，用于实现服务应用在非容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前非容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总非容器化区域的服务路由规则；
容器化模式处理模块，用于实现服务应用在容器化模式下的服务注册与发现机制，配置为执行以下的处理：查询当前区域服务注册中心的所有本区域服务，创建当前容器化区域内部服务路由规则，向当前区域服务注册中心注册外部区域服务，创建跨区域服务路由规则，汇总容器化区域的服务路由规则。
10.根据权利要求9所述的支持多种服务发现机制的网关路由规则生成系统，其特征在于，非容器化模式处理模块的配置中，服务注册中心是通过zookeeper的分布式服务框架来实现，zookeeper内部以键值对的形式存放服务地址信息，其中键值对中的键为服务名，值为服务所在的服务器地址和监听端口。
11.根据权利要求10所述的支持多种服务发现机制的网关路由规则生成系统，其特征在于，非容器化模式处理模块的配置中，非容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的IP地址和端口；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的IP地址和端口。
12.根据权利要求11所述的支持多种服务发现机制的网关路由规则生成系统，其特征在于，非容器化模式处理模块的配置中，外部区域服务在zookeeper内部以键值对的形式来实现，其中键值对中的键为外部区域服务的服务名，值为当前区域网络的IP地址和端口。
13.根据权利要求9所述的支持多种服务发现机制的网关路由规则生成系统，其特征在于，容器化模式处理模块的配置中，服务注册中心是通过kubernetes dns来实现，kubernetes dns内部以键值对形式存放服务地址信息，其中键为服务名.名称空间名，值为服务对应的集群内部虚地址和pod端口。
14.根据权利要求13所述的支持多种服务发现机制的网关路由规则生成系统，其特征在于，容器化模式处理模块的配置中，容器化区域内部服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是目标服务的kubernetes域名；所创建的跨区域服务路由规则是：匹配条件为“/服务名”，路由下一跳服务是本区域网关的kubernetes域名。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210039004.5A CN114374743B (zh) | 2022-01-13 | 2022-01-13 | 支持多种服务发现机制的网关路由规则生成方法和系统 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202210039004.5A CN114374743B (zh) | 2022-01-13 | 2022-01-13 | 支持多种服务发现机制的网关路由规则生成方法和系统 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN114374743A CN114374743A (zh) | 2022-04-19 |
| CN114374743B true CN114374743B (zh) | 2023-08-22 |
Family
ID=81143400
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202210039004.5A Active CN114374743B (zh) | 2022-01-13 | 2022-01-13 | 支持多种服务发现机制的网关路由规则生成方法和系统 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN114374743B (zh) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115250197B (zh) * | 2022-06-02 | 2024-04-12 | 苏州思萃工业互联网技术研究所有限公司 | 一种自动化创建容器发现服务的装置 |
| CN115695319B (zh) * | 2022-11-01 | 2024-08-16 | 上海金融期货信息技术有限公司 | 支持多优先级策略的网关路由规则计算方法 |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106302596A (zh) * | 2015-06-03 | 2017-01-04 | 北京京东尚科信息技术有限公司 | 一种服务发现的方法和装置 |
| WO2019100605A1 (zh) * | 2017-11-21 | 2019-05-31 | 平安科技（深圳）有限公司 | 平台即服务paas容器平台的构建方法、服务器、系统及存储介质 |
| WO2020147396A1 (zh) * | 2019-01-17 | 2020-07-23 | 平安科技（深圳）有限公司 | 服务域名的动态配置方法、装置、设备及存储介质 |
| CN111722883A (zh) * | 2020-06-12 | 2020-09-29 | 浪潮电子信息产业股份有限公司 | 一种接口地址的更新方法、装置和计算机可读存储介质 |
Family Cites Families (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107667517B (zh) * | 2015-06-03 | 2021-03-19 | 瑞典爱立信有限公司 | 用于能够实现第二容器上的反向代理的在第一服务容器内的被植入代理器 |
| US11153279B2 (en) * | 2020-01-30 | 2021-10-19 | Hewlett Packard Enterprise Development Lp | Locally representing a remote application programming interface (API) endpoint within an application platform |
-
2022
- 2022-01-13 CN CN202210039004.5A patent/CN114374743B/zh active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106302596A (zh) * | 2015-06-03 | 2017-01-04 | 北京京东尚科信息技术有限公司 | 一种服务发现的方法和装置 |
| WO2019100605A1 (zh) * | 2017-11-21 | 2019-05-31 | 平安科技（深圳）有限公司 | 平台即服务paas容器平台的构建方法、服务器、系统及存储介质 |
| WO2020147396A1 (zh) * | 2019-01-17 | 2020-07-23 | 平安科技（深圳）有限公司 | 服务域名的动态配置方法、装置、设备及存储介质 |
| CN111722883A (zh) * | 2020-06-12 | 2020-09-29 | 浪潮电子信息产业股份有限公司 | 一种接口地址的更新方法、装置和计算机可读存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN114374743A (zh) | 2022-04-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN114374743B (zh) | 支持多种服务发现机制的网关路由规则生成方法和系统 | |
| US8582469B2 (en) | Peer-to-peer network including routing protocol enhancement | |
| Caprolu et al. | Fortress: an efficient and distributed firewall for stateful data plane sdn | |
| US8291077B2 (en) | Provision of services over a common delivery platform such as a mobile telephony network | |
| US20140122572A1 (en) | Enterprise service bus routing system | |
| US9294867B2 (en) | Provision of services over a common delivery platform such as a mobile telephony network | |
| JP2006109407A (ja) | コールの再構成時にコール・コンポーネントをマージするための方法および装置 | |
| KR20160148650A (ko) | 트랜잭셔널 미들웨어 머신 환경에서 도메인에 걸친 메시징을 위해 바이패스-도메인 모델 및 프록시 모델을 지원하고 서비스 정보를 갱신하는 시스템 및 방법 | |
| US20130159374A1 (en) | Method And Apparatus For Messaging In The Cloud | |
| CN112737860B (zh) | 裸金属服务器vxlan接入的方法及计算机可读介质 | |
| US9935791B2 (en) | Method and system for name resolution across heterogeneous architectures | |
| WO2021136634A1 (en) | Association with a network data analytics function | |
| US20060161616A1 (en) | Provision of services over a common delivery platform such as a mobile telephony network | |
| CN113676564A (zh) | 数据传输方法、装置及存储介质 | |
| CN114490393A (zh) | 一种单集群多租户管理系统 | |
| EP3884647A2 (en) | Methods of operating service control nodes | |
| WO2024148877A1 (zh) | 一种实现集群的服务拓扑感知的方法、装置、设备及介质 | |
| CN113254227B (zh) | 跨数据中心的远程方法调用的方法、系统 | |
| CN113839876B (zh) | 一种内部网络的传输路径优化方法及设备 | |
| US8743694B2 (en) | Determination of bypass zones from network configuration settings | |
| CN111147621B (zh) | 一种支持外网用户进行IPv6业务访问的方法 | |
| CN116800605B (zh) | 在容器中运行虚拟机的网络实现方法、系统、设备及介质 | |
| CN115695319B (zh) | 支持多优先级策略的网关路由规则计算方法 | |
| CN115514805B (zh) | 基于统一访问规则的多注册中心微服务发现方法和系统 | |
| CN117692255B (zh) | 动态扩展aaa服务的方法、装置及电子设备 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |