多租户背景

SaaS(software-as-a-service,软件即服务)化之后,API(Application Programming Interface,应用程序编程接口)网关(Gateway)可以将平台或系统等内部的数据或者程序通过Restful(Representational State Transfer,表述性状态传递)API的方式提供给第三方API租户,从而使API租户能够将不同API服务整合到自己的应用中,衍生出新的服务,有利于促进技术生态发展和跨界创新。

不同的API租户,对API资源和安全等的要求不同,由此衍生出了不同的API SLA(Service-Level Agreement,服务等级协议策略)。API网关为了满足不同API租户的SLA策略,需要使用不同方案对外提供API服务。目前API网关的租户有两种——物理租户和逻辑租户,相应地使用的多租户(多个物理租户或者多个逻辑租户)方案也不同。

物理多租户方案

租户之间的API是物理隔离的,例如使用Docker容器隔离、VM(Virtual Machine,虚拟机)隔离或者物理机隔离。每个租户在API网关中对应一个或者多个API运行实例,这些API运行实例组成租户(例如租户A)独占的API集群,因为采用物理资源独占模式,所以每个租户都拥有自己私有的API运行实例URL,这些URL不会冲突。物理多租户方案中,每个租户的应用程序根据租户ID向API网关请求资源后,API网关返回该租户的API运行实例URL,所述应用程序直接访问返回的API运行实例URL来获取资源,因此不需要进行多租户路由。

逻辑多租户方案

所有租户共享一个或者多个API运行实例,每个API运行实例内部利用多线程、协程或者消息队列隔离的方式,实现不同租户之间的API隔离。各个租户共享一个或者多个API运行实例,API集群对外只提供一个运行实例URL。因为所有的租户共享相同的API运行实例,故API运行实例之间是完全对等的。因此,在逻辑多租户方案中,租户的应用程序根据租户ID向API网关请求API资源后,API网关只需要做随机或轮询分发,就能将API运行实例路由至租户的应用程序。

两种方案优缺点

物理多租户方案存在资源占用多和维护成本高等问题,逻辑多租户方案则存在故障隔离性差等问题,为兼顾资源节约和提高故障隔离性,有必要提出混合多租户方案。混合多租户方案可以对重要的租户采用物理多租方案,对普通租户则采用逻辑多租方案。混合多租户场景中,有些API运行实例是被单个物理租户独占的,有些API运行实例是被多个逻辑租户共享的,如何正确地将API运行实例路由至租户的应用程序,是实现混合多租户方案需要解决的主要问题。

Gravitee网关物理多租房实现

步骤如下:
1. Setting中,Gateway下可提前增加租户Tenants。
2. 增加API时,Gateway设置步骤,选择租户。
3. 修改Gateway配置文件gravitee.yml的Multi-tenant configuration配置项:
tenant: 第一步增加租户生成的租户id
4. 该租户的所有请求,由此网关单独处理。

版权声明:本文为jerryqm原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://www.cnblogs.com/jerryqm/p/13156813.html