一种单集群多租户管理系统的制作方法

1.本发明涉及一种单集群多租户管理系统，具体涉及一种基于ingress和namespace(命名空间)的kubernetes(一种开源容器管理平台)单集群多租户管理系统。


背景技术：

2.传统金融行业的线上环境，如图1所示，有如下广泛的特征：
3.1.高度隔离的多网络区域：由于金融行业对信息安全的敏感性，金融企业的线上环境，通常由多个高度隔离的网络区域组成，这些网络区域根据承载的业务类型和所需要保障的安全级别来划分。网络区域之间，使用防火墙等技术进行网络隔离，所有必须的跨区域访问，统一使用网关进行流量管控。
4.2.传统架构和云原生架构并行：近些年，云原生技术已成为驱动业务增长的重要引擎，金融行业也纷纷加入到云原生架构转型的队列。但是，业务架构的云原生改造并不能一蹴而就，因此，云架构和传统应用架构的并行，将是一个长久持续的现状。因此，从架构上来说，网络区域可能由传统的业务架构组成，也可能是云原生架构中的集群。
5.3.微服务架构：微服务架构是云原生的三驾马车之一，明确服务间的依赖，互相解耦，让开发更加聚焦业务开发，是当前大部分金融企业架构转型的不二之选。由于微服务让业务聚焦，同时，考虑到金融业务的复杂性，一个金融业务的完成，往往需要部署在多个区域中的多个服务，共同通过restful接口通信来完成。
6.综上，基于云原生和微服务的金融业务架构转型，给企业带来了资源高效、应用敏捷等价值，但是由于金融行业的复杂的线上网络架构，也给开发测试环境的多租户管理机制，带来了更大的挑战：如何在有限的开发测试资源中，使用一种多租户机制，快速创建出多套和线上一致的包含非容器环境和容器环境，同租户各区域间互联互通，不同租户各区域间隔离的开发测试环境，是目前业界亟待解决的问题之一。


技术实现要素：

