多租戶背景
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. 該租戶的所有請求，由此網關單獨處理。