如何理解多租戶架構？

https://www.cnblogs.com/pingfan21/p/7478242.html

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

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

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

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

一、對多租戶的理解

　　多租戶定義：多租戶技術或稱多重租賃技術，簡稱SaaS，是一種軟體架構技術，是實現如何在多使用者環境下（此處的多使用者一般是面向企業使用者）共用相同的系統或程式元件，並且可確保各使用者間資料的隔離性。簡單講：在一臺伺服器上執行單個應用例項，它為多個租戶（客戶）提供服務。從定義中我們可以理解：多租戶是一種架構，目的是為了讓多使用者環境下使用同一套程式，且保證使用者間資料隔離。那麼重點就很淺顯易懂了，多租戶的重點就是同一套程式下實現多使用者資料的隔離。對於實現方式，我們下面會討論到。

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

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

二、多租戶資料隔離的三種方案

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

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

　　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