轉自：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
轉自：https://www.cnblogs.com/pingfan21/p/7478242.html
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/50013.html
標籤：架構設計