多租戶的概念是我在畢業后不久進第一家公司接觸到的，當時所在部門的業務是計劃建設一套基于自研的、基于開放 API 的、基于 PaaS 的、面向企業（ToB）的多租戶架構平臺，將我們的服務可以成規模地、穩定高效地交付給客戶使用。

前言

多租戶的概念是我在畢業后不久進第一家公司接觸到的，當時所在部門的業務是計劃建設一套基于自研的、基于開放 API 的、基于 PaaS 的、面向企業（ToB）的多租戶架構平臺，將我們的服務可以成規模地、穩定高效地交付給客戶使用。

當時我們就去參考了騰訊云和阿里云的多租戶設計，團隊經過調研后得出了以下幾個基本共識：

• 要有一定的量：即業務規模大到需要使用多租戶架構來解決，不然就考慮普通的 SaaS 做交付；
• 底層的硬件資源：需要足夠支持這樣量級的業務，運維、高可用、監控這幾方面可能需要云原生團隊的支持；
• 平臺架構設計上：一定要保證高隔離性、高可擴展性、高性能，同時可以支持復雜的、高并發的場景；
• 成本與營收平衡：需要有一個可以接受的范圍，畢竟投入進去的前期是基本虧損的，穩定后再抱有能賺錢的心態。

當然，作為一個入門系列，本篇文章的內容偏基礎概念，并不是多租戶技術架構的最佳實踐。筆者把從互聯網上學習到的相關知識與自身的工作實踐相結合，希望能在分享的過程中和大家一起進步。

---

一、多租戶的概念

多租戶本質上是一種軟件的技術架構，它最核心的特征是多個租戶可以共享一個系統實例，并且租戶間是可以實現數據和行為的隔離，這可以說是多租戶技術架構里最重要的兩點了。

多租戶架構是 SaaS 模式中的重要且常見的架構，通過共享和復用資源降低成本，提高效率和可擴展性。其中最需要關注就是：數據/行為的隔離、身份/角色的認證與授權、底層硬件資源管理、高性能與高可用、定制化和可擴展、數據一致性、系統安全性等。

這里就不過多贅述了，下面會將概念詳細鋪開。如果要找一個生活中容易理解的場景做比喻，那么多租戶的概念其實就和租房子的概念類似，只不過在各自的專業領域所涉及到的術語和具體實現會不一樣。

---

二、隔離模式

一般來說多租戶常見的有3種隔離模式：獨立數據庫、共享數據但獨立數據架構、共享數據庫且共享數據架構。

2.1獨立數據庫模式

獨立數據庫模式示例

2.1.1特征

一個租戶一個數據庫，隔離級別最高，對系統底層所涉及到的計算、存儲、網絡等資源的隔離。

和傳統軟件模式（SaaS）的區別：

獨立數據庫模式有標準的租戶身份識別、租戶入駐流程、計費體系、運營流程等。除此之外，本質上其提供的服務還是端到端的 SaaS 模式，某種意義上可以看作每一個租戶都各自擁有一套端到端的基礎設施。

2.1.2優點

• 滿足強隔離需求：一些租戶為了保證系統和數據的安全性，可能會提出非常嚴格的隔離要求，期望軟件產品能夠部署在一套完全獨立的環境中，不和其它租戶的實例、數據放在一起；
• 計費邏輯簡單：在這種豎井模式下，計費模型相對是比較簡單的；
• 降低故障影響：因為每個租戶的系統都部署在獨立的環境中，如果一個環境出現故障，并不會影響其他租戶的軟件服務。

2.1.3缺點

• 規模化問題：由于租戶是各自獨立的環境，每入駐一個租戶就需要準備、創建、運營一套 SaaS 環境，如果只有少量租戶還可以管理，一旦租戶的數量多起來，管理和運營這些環境將會是非常大的挑戰；
• 成本問題：每個租戶都需要單獨的部署環境，那么花費在每個租戶上的成本就會非常高，會大幅度降低 SaaS 軟件服務的盈利能力；
• 敏捷迭代問題：一般來說 SaaS 模式的優勢是可以很快響應市場變化，可以迅速迭代產品功能，但是在這種豎井模式下更管理、運維這些租戶的 SaaS 環境會變得非常復雜且低效；
• 基礎設施的監控：同樣地，在這種非中心化的模式下，對每個租戶的基礎設施的運維與監控也是非常復雜且繁瑣的。

