枯燥的程式碼，美麗的人生

要說多租戶隔離首先要說下雲計算的概念。《資訊保安技術，雲計算服務安全能力要求》（GB/T21168-2014）中有明確的解釋：

雲計算：透過網路訪問可擴充套件的、靈活的物理或虛擬共享資源池，並可按需自助獲取和管理資源的模式（資源例項包括伺服器、作業系統、網路、軟體和儲存裝置等）。雲計算服務：使用定義的介面，藉助雲計算提供一種或多種資源的能力。

《雲計算標準化白皮書》中也將雲計算的核心特徵總結為以下幾點：

廣泛的網路接入。可透過網路，採用標準機制訪問物理和虛擬資源的特性。這裡的標準機制有助於透過異構使用者平臺使用資源。這個關鍵特性強調雲計算使使用者更方便地訪問物理和虛擬資源:使用者可以從任何網路覆蓋的地方，使用各種客戶端裝置，包括行動電話、平板、筆記本和 工作站訪問資源。可測量的服務。透過可計量的服務交付使得服務使用情況可監控、控 制、彙報和計費的特性。透過該特性，可最佳化並驗證已交付的雲服務。這個關鍵特性強調客戶只需對使用的資源付費。從客戶的角度看，雲計 算為使用者帶來了價值，將使用者從低效率和低資產利用率的業務模式轉變 到高效率模式。多租戶。透過對物理或虛擬資源的分配保證多個租戶以及他們的計算 和資料彼此隔離和不可訪問的特性。在典型的多租戶環境下，組成租戶的一組雲服務使用者同時也屬於一個雲服務客戶組織。在某些情況下，尤其在公有云和社群雲部署模型下，一組雲服務使用者由來自不同客戶的用 戶組成。一個雲服務客戶組織和一個雲服務提供者之間也可能存在多個 不同的租賃關係。這些不同的租賃關係代表雲服務客戶組織內的不同小 組。按需自服務。雲服務客戶能根據需要自動，或透過與雲服務提供者的 最少互動，配置計算能力的特性。這個關鍵特性強調雲計算為使用者降低 了時間成本和操作成本，因為該特性賦予了使用者無需額外的人工互動， 就能夠在需要的時候做需要做的事情的能力。快速的彈性和可擴充套件性。物理或虛擬資源能夠快速、彈性，有時是自 動化地供應，以達到快速增減資源目的的特性。對雲服務客戶來說，可 供應的物理或虛擬資源無限多，可在任何時間購買任何數量的資源，購 買量僅僅受服務協議的限制。這個關鍵特性強調雲計算意味著使用者無需 再為資源量和容量規劃擔心。對客戶來說，如果需要新資源，新資源就 能立刻自動地獲得。資源本身是無限的，資源的供應只受服務協議的限 制。資源池化。將雲服務提供者的物理或虛擬資源進行整合，以便服務於一個或多個雲服務客戶的特性。這個關鍵特性強調雲服務提供者既能支援多租戶，又透過抽象對客戶遮蔽了處理複雜性。對客戶來說，他們僅僅知道服務在正常工作，但是他們通常並不知道資源是如何提供或分佈 的。資源池化將原本屬於客戶的部分工作，例如維護工作，移交給了提 供者。需要指出的是，即使存在一定的抽象級別，使用者仍然能夠在某個 更高的抽象級別指定資源位置。

當你要搞一個SaaS服務平臺時，你會發現上述有些概念很難套的上或者有點彆彆扭扭，這是正常現象。因為以上雲計算的定義和特徵很大程度上是從IaaS總結出來的。對於如何界定雲計算我們不必死扣概念，也不能完全參照IaaS的標準來建設。

回到多租戶隔離的實現方案，Gartner按照4個層次對多租戶模型進行劃分，即基礎設施層（主要是指各種伺服器）、資料層（即資料庫層）、應用平臺層（即應用執行的容器）以及應用邏輯層（即應用功能）。如下圖所示：

Gartner一共將多租戶模型劃分為7種模型，從左向右隔離級別依次降低。

第一種模型稱為“Shared Nothing”，即不共享任何資源。在這種模型中，從最底層的基礎設施層，一直到最上端的應用邏輯層，每個租戶均獨享。這種模式也是傳統的IT開發和部署模式。

第二種模型稱為“Shared Hardware”，即共享硬體資源，所有硬體伺服器會形成一個硬體資源池，所有租戶根據需要來共享這些資源。這種模式就是現在比較常見的IaaS模式。第三種模型稱為“Shared OS”，即共享作業系統。在這種模型中，所有硬體資源均安裝有相同的作業系統，透過在租戶間切分和分配作業系統的程序來實現對計算資源的共享。與第二種模型一樣，這種模型也主要集中在對底層計算資源的共享和分配上，而更高層次的內容均是各個租戶獨享的資源。需要單獨購買和部署。

第四種模型稱為“Shared Database”，即共享資料庫。在這種模型下，所有租戶會共享一個數據庫，各個租戶自己的應用伺服器以及運行於其中的應用會使用共享資料庫中為該租戶劃分的資料資源。

第五種模型稱為“Shared Container”，即共享容器。注意，在這種模型下，各個租戶只是共享應用的執行容器，而應用對應的資料庫都是各個租戶獨享的，這一點與第六種模型是根本性的區別。在這種模型中，要求應用執行的容器是支援多租戶訪問的，即容器本身可以智慧化的區分來自各個租戶的請求。

第六種模型稱為“Shared Everything”，即全共享。在這種模型中，所有租戶自頂向下共享所有資源。對於提供服務的一方來講，可以最大限度的利用各種資源，並且依託支援多租戶的應用容器，也可以只開發一套程式，部署一次，便可滿足所有租戶對公共應用的需要。

第七種模型稱為“Custom Multitenancy”，即定製化的多租戶。在這種模型中，實現多租戶的方法是在應用邏輯中改造已有的API，增加租戶的維度。但是這種模式僅僅是對某一個應用起作用，由於沒有使用支援多租戶的應用伺服器，但是又想讓各個租戶共享應用容器，所以不得不在應用邏輯中做文章。

回到現實中，我們應該根據實際的需求來構建恰當的多租戶模型，對於需要更為經濟型SaaS應用的客戶群，可以提供第六種多租戶模型的應用，而對於需要更高資料隔離和計算資源需要的客戶群，則可以提供第五種多租戶模型的應用。小編所在的公司就是採用的第六種多租戶模型。而實際上，國內大部分的SaaS服務也都是採用的這種模型。

我們再來說下設計層面如何做到資料隔離呢？其實很簡單的，那就是在共享表中增加TenantID欄位，對於所有的SQL操作語句都增加TenantID判斷條件。當然了，我們作為有追求的的程式猿，這樣重複、不優雅的程式碼實現似乎會被人唾棄。有沒有更好的方案呢？當然有了，那就是在ORM層實現個SQL改寫器，自動的給SQL操作語句追加TenantID判斷條件。基於mybatis的多租戶隔離外掛github上有很多，大家可以自行選用。

做SaaS服務比較成功的案例國外的有Salesforce，國內的有客如雲、有贊等，都可以作為我們設計SaaS平臺的參考。

最後上一張IaaS、PaaS、SaaS區別圖示：