前段時間公司產品進行了架構的進化，進化到了多租戶架構。當我第一次聽到多租戶時，我也挺納悶，不理解。但當我逐漸的翻閱資料，以及研發功能時。不斷的加深了對多租戶的理解。盡管我現在也只是淺淺的懂一點而已。

　　OK,Let‘s get this straight（讓我們搞懂它），接下來讓我們問自己幾個問題:

　　1.什麽是多租戶架構？
　　2.多租戶架構的優缺點？
　　3.多租戶架構的適用場景？

　　讓我們帶著這幾個問題進入下面的閱讀。

一、對多租戶的理解

　　多租戶定義：多租戶技術或稱多重租賃技術，簡稱SaaS，是一種軟件架構技術，是實現如何在多用戶環境下（此處的多用戶一般是面向企業用戶）共用相同的系統或程序組件

　　在了解詳細一點：在一個多租戶的結構下，應用都是運行在同樣的或者是一組服務器下，這種結構被稱為“單實例”架構（Single Instance），單實例多租戶。多個租戶的數據是保存在相同位置，依靠對數據庫分區來實現隔離操作。既然用戶都在運行相同的應用實例，服務運行在服務供應商的服務器上，用戶無法去進行定制化的操作，所以這對於對該產品有特殊需要定制化的客戶就無法適用，所以多租戶適合通用類需求的客戶。那麽缺點來了，多租戶下無法實現用戶的定制化操作。

　　在翻閱多租戶的資料時，還有一個名詞與之相對應，那就是單租戶SaaS架構（也被稱作多實例架構（Multiple Instance））。單租戶架構與多租戶的區別在於，單租戶是為每個客戶單獨創建各自的軟件應用和支撐環境。單租戶SaaS被廣泛引用在客戶需要支持定制化的應用場合，而這種定制或者是因為地域，抑或是他們需要更高的安全控制。通過單租戶的模式，每個客戶都有一份分別放在獨立的服務器上的數據庫和操作系統，或者使用強的安全措施進行隔離的虛擬網絡環境中。因為本篇主要是討論多租戶，所以單租戶的相關知識就簡單了解一下，不做過多的闡述了。

二、多租戶數據隔離的三種方案

　　在當下雲計算時代，多租戶技術在共用的數據中心以單一系統架構與服務提供多數客戶端相同甚至可定制化的服務，並且仍可以保障客戶的數據隔離。目前各種各樣的雲計算服務就是這類技術範疇，例如阿裏雲數據庫

　　多租戶在數據存儲上存在三種主要的方案，分別是：

　　1. 獨立數據庫

　　這是第一種方案，即一個租戶一個數據庫，這種方案的用戶數據隔離級別最高，安全性最好，但成本較高。
　　優點：
　　　　為不同的租戶提供獨立的數據庫，有助於簡化數據模型的擴展設計，滿足不同租戶的獨特需求；如果出現故障，恢復數據比較簡單。
　　缺點：
　　　　增多了數據庫的安裝數量，隨之帶來維護成本和購置成本的增加。
　　這種方案與傳統的一個客戶、一套數據、一套部署類似，差別只在於軟件統一部署在運營商那裏。如果面對的是銀行、醫院等需要非常高數據隔離級別的租戶，可以選擇這種模式，提高租用的定價。如果定價較低，產品走低價路線，這種方案一般對運營商來說是無法承受的。

　　2. 共享數據庫，獨立 Schema
　　這是第二種方案，即多個或所有租戶共享Database，但是每個租戶一個Schema（也可叫做一個user）。底層庫比如是：DB2、ORACLE等，一個數據庫下可以有多個SCHEMA
　　優點：
　　　　為安全性要求較高的租戶提供了一定程度的邏輯數據隔離，並不是完全隔離；每個數據庫可支持更多的租戶數量。
　　缺點：
　　　　如果出現故障，數據恢復比較困難，因為恢復數據庫將牽涉到其他租戶的數據；
　　如果需要跨租戶統計數據，存在一定困難。

　　3. 共享數據庫，共享 Schema，共享數據表
　　這是第三種方案，即租戶共享同一個Database、同一個Schema，但在表中增加TenantID多租戶的數據字段。這是共享程度最高、隔離級別最低的模式。
　　即每插入一條數據時都需要有一個客戶的標識。這樣才能在同一張表中區分出不同客戶的數據。
　　優點：
　　　　三種方案比較，第三種方案的維護和購置成本最低，允許每個數據庫支持的租戶數量最多。
　　缺點：
　　　　隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量； 數據備份和恢復最困難，需要逐表逐條備份和還原。

　　如果希望以最少的服務器為最多的租戶提供服務，並且租戶接受犧牲隔離級別換取降低成本，這種方案最適合。
　　　　
　　在SaaS實施過程中，有一個顯著的考量點，就是如何對應用數據進行設計，以支持多租戶，而這種設計的思路，是要在數據的共享、安全隔離和性能間取得平衡。

　　因為我們用的底層庫是MySQL，且要保證數據的完全隔離，所以用的方案屬於第一種。獨立數據庫。因為MySQL下SCHEMA就是他的數據庫名。所以每多服務一個用戶，都需要新建一個數據庫。如果是DB2或者是ORACLE的話，一個數據庫下，可以采用獨立的SCHEMA來進行數據隔離，這樣會相對節省成本，且數據隔離的強度高。

三、選擇合理的實現模式
　　衡量三種模式主要考慮的因素是隔離還是共享。

　　成本角度因素

　　　　隔離性越好，設計和實現的難度和成本越高，初始成本越高。共享性越好，同一運營成本下支持的用戶越多，運營成本越低。

　　安全因素

　　　　要考慮業務和客戶的安全方面的要求。安全性要求越高，越要傾向於隔離。

　　從租戶數量上考慮
　　　　主要考慮下面一些因素
　　　　系統要支持多少租戶？上百？上千還是上萬？可能的租戶越多，越傾向於共享。
　　　　平均每個租戶要存儲數據需要的空間大小。存貯的數據越多，越傾向於隔離。
　　　　每個租戶的同時訪問系統的最終用戶數量。需要支持的越多，越傾向於隔離。
　　　　是否想針對每一租戶提供附加的服務，例如數據的備份和恢復等。這方面的需求越多， 越傾向於隔離

　　技術儲備
　　　　共享性越高，對技術的要求越高。

　　以上三部分內容分別針對開頭的三個問題做了概要的闡述，文章中部分內容也是摘錄自查閱的資料，實乃他人總結的非常好，所以就直接把輪子拿過來用了，旨在讓你我更加了解多租戶這種架構，還望勿噴！

查閱資料如下：

　　 多租戶和單租戶SaaS的架構對比 http://blog.sina.com.cn/s/blog_a5ed66830102wddk.html
　　　數據層的多租戶淺談 https://www.ibm.com/developerworks/cn/java/j-lo-dataMultitenant/
　　　SaaS多租戶數據隔離的三種方案 http://blog.csdn.net/yown/article/details/51288549

如何理解多租戶架構？