【解決方案】多租戶技術架構設計入門（一）

目錄

• 前言
• 一、多租戶的概念
• 二、隔離模式
  • 2.1獨立資料庫模式
  • 2.2共享資料庫獨立資料架構
  • 2.3共享資料庫共享資料架構
• 三、隔離方案選型
• 四、架構模型
  • 4.1模型分層
  • 4.2模型關係
• 五、文章小結

前言

多租戶的概念是我在畢業後不久進第一家公司接觸到的，當時所在部門的業務是計劃建設一套基於自研的、基於開放 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 管理平臺的開發者負責。

五、文章小結

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