多租户背景
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. 该租户的所有请求，由此网关单独处理。