CN113206866A - 一种多区域场景下服务提供方法、装置及存储介质 - Google Patents

Abstract

本公开提供一种多区域场景下服务提供方法、装置及存储介质，用于解决云计算服务平台的安全性和可维护性低的技术问题。本公开在多区域云计算服务平台中，增加请求路由模块，基于预配置的转发规则，由请求路由模块将携带区域标识和服务标识的服务请求转发给相应区域中的服务网关，由服务网关基于转发规则将请求派发给对应的服务模块。通过本公开技术方案使得云计算服务平台中的每个区域对外仅需暴露一个端口，通过服务标识及规则能够实现多区域内的服务模块的互访，从而提升了系统的安全性，降低了维护复杂度。

Description

一种多区域场景下服务提供方法、装置及存储介质

技术领域

本公开涉及通信及云计算技术领域，尤其涉及一种多区域场景下服务提供方法、装置及存储介质。

背景技术

OpenStack是一个开源的云计算管理平台项目，是一系列软件开源项目的组合。OpenStack为私有云和公有云提供可扩展的弹性的云计算服务。

Keystone为OpenStack的基础支持服务，主要功能包括管理用户及其权限、维护OpenStack Services的Endpoint(服务入口)、Authentication(认证)和Authorization(鉴权)等。

Kubernetes(简称K8s)是一个应用于容器集群的自动化部署、扩容以及运维的开源平台。通过K8s，可以快速有效地响应用户需求；快速而有预期地部署应用；无缝对接新应用功能；节省资源，优化硬件资源的使用。为容器编排管理提供了完整的开源方案。

OpenStack多区域(region)是指多套OpenStack共享一个安装部署认证服务(keystone)和Horizon，每个区域一套OpenStack环境，可以分布在不同的地理位置，提供环境隔离功能，选择创建虚拟机的时候可以根据自己所处的位置就近选择。每个region都有个完整的OpenStack部署环境，regions之间完全隔离，region内的OpenStack组件注册自己的endpoint(服务入口)到keystone。不同的region可共享一套keystone和Horizon来提供用户的访问控制与界面操作。

在现有的多region场景中，在通过一个region的OpenStack环境直接访问另一个region的服务时，需要另一个region对应的OpenStack环境放开每个被访问服务的端口，这会带来安全隐患且带来维护上的困难。此外，不同的服务暴露不同的端口号，上层封装业务时调用后台OpenStack组件API时需要区分端口，在产品设计和代码实现上也会带来不必要的困难，降低产品和代码的可维护性。

发明内容

有鉴于此，本公开提供一种多区域场景下服务提供方法、装置及存储介质，用于解决云计算服务平台的安全性和可维护性低的技术问题。

图1为本公开提供的多区域场景下服务提供方法的步骤流程图，该方法应用于包含多个区域的云计算服务平台，该方法包括：

步骤101.以与区域绑定的IP地址和端口接收服务请求，所述服务请求中携带有所请求的服务所在区域的区域标识和服务标识；

本公开中每个区域对外提供服务时仅对外暴露与区域绑定的IP地址和服务端口，本区域内部的服务的IP地址和端口以及其它区域的服务的IP地址和端口都不对外暴露。

步骤102.基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关，所述区域转发规则中包括区域标识与区域IP地址的对应关系；

本公开在区域内预先配置有包括区域标识与区域IP地址的对应关系的区域转发规则，当接收到服务请求时，根据服务请求中的区域标识匹配对应的区域转发规则，将服务请求转发给对应区域中的服务网关。

进一步地，基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关方法为：

从所述服务请求中提取区域标识；

使用所提取的区域标识匹配区域转发规则，若匹配成功则从区域转发规则中获取区域IP地址，修改所述服务请求，将所述服务请求重定向到所获取的区域IP地址指向的区域中的服务网关和服务网关端口。

步骤103.基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理，所述服务转发规则中包括服务标识与区域中服务模块地址和端口的对应关系；

