如何理解多租戶架構？

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

　　OK,Let's get this straight（讓咱們搞懂它），接下來讓咱們問本身幾個問題:

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

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

1、對多租戶的理解

　　多租戶定義：多租戶技術或稱多重租賃技術，簡稱SaaS，是一種軟件架構技術，是實現如何在多用戶環境下（此處的多用戶通常是面向企業用戶）共用相同的系統或程序組件，而且可確保各用戶間數據的隔離性。簡單講：在一臺服務器上運行單個應用實例，它爲多個租戶（客戶）提供服務。從定義中咱們能夠理解：多租戶是一種架構，目的是爲了讓多用戶環境下使用同一套程序，且保證用戶間數據隔離。那麼重點就很淺顯易懂了，多租戶的重點就是同一套程序下實現多用戶數據的隔離。對於實現方式，咱們下面會討論到。

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

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

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

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

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

　　1. 獨立數據庫

　　這是第一種方案，即一個租戶一個數據庫，這種方案的用戶數據隔離級別最高，安全性最好，但成本較高。 
　　優勢： 
　　　　爲不一樣的租戶提供獨立的數據庫，有助於簡化數據模型的擴展設計，知足不一樣租戶的獨特需求；若是出現故障，恢復數據比較簡單。 
　　缺點： 
　　　　增多了數據庫的安裝數量，隨之帶來維護成本和購置成本的增長。 
　　這種方案與傳統的一個客戶、一套數據、一套部署相似，差異只在於軟件統一部署在運營商那裏。若是面對的是銀行、醫院等須要很是高數據隔離級別的租戶，能夠選擇這種模式，提升租用的訂價。若是訂價較低，產品走低價路線，這種方案通常對運營商來講是沒法承受的。

　　2. 共享數據庫，獨立 Schema 
　　這是第二種方案，即多個或全部租戶共享Database，可是每一個租戶一個Schema（也可叫作一個user）。底層庫好比是：DB二、ORACLE等，一個數據庫下能夠有多個SCHEMA
　　優勢： 
　　　　爲安全性要求較高的租戶提供了必定程度的邏輯數據隔離，並非徹底隔離；每一個數據庫可支持更多的租戶數量。
　　缺點： 
　　　　若是出現故障，數據恢復比較困難，由於恢復數據庫將牽涉到其餘租戶的數據； 
　　若是須要跨租戶統計數據，存在必定困難。

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

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

　　由於咱們用的底層庫是MySQL，且要保證數據的徹底隔離，因此用的方案屬於第一種。獨立數據庫。由於MySQL下SCHEMA就是他的數據庫名。因此每多服務一個用戶，都須要新建一個數據庫。若是是DB2或者是ORACLE的話，一個數據庫下，能夠採用獨立的SCHEMA來進行數據隔離，這樣會相對節省成本，且數據隔離的強度高。

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

　　成本角度因素 

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

　　安全因素 

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

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

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

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

查閱資料以下：

　　 多租戶和單租戶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