2.2共享數據庫獨立數據架構

獨立數據庫共享數據架構模式示例

2.2.1

多個租戶或者所有租戶共享數據庫，每個租戶會擁有一個 schema 形成邏輯上的隔離，而并不是物理上的隔離（還在一個實例內）。即多個租戶共享一套基礎設施，降低 Saas 軟件服務的資源成本。

簡單介紹下 schema：

schema 就是數據對象的集合，這個集合包含了各種對象如：表、視圖、存儲過程和索引等。如果把數據庫看作是一個倉庫，那么schema就是一個個的房間，表就是 一個個的柜子。user 是 schema 的 administrator，有操控每個 schema 的權限。

但需要說明的是，MySQL 數據庫中沒有 schema 這個概念，但是一個 MySQL 實例可以有多個數據庫。

2.2.2優點

• 高效管理：在上述共享策略下，所有的租戶都可以集中管理，同時監控基礎設施將更容易，且產品的迭代可以更快；
• 低成本：相對于豎井模式的獨立數據庫，共享數據庫的成本更低，還可以方便地根據用戶的使用需求動態地擴展系統；
• 隔離性較好：雖然同在一個實例內，但是做了邏輯區分，租戶使用的庫不一樣，隔離效果還是比較好的。

2.2.3缺點

• 租戶相互影響：由于所有租戶共享同一資源，當一個租戶占用大量機器時會消耗很多資源，其它租戶的使用很可能會受到影響。在這種情況下，對整個系統架構的可用性和擴展性的要求就比較高了，同時可能也考慮適當地設計限流、降級和熔斷等措施來應對；
• 運維工作量大：每增加一個租戶，都需要為其需要創建新的業務數據庫來進行管理，還可能需要與開發人員共同維護這些數據庫；
• 租戶計費困難：所有租戶共享資源，使得計費可能更加困難，但在研發資源較為充足的時候也不是很大的問題。

2.3共享數據庫共享數據架構

共享數據庫共享數據架構模式示例

2.3.1特征

所有租戶共享一個數據庫實例，共享同一個數據庫，只不過在每張表都加上租戶標識字段用以區分。

2.3.2優點

• 資源成本低：一個實例的一個數據庫就可以搞定所有租戶的數據，支持的租戶數量理論上可以很多；
• 便于迭代：在開發的時候只需要額外關注租戶標識字段就好，產品迭代維護起來也能很方便；

2.3.3缺點

• 隔離性差：所有租戶的數據都放在一起，一旦業務層沒有做好對租戶標識的區分，很容易造成租戶的數據混亂；
• 性能瓶頸：隨著租戶數據量的成倍增加，單表的性能一定會逐步下降，且性能優化會受限于基礎資源的不足；
• 擴展性差： 一旦業務變得復雜，業務之間的耦合也會變緊，可能會引起分布式事務、數據不一致性等一系列的系統問題。

---

三、隔離方案選型

關于怎么對上述提到的 3 種隔離模式的選型，可以從以下 4 個維度來做比較：

1. 資源共享度：即多個租戶之間的對基礎設置的共享程度如何，是豎井還是schema還是共用數據庫？
2. 數據隔離度：當租戶對于業務數據的隔離要求比較高時可以選擇豎井，成本比較緊張或者在初始階段可以考慮共享數據庫；
3. 業務復雜度：有些核心業務是比較復雜的，對整體的服務和底層資源的考驗都比較大，其它業務可以適當做一些簡化；
4. 應用成本：既然選用多租戶技術框架，那么說明用戶肯定是達到了一定的量級，運營、維護、硬件等的綜合成本一定要考慮。

隔離方案選型對比圖示

---

四、架構模型

4.1模型分層

在這里筆者分為了3個層次：管理層、服務層、基礎設施，如多租戶架構圖示（一）所示，下面展開講一下這樣分層的原因。

多租戶架構圖示（一）