7.以下给出一个或多个方面的简要概述以提供对这些方面的基本理解。此概述不是所有构想到的方面的详尽综览，并且既非旨在指认出所有方面的关键性或决定性要素亦非试图界定任何或所有方面的范围。其唯一的目的是要以简化形式给出一个或多个方面的一些概念以为稍后给出的更加详细的描述之序。
8.本发明的目的在于解决上述问题，提供了一种单集群多租户管理系统，能够创建出多套和线上一致的开发测试环境，使得租户各区域间互联互通，不同租户各区域间隔离。
9.本发明的技术方案为：本发明揭示了一种单集群多租户管理系统，系统包括多个分区组，每一分区组包括多个分区，每一分区一一对应生产环境的线上区域，分区组中所包含的分区的一部分用于提供非容器化区域且另一部分用于提供容器化区域，非容器化区域和容器化区域共同构成完整的线上模拟环境，其中不同的租户根据环境的用途自定义该租户对应的分区组的值。
z3.k8s.net/s3，同时通过dns服务，定位到该服务s3的访问地址域名的地址，调用请求到达容器集群；
25.步骤3：容器集群通过域名地址，匹配容器化区域z3所属的ingress，ingress将调用请求翻译为集群内部寻址：容器化区域z3、网关g3、路径为“/s3”；
26.步骤4：网关g3根据集群内部寻址中的路径“/s3”，将调用请求翻译为集群内部地址，即寻找相同分区的服务s3。
27.根据本发明的单集群多租户管理系统的一实施例，容器化区域z4中的服务s4调用非容器化区域z2中的服务s2的调用过程进一步包括：
28.步骤1：位于容器化区域z4的服务s4，通过容器化区域的服务注册和发现，得到服务s2的访问地址为，该访问地址注册的是g4网关；
29.步骤2：g4网关通过查询路由信息表，计算得到服务s2的访问地址，调用请求到达非容器化区域z2的网关g2；
30.步骤3：网关g2通过非容器化区域的服务注册和发现，得到服务s2的访问地址，调用请求到达服务s2。
31.本发明对比现有技术有如下的有益效果：本发明一方面保证了多租户使用一套开发测试环境下，多套环境之间的隔离性，即分区组内，分区之间的流量访问完全由网关和ingress统一管控，分区组之间不存在访问流量，从而实现分区自之间的流量隔离性，以及分区组内部的流量联通性。本发明另一方面提出了分区组机制，实现对分区组内部服务的透明性，即，所有分区组内的跨分区的路由寻址，均由网关和ingress统一封装，对于服务和服务的开发者来说，不需要关心自己所属的分区组，即可实现和线上环境相同的服务调用机制。
附图说明
32.在结合以下附图阅读本公开的实施例的详细描述之后，能够更好地理解本发明的上述特征和优点。在附图中，各组件不一定是按比例绘制，并且具有类似的相关特性或特征的组件可能具有相同或相近的附图标记。
33.图1示出了传统金融行业的线上环境的架构示意图。
34.图2示出了本发明的单集群多租户管理系统的一实施例的整体架构示意图。
35.图3示出了图2所示的系统实施例中配置的创建分区组的流程示意图。
36.图4示出了图2所示的系统实施例中配置的同分区组下的服务路由方法的流程示意图。
具体实施方式
37.以下结合附图和具体实施例对本发明作详细描述。注意，以下结合附图和具体实施例描述的诸方面仅是示例性的，而不应被理解为对本发明的保护范围进行任何限制。
38.图2示出了本发明的单集群多租户管理系统的一实施例的整体架构。请参见图2，本实施例的单集群多租户管理系统包括多个分区组。
39.分区组(namespacegroup，简称为ng)包含多个分区，并一一对应生产环境的线上区域(zone，简称为z)，用于提供由非容器化区域(即图中的区域ng1-z1和ng1-z2)和容器化
区域(即图中的分区ng1-z3和ng1-z4)共同构成的完整的线上模拟环境。不同的租户根据环境的用途，自定义其对应的分区组的值，如ng＝m12-trade-it-test，即表示12月份的交易版本集成测试环境。
40.分区组包含的传统环境区域(即非容器化区域)是由云平台的linux主机构成，例如图2中所示的分区组ng1中的区域ng1-z1和区域ng1-z2，分区组ng2中的区域ng2-z1和区域ng2-z2。分区组包含的容器化区域，是由kubernetes集群中的多个命名空间(namespace，简称为n)组成的，例如图2中所示的分区组ng1的分区ng1-z3和ng1-z4，分区组ng2中的分区ng2-z3和ng2-z4。每一个区域z(包括非容器化区域和容器化区域)都由一系列服务(service，简称为s)和一个网关(gateway，简称g)组成。服务即通过http协议暴露的微服务，服务的访问路径为[本区域网关地址]/[s]，非容器化区域的服务访问地址为ip[g]/[s]，容器化区域的服务访问地址为[ng]-[z].k8s.net/[s]。网关部署在对应的区域中，用于控制区域间的访问流量，而区域内的服务访问则不经过网关。每一网关的路由数据库中存储其他区域的访问地址。非容器化区域的网关暴露地址为ip[g]，即非容器化区域所在主机的局域网ip；容器化区域的网关暴露地址为[ng]-[z].k8s.net。
[0041]
分区组中还包括ingress(即，基于路由规则的网络代理，简称in)，例如图示的分区组ng1中的ingress ng1-in3和ingress ng1-in4，分区组ng2中的ingress ng2-in3和ingress ng2-in4。ingress是kubernetes资源之一，是kubernetes暴露服务的通用方式之一。首先，容器集群的主节点(master)在dns服务启上注册.k8s.net的根域名，使容器集群暴露在局域网中。基于一个容器化区域(容器化区域即图示的分区ng1-z3)对应一个ingress的关系,ingress通过域名暴露方式将一个域名和一个容器化区域的网关映射起来。比如，当ingress中的控制器，识别到域名是[ng]-[z].k8s.net的访问，通过映射和代理的方式，将请求转发到域名中所指示的[ng]分区组的[z]区域的网关。
[0042]
同一分区组内的分区间流量由网关和ingress统一管控，不同分区组之间不存在访问流量。综上，同一分区组内部的流量联通性得到了保证，和线上区域流量保持一致。同时，多租户共用一个云平台和容器集群的情况下，多套环境之间的隔离性也得到了保证。
[0043]
要实现图2所示的系统中的多租户管理机制，需要配置如图3所示的分区组创建方法和如图4所示的同分区组下的服务路由方法。以下就这两种方法分别展开说明。
[0044]
图3示出了系统创建分区组的流程。用户只需要通过界面输入参数“分区组名称”，如new-production-test，图3的方法自动为用户生成一套区域互联互通、流量全闭环和线上区域一致的开发测试环境。其详细步骤如下。
[0045]
步骤1：用户输入分区组的名称，即ng的值。
[0046]
步骤2：根据内置的线上区域列表，循环创建分区，分区的值为n＝[ng]-[z]。
[0047]
步骤3：当区域为传统区域(非容器化区域)时，分区的创建需要从云平台中创建虚拟机，分配ip，部署区域的服务、网关等组件，部署完成后生成本区域的网关路由地址addr[ng1-z1]＝ip[g1]。然后执行步骤5。
[0048]
步骤4：当区域为容器化区域时，调用kubernetes的api创建分区(分区组即上述的ng，而区域和分区是一一映射的关系，分区对应生产线上的区域概念)，分区名称为n＝[ng]-[z]。同时，创建分区配套的ingress实例，注册每个分区的域名地址[ng]-[z].k8s.net，并配置域名地址和分区[n]下的网关服务[g]的映射关系。最后，生成本区域的网
关路由地址addr[ng3-z3]＝[ng]-[z].k8s.net。然后执行步骤5。
[0049]
步骤5：汇总本分区组下所有区域(容器化区域和非容器化区域)的网关路由地址，集中存储后将网关路由地址的汇总结果中将每个区域的网关路由地址分发配置到对应的网关中。
[0050]
图4示出了图2所示的系统实施例中配置的同分区组下的服务路由方法的流程。如图4所示，分区组ng1中，位于非容器化区域z1的服务s1,调用位于容器化区域z3的服务s3,调用过程如下：
[0051]
步骤1：服务s1使用非容器化区域的服务注册和发现算法，得到分区z3中的服务s3的访问地址为ip[g1]/s3并发起调用请求，调用请求先到达服务s1所在的区域ng1-z1的网关g1。
[0052]
非容器化区域的服务注册和发现算法的实现如下：
[0053]
使用zookeeper来实现。同一个非容器化区域中，如图1所示，服务s1将自身ip信息ip[s1]注册到zookeeper中，如果z1区域的服务s2需要访问服务s1，可以从zookeeper中读取到服务s1的访问地址，即ip[s1]。同理，g1网关负责把所有其他区域的服务访问地址注册到zookeeper中，注册的值为ip[g1]，例如服务s1调用服务s5，就会从zookeeper中读取到ip[g1]并进行调用。
[0054]
步骤2：网关g1通过查询路由信息表，计算得到服务s3的访问地址为ng1-z3.k8s.net/s3，同时通过dns服务，定位到该服务s3的访问地址域名的地址，调用请求到达容器集群。
[0055]
步骤3：容器集群通过域名地址，匹配分区ng1-z3所属的ingress ng1-in1，ingress ng1-in1将调用请求翻译为集群内部寻址：分区ng1-z3，网关g3，路径(url)为/s3。
[0056]
步骤4：网关g3:根据路径/s3,将调用请求翻译为集群内部地址“s3:8080”,即寻找相同分区的s3服务。
[0057]
如图4所示，分区组ng2中，位于容器化区域z4的服务s4,调用位于非容器化区域z2的服务s2,其调用过程如下：
[0058]
步骤1：位于分区ng2-z4的服务s4,通过容器化区域的服务注册和发现算法，得到服务s2的访问地址为s2:8080,该访问地址注册的是g4网关。
[0059]
容器化区域的服务注册和发现算法的具体实现为：在容器集群内部，使用kubernetes dns来实现服务的注册和发现机制。如图1所示，服务s5将自身的服务名s5和集群内部虚拟地址注册到kubernetes dns的列表中，服务s6可以直接使用服务s5的域名调用服务s5。同理，g3网关负责将所有外部服务的服务名如s1和g3网关自身的集群内部虚拟地址注册到kubernetes dns列表中，这样当服务s5需要调用服务s1时，使用的域名s1便会访问到网关g3。
[0060]
步骤2：g4网关通过查询路由信息表，计算得到服务s2的访问地址为ip[g2]/s2，调用请求到达z2区域网关g2。
[0061]
步骤3：网关g2:通过非容器化区域的服务注册和发现算法，得到服务s2的访问地址为ip[s2]/s2，调用请求到达服务s2。
[0062]
如上述图4所述，所有分区组内的跨分区的路由寻址，均由网关和ingress统一封装，对于服务和服务的开发者来说，不需要关心自己所属的分区组，即可实现和线上环境相
同的服务调用机制，从而保证了分区组内部服务的透明性。
[0063]
尽管为使解释简单化将上述方法图示并描述为一系列动作，但是应理解并领会，这些方法不受动作的次序所限，因为根据一个或多个实施例，一些动作可按不同次序发生和/或与来自本文中图示和描述或本文中未图示和描述但本领域技术人员可以理解的其他动作并发地发生。
[0064]
本领域技术人员将进一步领会，结合本文中所公开的实施例来描述的各种解说性逻辑板块、模块、电路、和算法步骤可实现为电子硬件、计算机软件、或这两者的组合。为清楚地解说硬件与软件的这一可互换性，各种解说性组件、框、模块、电路、和步骤在上面是以其功能性的形式作一般化描述的。此类功能性是被实现为硬件还是软件取决于具体应用和施加于整体系统的设计约束。技术人员对于每种特定应用可用不同的方式来实现所描述的功能性，但这样的实现决策不应被解读成导致脱离了本发明的范围。
[0065]
结合本文所公开的实施例描述的各种解说性逻辑板块、模块、和电路可用通用处理器、数字信号处理器(dsp)、专用集成电路(asic)、现场可编程门阵列(fpga)或其它可编程逻辑器件、分立的门或晶体管逻辑、分立的硬件组件、或其设计成执行本文所描述功能的任何组合来实现或执行。通用处理器可以是微处理器，但在替换方案中，该处理器可以是任何常规的处理器、控制器、微控制器、或状态机。处理器还可以被实现为计算设备的组合，例如dsp与微处理器的组合、多个微处理器、与dsp核心协作的一个或多个微处理器、或任何其他此类配置。
[0066]
结合本文中公开的实施例描述的方法或算法的步骤可直接在硬件中、在由处理器执行的软件模块中、或在这两者的组合中体现。软件模块可驻留在ram存储器、闪存、rom存储器、eprom存储器、eeprom存储器、寄存器、硬盘、可移动盘、cd-rom、或本领域中所知的任何其他形式的存储介质中。示例性存储介质耦合到处理器以使得该处理器能从/向该存储介质读取和写入信息。在替换方案中，存储介质可以被整合到处理器。处理器和存储介质可驻留在asic中。asic可驻留在用户终端中。在替换方案中，处理器和存储介质可作为分立组件驻留在用户终端中。
[0067]
在一个或多个示例性实施例中，所描述的功能可在硬件、软件、固件或其任何组合中实现。如果在软件中实现为计算机程序产品，则各功能可以作为一条或更多条指令或代码存储在计算机可读介质上或藉其进行传送。计算机可读介质包括计算机存储介质和通信介质两者，其包括促成计算机程序从一地向另一地转移的任何介质。存储介质可以是能被计算机访问的任何可用介质。作为示例而非限定，这样的计算机可读介质可包括ram、rom、eeprom、cd-rom或其它光盘存储、磁盘存储或其它磁存储设备、或能被用来携带或存储指令或数据结构形式的合意程序代码且能被计算机访问的任何其它介质。任何连接也被正当地称为计算机可读介质。例如，如果软件是使用同轴电缆、光纤电缆、双绞线、数字订户线(dsl)、或诸如红外、无线电、以及微波之类的无线技术从web网站、服务器、或其它远程源传送而来，则该同轴电缆、光纤电缆、双绞线、dsl、或诸如红外、无线电、以及微波之类的无线技术就被包括在介质的定义之中。如本文中所使用的盘(disk)和碟(disc)包括压缩碟(cd)、激光碟、光碟、数字多用碟(dvd)、软盘和蓝光碟，其中盘(disk)往往以磁的方式再现数据，而碟(disc)用激光以光学方式再现数据。上述的组合也应被包括在计算机可读介质的范围内。
[0068]
提供对本公开的先前描述是为使得本领域任何技术人员皆能够制作或使用本公开。对本公开的各种修改对本领域技术人员来说都将是显而易见的，且本文中所定义的普适原理可被应用到其他变体而不会脱离本公开的精神或范围。由此，本公开并非旨在被限定于本文中所描述的示例和设计，而是应被授予与本文中所公开的原理和新颖性特征相一致的最广范围。