前言

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

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

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

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

一、多租戶的概念

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

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

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

二、隔離模式

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

2.1獨立數(shù)據(jù)庫模式

2.1.1特征

一個租戶一個數(shù)據(jù)庫，隔離級別最高，對系統(tǒng)底層所涉及到的計算、存儲、網(wǎng)絡等資源的隔離。

和傳統(tǒng)軟件模式（SaaS）的區(qū)別：

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

2.1.2優(yōu)點

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

2.1.3缺點

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

2.2共享數(shù)據(jù)庫獨立數(shù)據(jù)架構

獨立數(shù)據(jù)庫共享數(shù)據(jù)架構模式示例

2.2.1

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

簡單介紹下 schema：

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

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

2.2.2優(yōu)點

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

2.2.3缺點

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

2.3共享數(shù)據(jù)庫共享數(shù)據(jù)架構

2.3.1特征

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

2.3.2優(yōu)點

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

2.3.3缺點

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

三、隔離方案選型

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

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

四、架構模型

4.1模型分層

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

• 管理層

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

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

• 服務層

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

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

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

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

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

• 基礎設施

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

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

4.2模型關系

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

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

五、文章小結

文章到這里就結束了，作為一個系列文章的開頭，本文的內(nèi)容篇基礎概念，并不是多租戶技術架構的最佳實踐。
如果文章有不足和錯誤，還請大家指正?；蛘吣阌衅渌胝f的，也歡迎大家在評論區(qū)交流！文章來源地址http://www.zghlxwxcb.cn/news/detail-844236.html

到了這里，關于【解決方案】多租戶技術架構設計入門（一）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！