本公开在区域内预先配置有包括服务标识与区域内服务模块地址和端口的对应关系的服务转发规则，服务网关基于接收到服务请求后基于服务请求中的服务标识匹配对应的服务转发规则，将服务请求转发给对应的服务模块进行处理。服务模块用于对服务请求进行最终的业务处理，并向请求方反馈处理结果。

进一步地，基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理的方法为：

从所述的服务请求中提取服务标识；

使用所提取的服务标识匹配服务转发规则，若匹配成功则从服务转发规则中获取服务模块地址和端口，修改服务请求，将所述服务请求重定向到所获取的服务模块地址和端口。

进一步地，所述多个区域的云计算服务平台共用一套认证模块，未包括认证模块的区域中对认证模块的请求，通过预配置的包括区域标识与区域IP地址的对应关系的转发规则转发到部署认证模块的区域当中，由部署认证模块的区域当中认证模块进行处理。

进一步地，所述云计算服务平台采用OpenStack云计算管理平台进行管理，所述认证模块采用Keystone实现，所述服务请求的路由转发采用Ingress-nginx实现，所述规则配置采用Ingress实现。

图2为本公开提供的一种多区域场景下服务提供装置结构示意图，该装置200中的各功能模块可以采用软件、硬件或软硬件相结合的方式实现。各模块可部署在一个硬件设备上实施上述方法的所有步骤，也可分散部署在不同硬件设备上由多个硬件设备分别实施上述方法中的一个或若干步骤从而共同实施以实现本公开的发明目的。当由多个硬件设备共同实施时，由于各硬件设备之间相互协作的目的是共同实现本发明目的，一方的动作和处理结果确定了另一方的动作执行的时机及可能获得的结果，因此，在逻辑上可视为各模块彼此之间具有相互指挥和控制关系。该装置200应用于包含多个区域的云计算服务平台，该装置200包括：

请求路由模块210，用于以与区域绑定的IP地址和端口接收服务请求，所述服务请求中携带有所请求的服务所在区域的区域标识和服务标识；基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关，所述区域转发规则中包括区域标识与区域IP地址的对应关系；

规则解析模块220，用于存储预配置的区域转发规则、服务转发规则；

服务网关230，用于基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理，所述服务转发规则中包括服务标识与区域中服务模块地址和端口的对应关系。

进一步地，所述装置200还包括：

认证模块，用于处理本区域内的认证请求以及由其它未部署认证模块的区域转发过来的认证请求，未部署认证模块的区域中的认证请求通过其区域内预配置的包括区域标识与区域IP地址的对应关系的转发规则转发到部署认证模块的区域当中认证模块，由部署认证模块的区域当中认证模块进行处理。

进一步地，所述请求路由模块210包括：

区域标识提取模块，用于从所述服务请求中提取区域标识；

区域转发匹配模块，用于使用所提取的区域标识匹配区域转发规则，若匹配成功则从区域转发规则中获取区域IP地址；

区域转发执行模块，用于根据所获取的区域IP地址修改所述服务请求，将所述服务请求重定向到所获取的区域IP地址指向的区域中的服务网关和服务网关端口。

进一步地，所述服务网关230包括：

服务标识提取模块，用于从所述的服务请求中提取服务标识；

服务转发匹配模块，用于使用所提取的服务标识匹配服务转发规则，若匹配成功则从服务转发规则中获取服务模块地址和端口；

服务转发执行模块，用于根据所获取的服务模块地址和端口，修改服务请求，将所述服务请求重定向到所获取的服务模块地址和端口。

进一步地，所述云计算服务平台采用OpenStack云计算管理平台进行管理，所述认证模块采用Keystone，所述请求路由模块210采用Ingress-nginx，所述规则解析模块220采用Ingress。

图3为本公开一实施例提供的一种电子设备结构示意图，该设备300包括：诸如中央处理单元(CPU)的处理器310、通信总线320、通信接口340以及存储介质330。其中，处理器310与存储介质330可以通过通信总线320相互通信。存储介质330内存储有计算机程序，当该计算机程序被处理器310执行时即可实现本公开提供的方法的各步骤。