• 管理層

  這一層有點類似于阿里云的控制臺，阿里云自己內部可以監控每個租戶的大致情況，租戶自己可以監控到自己付費的資源情況。

  1. 對于開發者而言，這一層主要就是對租戶的管理：即租戶購買了哪些服務、租戶之間的隔離、對租戶的計費等。就像房東對一棟樓每個房間租戶的管理：幾層幾號房租給了誰、要租多久、租金包含什么等，房東只管出租和維護房子，不會管里面租戶的日常生活。
  2. 對于租戶而言，就是對花錢租的服務進行管理：即具體購買了哪些系統、哪些資源、怎么角色授權等。比如租戶租了個一室一廳一衛，客廳怎么布置、廚房要不要做飯、衛生間的垃圾幾天丟一次，這些東西房東基本不會干涉的。

• 服務層

  這一層就是具體提供的系統服務了，這些服務是由開發者開發的，一般情況下所有租戶都是共享一套代碼和系統的，特殊定制化的服務除外。

  1. 對于開發者而言，普通傳統 SaaS 開發模式下，對每一個客戶都得定制開發一套系統，雖然定制化的內容可能大同小異，不會有本質上的區別，但受到數據隔離、底層資源和角色授權等方面的限制，只能單獨為每個客戶部署一套服務和一套資源。

     一旦客戶的數量多起來，劣勢是非常明顯的：開發成本和部署的成本都太高了，且可復用程度低。

     多租戶模式下，如果有一套優秀的、成熟的多租戶技術架構，那么無論對于開發者還是租戶，都是省時省力省錢且高效的。像阿里云提供的 CDN 內容分發、OSS 對象存儲、RDS 云數據庫、SLB 負載均衡等可供租戶購買的服務，都是經過市場打磨的優秀產品。

  2. 對于租戶而言，這層就是購買的具體服務了，這些購買的服務一般會作為底座，用于支撐租戶的業務發展。舉個例子：A 公司花 10 萬元買了阿里云的一些產品服務來支撐自己公司的業務，A 公司將這些業務投入市場后，銷售價格可以為 15 萬元，而可能阿里云為一個租戶提供產品服務的實際成本僅為 5 萬元。

• 基礎設施

  這一層有點類似于 IaaS 基礎設施即服務的概念。我們知道，無論什么軟件服務都要基于 CPU、內存、磁盤、路由器、交換器等一系列的硬件設施。

  1. 對于開發者而言，基礎設施要么自建要么采購。就目前來說，市場上只有少數幾個廠家擁有成熟的硬件設施解決方案，所以軟件服務的開發者一般以采購為主；
  2. 對于租戶而言，對基礎設施是無感的：租戶不必關心具體的底層硬件結構，只需要關注服務層的告警，如有告警可以提出緊急工單對接開發者。

4.2模型關系

這個模型里我理解可以分為 4 種體系：SaaS平臺體系、權限角色體系、業務體系與云資源體系。如多租戶架構圖示（二）所示，每種體系之間都有各自的關聯關系。為方便大家理解，每種關系我都展開講講。

多租戶架構圖示（二）

• SaaS平臺與租戶的關系：這個平臺里面有多個租戶，一般的話采用共享數據庫獨立數據架構的模式，容納幾十個租戶應該問題不大。
• 租戶與組織用戶的關系：租戶一般指的是企業或者組織，通常會有一些員工擔任管理員的角色來管理購買的 SaaS 服務。
• 用戶與權限角色的關系：面對眾多的 SaaS 服務系統，一般只會選擇性地給用戶授予某些權限，比如管理員、超級管理員等。
• 租戶與業務的關系：一般來說這里的業務指的是租戶自己的業務，租戶需要依賴購買的 SaaS 服務來支撐這些業務。
• 業務與底層資源的關系：底層資源一般指的是服務器等硬件資源，但是業務通常不關心底層資源。
• 租戶與底層資源的關系：租戶需要在購買的時候知道底層硬件的配置，其運維和告警等由 SaaS 管理平臺的開發者負責。

五、文章小結

文章到這里就結束了，作為一個系列文章的開頭，本文的內容篇基礎概念，并不是多租戶技術架構的最佳實踐。
如果文章有不足和錯誤，還請大家指正。或者你有其它想說的，也歡迎大家在評論區交流！