雲平台之多租戶
在雲領域我們常常會聽到一個詞：多租戶。這個詞在不同的語境中有着不同的含義。本文將介紹雲平台中的多租戶的概念以及實現多租戶支持的思路。
什么是租戶
剛開始接觸這個概念時，你肯定感覺“租戶”這個詞怪怪的。但假設我們換個詞，我相信你立即就有感覺了。這個詞就是“客戶”（這里的客戶指的就是商業上面的客戶）。
一個租戶就是一個客戶，比方我們開發的服務是給 XXX 企業使用的，那該企業就是我們的一個客戶/租戶；假設這個服務是面向互聯網的，那么使用該服務的每一個互聯網用戶都是一個客戶/租戶。
為什么須要多租戶支持
開發人員辛辛苦苦開發出一個服務。提供給了個人/企業使用，這樣就完事了么？當然不應該僅僅是這樣。我們開發出一個服務。最好是可以同一時候提供給多個個人/企業使用。並且這些客戶最好是共享同一套服務執行時（Runtime），這樣可以大大減少服務的運維成本：
- 服務執行時假設分開，則運維的成本與客戶數成正比（比方更新部署大量客戶的場景）
- 節省資源（將服務所需資源利用最大化：運維團隊統一、硬件使用）
另外，這樣也能夠減少服務的開發成本：
- 我們僅僅須要考慮怎樣實現單用戶的服務邏輯：業務邏輯相應其全部客戶都是同樣的，不管什么客戶來使用，程序提供的服務都是一樣的。進一步說，在業務層面我們開發這個服務時理論上不須要考慮多客戶支持，我們僅僅用關注該服務的業務邏輯怎樣實現
- 多客戶的管理功能能夠進行統一：開發人員應該不用考慮客戶管理功能，這部分應該是由雲平台統一提供的
多租戶場景舉例
如果我們要開發的服務是一個博客平台，這個服務是面向互聯網用戶的，每一個互聯網用戶都是我們的客戶（一個用戶就是一個租戶）。
在不支持多租戶的環境中，為了隔離每一個用戶的數據，至少我們在設計數據庫表時會考慮大多數表都存在一個 user_id 字段。用於 CRUD 數據時使用該字段進行用戶隔離。
比方如今的業務是“公布文章”。須要將文章數據保存在 article 表中，在實現時實際上我們關注了兩件事情：
- CRUD：這是業務邏輯實現的一部分
- 用戶隔離：須要增加 user_id。做業務關聯
1 是“純”業務邏輯部分的實現。這是必須實現的；2 則是為了多用戶博客平台而須要考慮的，這並非博客平台本身的業務邏輯。這里假設能得到平台的多租戶支持，就不用考慮第 2 點了。這樣能夠將注意力集中於第 1 點業務邏輯實現上，這是很典型的一個多租戶場景。
多租戶支持
我們能夠這樣理解多租戶支持：
- 從服務提供的角度看。我們開發的一個服務執行時能夠同一時候提供給多個客戶使用。而且客戶之間的數據/狀態是保持隔離的
- 從服務使用的角度看，我和你能夠作為不同的客戶同一時候使用同一個執行的服務，此時我們使用該服務完畢的業務是相互不影響的，就好像我們在使用自己獨享的服務一樣
那么這個服務就是支持多“客戶”的，即該服務支持多租戶。這里的“服務”能夠是應用，能夠是 SaaS 平台，也能夠是 PaaS 平台。只是按眼下我們熟悉的雲平台看，應用的多租戶支持應該是最常規的。這是由於應用面向的是用戶，這個群體是非常龐大的。
多租戶支持從實現的角度看。“是一種軟件架構技術”，之所以強調它是屬於架構層面是由於要實現它必須在做技術架構時就要將其考慮在內。
一種租戶模型
本文一開始我們提到使用“客戶”來置換“租戶”來理解租戶的含義。再從“商業”這個方面來看的話，我們不難發現租戶事實上就是其雲環境中的商業模式實現的一部分。商業模式是多樣的。這意味着租戶的划分也是多樣的。這里我們描寫敘述當中一種可能的租戶棧：
- 應用程序是提供給用戶使用的，對於應用來說，用戶就是它的租戶（這一點業界比較統一）
- SaaS 提供的服務是給應用開發商使用的，對於 SaaS 來說，應用開發商就是它的租戶
- PaaS 提供的服務是給應用系統使用的，對於 PaaS 來說。相關應用的組合就是它的租戶
SaaS 和 PaaS 面向的是開發商、系統等非端用戶角色。這一部分通常是由雲平台開發人員決定的（捆綁商業模式）。特別是私有/企業雲平台一般不會考慮形如“在 PaaS 平台上支持執行多個 SaaS 平台”這種場景。所以以下我們很多其它的是環繞“應用對多租戶支持”進行討論。
應用多租戶
應用多租戶的使用場景前面已經介紹過了。如今如果我們是一個雲平台開發人員，為了滿足支持應用支持多租戶的需求，在雲平台中我們須要提供以下幾個支持：
- 租戶管理：CRUD，統計
- 租戶隔離/共享的服務：隊列、緩存、數據庫等
- 租戶隔離的統計：日志、配額
這些支持能夠分為兩類：
- 租戶的管理：不會直接面向應用的端用戶。面向的是應用的運維。平台應該提供詳細實現
- 租戶數據/狀態的隔離：從請求開始就應該能夠區分這個請求是來自於哪個租戶，請求處理時在調用鏈路上也須要帶上租戶上下文。數據的存取是依照租戶隔離的。調用平台提供的服務時也是租戶隔離的
第 1 點比較easy實現。這是一個業務模型方面的問題，能夠依據業務域來抽象租戶模型，比方企業應用通常是依照“組織機構”來區分租戶的；
第 2 點是一個純技術的需求。須要在平台技術實現上支持按“租戶”的執行時隔離，我們強調的是隔離，由於在實現時我們要達到的目標就是隔離，僅僅只是這里是按租戶（租戶僅僅是一個商業概念，技術層面我們最好能夠將其進行抽象。盡量減小商業模式多樣化對技術架構的沖擊）。我們能夠將租戶映射到一個抽象概念上，這個抽象概念能夠實現我們的隔離需求。
命名空間
前面我們討論多租戶支持都是自上而下的：從應用多租戶需求到數據隔離實現；如今我們再換種視角，自下而上：先通過命名空間隔離數據，再將命名空間提供給應用多租戶的實現使用。自下而上的目的主要是在平台內部，我們可以通過“命名空間”來進行數據/狀態隔離的抽象。終於的理想情況是命名空間不僅可以支持應用多租戶實現，還可以可選擇性地暴露命名空間 APIs。讓應用可以進行某些數據的隔離（比方緩存）。方便業務實現。
隔離的實現
租戶請求從開始到結束平台都須要知曉這個請求映射的命名空間。從請求處理棧我們能夠這樣大致划分一下：
- 負載均衡器（LB）
- 應用容器（APP）
- 平台服務接口（RPC）
- 平台服務實現（DB/Cache/MQ....）
在這個棧中每一層平台都是須要知道這個請求相應的命名空間的。平台能夠提供一個統一登錄的服務，將租戶信息映射為命名空間並保存到用戶會話中，這樣每次該用戶的請求：
- 過 LB 時就能夠區分出命名空間來
- 在 APP 容器中能夠通過會話
- RPC 時傳遞命名空間
- 依據服務的不同進行命名空間實現（比如 DB 依據命名空間使用不同的 Schema，MQ 依據命名空間使用不同的隊列）
這里我們使用的隔離實現基本思路是“Shared application”，即多租戶共享一個應用，相應一套基礎設施（請參考：將單租戶應用程序轉換為多租戶應用程序）。
一種平台設計
前面談了這么多，如今我們能夠腦補出一種支持應用多租戶的雲平台：
（這里的設計思路也包括了有的租戶要求獨享資源的場景）
總結
- 租戶和客戶的概念類似
- 對多租戶的支持我們一般指的是應用對多租戶的支持
- 在技術層面支持多租戶須要實現數據/狀態隔離
- 使用命名空間進行隔離實現抽象
- 租戶到命名空間的映射可由平台集成