其中，存储介质可以包括随机存取存储器(Random Access Memory，RAM)，也可以包括非易失性存储器(Non-Volatile Memory，NVM)，例如至少一个磁盘存储器。另外，存储介质还可以是至少一个位于远离前述处理器的存储装置。处理器可以是通用处理器，包括中央处理器(Central Processing Unit，CPU)、网络处理器(Network Processor，NP)等；还可以是数字信号处理器(Digital Signal Processing，DSP)、专用集成电路(ApplicationSpecific Integrated Circuit，ASIC)、现场可编程门阵列(Field-Programmable GateArray，FPGA)或其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。

本公开在多区域云计算服务平台中，增加请求路由模块，基于预配置的转发规则，由请求路由模块将携带区域标识和服务标识的服务请求转发给相应区域中的服务网关，由服务网关基于转发规则将请求派发给对应的服务模块。通过本公开技术方案使得云计算服务平台中的每个区域对外仅需暴露一个端口，通过服务标识及规则能够实现多区域内的服务模块的互访，从而提升了系统的安全性，降低了维护复杂度。

附图说明

为了更加清楚地说明本公开实施例或者现有技术中的技术方案，下面将对本公开实施例或者现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本公开中记载的一些实施例，对于本领域普通技术人员来讲，还可以根据本公开实施例的这些附图获得其他的附图。

图1为本公开提供的多区域场景下服务提供方法的步骤流程图；

图2为本公开提供的一种多区域场景下服务提供装置结构示意图；

图3为本公开一实施例提供的一种电子设备结构示意图；

图4为本公开一实施例提供的多区域场景下服务提供方法中区域结构及请求处理步骤的示意图；

图5为本公开一实施例提供的服务请求由本区域内部服务模块提供服务的处理步骤流程图；

图6为本公开一实施例提供的服务请求由其它区域内的服务模块提供服务的处理步骤流程图。

具体实施方式

在本公开实施例使用的术语仅仅是出于描述特定实施例的目的，而非限制本公开实施例。本公开实施例中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其它含义。本公开中使用的术语“和/或”是指包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本公开实施例可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开实施例范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，此外，所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

云计算管理平台(例如OpenStack)通常支持多区域(region)配置，以两个区域RegionOne、RegionTwo为例，两个区域内的两套云计算环境可共用一套认证系统(例如keystone)，可实现通过一个后台管理平台同时管理两个区域中的两套云计算业务系统。

目前，在以Openstack+Keystone为例的在多区域组网环境中，首先需在keystone服务上注册每个组件的服务入口即endpoint(endpoint可看作是一个服务暴露出来的访问入口，通常是一个URL)，endpoint包含的属性包括：服务类型(例如计算compute服务类型)、服务名称(例如计算服务名为nova)、区域region、endpoint url(例如http://{IP}:8774/v2.1),以及接口类型(此类型表明当前endpoint url的权限，接口类型包含pubic，admin和internal三种类型)。在注册组件的endpoint后，需要在每个OpenStack环境中，修改每个组件对应配置文件中的配置，增加其对应注册到keystone的region的配置信息，比如，一套OpenStack环境在keystone中注册的endpoint属于RegionTwo，那此套环境中的计算服务(nova)、网路服务(neutron)、块存储服务(cinder)、镜像服务(glance)等配置文件[keystone_authtoken]段中需增加region_name＝“RegionTwo”的配置。在修改完配置后重启服务使配置生效。通过上述方法可保证在区域region之间进行服务互访时，能通过此区域配置找到本区域内对应的服务的服务入口endpoint进行API访问。

在上述多region场景中，在通过RegionOne的OpenStack环境直接访问RegionTwo中的服务时，要求RegionTwo对应的OpenStack环境放开每个被访问服务的端口，这会带来安全隐患且带来维护上的困难。不同的服务暴露不同的端口号，上层封装业务时调用后台OpenStack组件API时需要区分端口，这在产品设计和代码实现上也会带来不必要的困难，降低产品和代码的可维护性。

为克服上述多区域云计算场景中存在的技术问题，提高云计算业务系统的安全性、可维护性，提高多区域云计算场景对外业务接口的统一性，本公开提供了一种多区域云计算场景下服务提供方法，以下结合具体实施例对本公开的技术方案进行详细说明。

图4为本公开一实施例提供的多区域场景下服务提供方法中区域结构及请求处理步骤的示意图，该实施例中，完整部署了两个区域region的OpenStack环境，环境访问地址分别为IP1和IP2。IP1的OpenStack各组件服务设置于区域RegionOne，IP2的OpenStack各组件服务设置于区域RegionTwo。

该实施例中，两个区域可共用一套认证模块，认证模块可采用keystone认证系统，区域内的各服务模块(例如compute-node计算服务模块、network-node网络服务模块等)可以根据真实的Region在相应的配置文件的[keystone_authtoken]段中增加region_name＝“RegionOne”或者region_name＝“RegionTwo”。

在共用一套认证模块的情况下，为了区别不同区域里的服务模块，需在认证模块keystone里增加区域Region配置信息。ip1环境部署完后，keystone中已有RegionOne，再在此keystone中添加RegionTwo(注意，此时Region配置并不体现ip地址信息)。关掉ip2环境的keystone服务，修改此环境中keystone的后端服务为ip1环境中的keystone服务，让ip2环境内OpenStack服务模块对keystone服务的访问转发到ip1环境的keystone服务上，使ip2环境中的OpenStack服务模块对接keystone的配置不需要做任何修改，就可以访问到ip1环境的keystone服务，实现两个region环境共用一个keystone服务能力。

在执行该实施例提供的多区域云计算场景下服务提供方法之前，需要首先在各区域region中的规则解析模块进行配置，在RegionOne即ip1环境的规则解析模块1中配置相应的入口ingress的规则，使得带有/api/RegionOne的服务请求转发到RegionOne自己的服务网关1，带有/api/RegionTwo的服务请求转发到远端ip2环境中的服务网关2。RegionTwo即ip2环境中的规则的配置与ip1的规则配置正好相反，带有/api/RegionOne的服务请求转发到远端ip1环境中的服务网关1，带有/api/RegionTwo的服务请求转发到自己的服务网关2。

在本公开实施例中，每个区域对外只暴露一个服务端口，不同的区域对外暴露的服务端口可以相同也可以不同，在图示实施例中，两个区域对外暴露的服务端口都为443。本公开实施例通过添加请求路由模块来对外屏蔽内部服务的服务端口，请求路由模块基于规则解析模块的解析结果，将API服务请求转发给本地API服务网关或其它区域的API服务网关。规则解析模块的规则中配置有区域region与IP地址的对应关系，根据配置规则，发给IP1的443端口的服务请求中，如果未携带或携带RegionOne的区域标识，则该服务请求会被转发到RegionOne中的对应服务模块进行处理，如果携带RegionTwo的区域标识，则该服务请求会被转发到RegionTwo中的对应服务模块进行处理。

以下分别对服务请求者向RegionOne中的计算服务发起服务请求和向RegionTwo中的网络服务发起请求的处理过程进行描述。

首先描述服务请求者向RegionOne发起计算服务请求，请求RegionOne中的计算模块提供计算服务时，RegionOne对外提供服务的处理过程如图5所示：

步骤501.请求路由模块1接收到服务请求1，服务请求1中携带所请求的服务所在区域的区域标识为RegionOne；

该实施例中，服务请求1为URL形式，用于请求RegionOne区域内的计算服务，示例如下：

http://ip1:443/api/RegionOne/Compute/xxx

其中，“ip1：443”为RegionOne对外提供服务的IP地址及端口，请求路由模块1基于请求中的IP地址及端口判断所述服务请求是否发给自己的，如果是发给自己的则继续处理，否则丢弃该服务请求，不做处理。

“RegionOne”为所请求的服务所在区域的区域识，“api/RegionOne/Compute/xxx”用于指示所请求的计算服务位于RegionOne的区域路径。

步骤502.请求路由模块1根据规则解析模块1中配置的区域转发规则确定负责处理服务请求1的服务网关为服务网关1，并将服务请求转发给服务网关1；

该实施例中，规则解析模块1中配置有如下区域转发规则：

“/api/RegionOne/xxx->转发到os-kong-proxy-svc:11000，接口变为/xxx”

其作用是将发给RegionOne的API服务请求转发到本地的名称为os-kong-proxy-svc端口为11000的服务网关，服务请求中的“/api/RegionOne/xxx”的部分将会被修改为“/xxx”。

例如服务请求“http://ip1:443/api/RegionOne/Compute/xxx”在经过规则解析后，被修改为“http://os-kong-proxy-svc:11000/Compute/xxx”发送给RegionOne中的服务网关os-kong-proxy-svc进行处理。

步骤503.服务网关1接收到服务请求1后，根据规则解析模块1中配置的服务转发规则确定处理服务请求1的服务模块为服务模块11，并将服务请求转发给服务模块11；

该实施例中，规则解析模块1中配置有如下服务转发规则：

“/compute/xxx->转发到compute-node:8774，接口变为/xxx”

该转发规则的作用是将请求中带有“compute”服务标识的服务请求转发给服务模块compute-node节点处理，对应的端口号为8774，服务请求中的“/compute/xxx”的部分将会被修改为“/xxx”。

例如将“http://os-kong-proxy-svc:11000/Compute/xxx”修改为“http://compute-node:8774/xxx”发送给服务模块11对应服务节点及端口号为compute-node:8774。

至此，完成了针对RegionOne中计算服务调用。

接下来描述服务请求者向RegionOne发起网络服务请求，请求RegionTwo中的网络模块提供网络服务时，针对该服务请求的处理过程如图6所示：

步骤601.请求路由模块1接收到服务请求2，服务请求2中携带所请求的服务所在区域的区域标识为RegionTwo；

该实施例中，服务请求2为URL形式，用于请求RegionTwo区域内的网络服务，示例如下：

http://ip1:443/api/RegionTwo/Network/xxx

其中，“ip1：443”为RegionOne对外提供服务的IP地址及端口，请求路由模块1基于请求中的IP地址及端口判断所述服务请求是否发给自己的，如果是发给自己的则继续处理，否则丢弃该服务请求，不做处理。

“RegionTwo”为所请求的服务所在区域的区域标识，“api/RegionTwo/Network/xxx”用于指示所请求的网络服务位于RegionTwo的区域路径。

步骤602.请求路由模块1根据规则解析模块1中配置的区域转发规则确定负责处理服务请求2的服务网关为位于RegionTwo中的服务网关2，并将服务请求转发给服务网关2；

该实施例中，规则解析模块1中配置有如下区域转发规则：

“/api/RegionTwo/xxx->转发到ip2:11000，接口变为/xxx”

其作用是将发给RegionTwo的API服务请求转发到RegionTwo中的名称为os-kong-proxy-svc端口为11000的服务网关2，服务请求中的“/api/RegionTwo/xxx”的部分将会被修改为“/xxx”。

例如服务请求“http://ip1:443/api/RegionTwo/Network/xxx”在经过规则解析后，被修改为“http://ip2:11000/Network/xxx”发送给RegionTwo中的服务网关2进行处理。

步骤603.服务网关2接收到服务请求2后，根据RegionTwo内的规则解析模块2中配置的服务转发规则确定处理服务请求2的服务模块为服务模块22，并将服务请求转发给服务模块22；

该实施例中，规则解析模块2中配置有如下服务转发规则：

“/network/xxx->转发到network-node:9696，接口变为/xxx”

该转发规则的作用是将请求中带有“network”服务标识的服务请求转发给本区域内的服务模块network-node节点处理，对应的端口号为9696，服务请求中的“/network/xxx”的部分将会被修改为“/xxx”。

例如将“http://ip2:11000/network/xxx”修改为“http://network-node:9696/xxx”发送给RegionTwo中的服务模块22，对应服务节点及端口号为network-node:9696。

至此，完成了通过向RegionOne发起服务请求调用RegionTwo中的网络服务处理过程。

Ingress是对集群中服务的外部访问进行管理的应用程序接口API对象，典型的访问方式是HTTP协议方式。Ingress公开了从集群外部到集群内服务的HTTP和HTTPS路由，流量路由由Ingress资源上定义的规则控制。Ingress可以配置用于提供外部可访问的服务URL、负载均衡流量、SSL终端和提供虚拟主机名配置。本公开一实施例中，服务请求路由转发模块采用Ingress-nginx来实现，规则解析模块可采用Ingress中的规则控制模块来实现。

本公开实施例中，多区域例如RegionOne和RegionTwo可共用一套认证模块，例如可采用keystone作为认证模块，endpoint配置、租户、用户、角色、token等信息都可共享。假设认证模块位于RegionOne中，则RegionTwo中所有对认证模块的访问都可通过预配置的ingress转发规则转发到远端RegionOne的认证模块上，RegionTwo本地不会保留keystone认证数据库的数据。但很多场景，上层业务为了性能、易用性等原因，进行业务封装或者页面数据展示时经常会直接访问数据库，由于RegionTwo本地keystone认证数据库没有信息，会导致这类方法在RegionTwo环境使用受阻。因此、，本公开另一实施例中，可使用数据库同步的方式实时动态将RegionOne中的认证数据库数据同步到RegionTwo中的认证数据库，保持两个区域环境数据一致。例如ip1上运行一个服务(形式多样，不限制实现方法，监听进程、API接口等都可达到相同效果)，当ip1的keystone认证数据库发生写变化时，主动将数据库变化实时同步到ip2的keystone认证数据库，使得RegionTwo中的服务能够全量获取到ip1的keystone认证数据库的数据。

应当认识到，本公开的实施例可以由计算机硬件、硬件和软件的组合、或者通过存储在非暂时性存储器中的计算机指令来实现或实施。所述方法可以使用标准编程技术，包括配置有计算机程序的非暂时性存储介质在计算机程序中实现，其中如此配置的存储介质使得计算机以特定和预定义的方式操作。每个程序可以以高级过程或面向对象的编程语言来实现以与计算机系统通信。然而，若需要，该程序可以以汇编或机器语言实现。在任何情况下，该语言可以是编译或解释的语言。此外，为此目的该程序能够在编程的专用集成电路上运行。此外，可按任何合适的顺序来执行本公开描述的过程的操作，除非本公开另外指示或以其他方式明显地与上下文矛盾。本公开描述的过程(或变型和/或其组合)可在配置有可执行指令的一个或多个计算机系统的控制下执行，并且可作为共同地在一个或多个处理器上执行的代码(例如，可执行指令、一个或多个计算机程序或一个或多个应用)、由硬件或其组合来实现。所述计算机程序包括可由一个或多个处理器执行的多个指令。

进一步，所述方法可以在可操作地连接至合适的任何类型的计算平台中实现，包括但不限于个人电脑、迷你计算机、主框架、工作站、网络或分布式计算环境、单独的或集成的计算机平台、或者与带电粒子工具或其它成像装置通信等等。本公开的各方面可以以存储在非暂时性存储介质或设备上的机器可读代码来实现，无论是可移动的还是集成至计算平台，如硬盘、光学读取和/或写入存储介质、RAM、ROM等，使得其可由可编程计算机读取，当存储介质或设备由计算机读取时可用于配置和操作计算机以执行在此所描述的过程。此外，机器可读代码，或其部分可以通过有线或无线网络传输。当此类媒体包括结合微处理器或其他数据处理器实现上文所述步骤的指令或程序时，本公开所述的发明包括这些和其他不同类型的非暂时性计算机可读存储介质。当根据本公开所述的方法和技术编程时，本公开还包括计算机本身。

以上所述仅为本公开的实施例而已，并不用于限制本公开。对于本领域技术人员来说，本公开可以有各种更改和变化。凡在本公开的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本公开的保护范围之内。

Claims (11)

1.一种多区域场景下服务提供方法，其特征在于，该方法应用于包含多个区域的云计算服务平台，该方法包括：

以与区域绑定的IP地址和端口接收服务请求，所述服务请求中携带有所请求的服务所在区域的区域标识和服务标识；

基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关，所述区域转发规则中包括区域标识与区域IP地址的对应关系；

基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理，所述服务转发规则中包括服务标识与区域中服务模块地址和端口的对应关系。

2.根据权利要求1所述的方法，其特征在于，所述多个区域的云计算服务平台共用一套认证模块，未包括认证模块的区域中对认证模块的请求，通过预配置的包括区域标识与区域IP地址的对应关系的转发规则转发到部署认证模块的区域当中，由部署认证模块的区域当中认证模块进行处理。

3.根据权利要求1所述的方法，其特征在于，所述基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关方法为：

从所述服务请求中提取区域标识；

使用所提取的区域标识匹配区域转发规则，若匹配成功则从区域转发规则中获取区域IP地址，修改所述服务请求，将所述服务请求重定向到所获取的区域IP地址指向的区域中的服务网关和服务网关端口。

4.根据权利要求1所述的方法，其特征在于，所述基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理的方法为：

从所述的服务请求中提取服务标识；

使用所提取的服务标识匹配服务转发规则，若匹配成功则从服务转发规则中获取服务模块地址和端口，修改服务请求，将所述服务请求重定向到所获取的服务模块地址和端口。

5.根据权利要求2所述的方法，其特征在于，

所述云计算服务平台采用OpenStack云计算管理平台进行管理，所述认证模块采用Keystone实现，所述服务请求的路由转发采用Ingress-nginx实现，所述规则配置采用Ingress实现。

6.一种多区域场景下服务提供装置，其特征在于，该装置应用于包含多个区域的云计算服务平台，该装置包括：

请求路由模块，用于以与区域绑定的IP地址和端口接收服务请求，所述服务请求中携带有所请求的服务所在区域的区域标识和服务标识；基于预设的服务请求的区域转发规则，将所述服务请求转发到对应区域中的服务网关，所述区域转发规则中包括区域标识与区域IP地址的对应关系；

规则解析模块，用于存储预配置的区域转发规则、服务转发规则；

服务网关，用于基于预设的服务转发规则，将所述服务请求转发给对应的服务模块进行处理，所述服务转发规则中包括服务标识与区域中服务模块地址和端口的对应关系。

7.根据权利要求6所述的装置，其特征在于，所述装置还包括：

认证模块，用于处理本区域内的认证请求以及由其它未部署认证模块的区域转发过来的认证请求，未部署认证模块的区域中的认证请求通过其区域内预配置的包括区域标识与区域IP地址的对应关系的转发规则转发到部署认证模块的区域当中认证模块，由部署认证模块的区域当中认证模块进行处理。

8.根据权利要求6所述的装置，其特征在于，所述请求路由模块包括：

区域标识提取模块，用于从所述服务请求中提取区域标识；

区域转发匹配模块，用于使用所提取的区域标识匹配区域转发规则，若匹配成功则从区域转发规则中获取区域IP地址；

区域转发执行模块，用于根据所获取的区域IP地址修改所述服务请求，将所述服务请求重定向到所获取的区域IP地址指向的区域中的服务网关和服务网关端口。

9.根据权利要求6所述的装置，其特征在于，所述服务网关包括：

服务标识提取模块，用于从所述的服务请求中提取服务标识；

服务转发匹配模块，用于使用所提取的服务标识匹配服务转发规则，若匹配成功则从服务转发规则中获取服务模块地址和端口；

服务转发执行模块，用于根据所获取的服务模块地址和端口，修改服务请求，将所述服务请求重定向到所获取的服务模块地址和端口。

10.根据权利要求7所述的装置，其特征在于，

所述云计算服务平台采用OpenStack云计算管理平台进行管理，所述认证模块采用Keystone，所述请求路由模块采用Ingress-nginx，所述规则解析模块采用Ingress。

11.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序当被处理器执行时实施如权利要求1至5中任一项所述的方法步骤。

Images