?

企業(yè)級SaaS市場近幾年在每個細(xì)分領(lǐng)域都涌現(xiàn)出了一批玩家。從技術(shù)角度看，不同的領(lǐng)域、不同的SaaS產(chǎn)品，必定有著同樣的架構(gòu)內(nèi)核，其中最關(guān)鍵的便是對于多租戶（Multi-Tenancy）的支持。對廣大企業(yè)來說，引入SaaS產(chǎn)品本質(zhì)上就是對互聯(lián)網(wǎng)服務(wù)的租賃，因而多租戶便必然是SaaS的天然屬性之一，也是其與傳統(tǒng)互聯(lián)網(wǎng)應(yīng)用架構(gòu)設(shè)計的重要差異之一。在SaaS架構(gòu)的成熟度演進過程中，其核心路線便是如何實現(xiàn)多租戶，也就是說，SaaS成熟度的高低，很大程度上取決于如何實現(xiàn)多租戶的支持。

一 多租戶技術(shù)的核心關(guān)注點

多租戶在技術(shù)實現(xiàn)層面目前并沒有既定的規(guī)范，不僅細(xì)節(jié)多，每處細(xì)節(jié)的實現(xiàn)方式也多種多樣。如何落地，一方面取決于當(dāng)前研發(fā)團隊現(xiàn)有的技術(shù)儲備、技術(shù)選型、團隊資本實力、所處行業(yè)或客戶特點（比如金融行業(yè)對數(shù)據(jù)安全會有更高要求），另一方面也與當(dāng)前的技術(shù)發(fā)展息息相關(guān)，云廠商的崛起和云原生時代的到來，也深刻影響著包括SaaS在內(nèi)的軟件構(gòu)建的方法。

但常規(guī)來說，真正的SaaS應(yīng)用往往需要滿足以下兩點：

• 單實例
• 多租戶

單實例意味著系統(tǒng)資源層面的共享，多租戶意味著應(yīng)用邏輯層面的隔離。所以如何平衡好這兩點，才是SaaS應(yīng)用多租戶設(shè)計的核心關(guān)注點。

經(jīng)典的分布式服務(wù)架構(gòu)天然解決了互聯(lián)網(wǎng)應(yīng)用的三高問題（高并發(fā)、高性能、高可用），這也是企業(yè)SaaS發(fā)展中后期即將面臨的問題，下面我們來分析下如何在該架構(gòu)下去設(shè)計與實現(xiàn)多租戶SaaS應(yīng)用。

?

二 多租戶的實現(xiàn)

從資源共享的層面看，從share nothing到share everything，在天平的任何一個點上都可以支撐多租戶。但正如我們前文所說，SaaS架構(gòu)首要考慮的目標(biāo)便是單實例，只有單實例才能將成本盡可能降低，產(chǎn)品才會有規(guī)模效應(yīng)。所以所謂共享和隔離，在經(jīng)典架構(gòu)下又會聚焦為一點，即如何對不同租戶進行資源層面的隔離。

?

三 關(guān)于資源

談到資源，我們可能會想到CPU、內(nèi)存、磁盤、網(wǎng)絡(luò)帶寬等，但如此多類型的資源，從其特征上又可以歸為兩類，即存儲資源和計算資源。

換句話說，SaaS系統(tǒng)在技術(shù)本質(zhì)上也可以認(rèn)為就是分布式存儲和分布式計算的融合。

在多租戶的實現(xiàn)中，往往更關(guān)鍵的是對于存儲資源的處理，計算資源一般只在必要情況下才會考慮，我認(rèn)為這主要是和存儲的“有狀態(tài)性”有關(guān)。下面我們以一些典型場景為例，具體分析一下多租戶的設(shè)計該如何著手。

?

四 存儲資源的隔離

隔離存儲資源概括來說可以用一個詞來解決：命名空間。以數(shù)據(jù)庫為例，我們只需要在每條租戶的記錄上，記下對應(yīng)租戶的標(biāo)識即可。

一般來說，不考慮分庫分表的情況下，我們邏輯上會在同一個Schema中，存儲所有租戶的數(shù)據(jù)。這就要求每張表都會有一個tenant_id字段，也即每條記錄都攜帶了它的“命名空間”——租戶標(biāo)識。

再以常用的NoSQL方案Redis為例，一般來說也是在同一個分布式集群中存儲所有租戶數(shù)據(jù)，那么很明顯在key上攜帶租戶標(biāo)識即可。

所以無論何種存儲，思路都是相通的，而且處理起來相對簡單粗暴。但這里我想著重強調(diào)的是，在工程層面我們應(yīng)當(dāng)將這種約定在底層框架里做統(tǒng)一處理。

比如在租戶上下文中的所有SQL語句，應(yīng)當(dāng)都要攜帶where tenant_id=?這個條件，才能保證邏輯正確，我們很難想象在代碼從零到十萬、百萬行的過程中，所有人都自始至終都牢記這個規(guī)則。

那么類似場景下，我們就可以通過AOP技術(shù)將多租戶相關(guān)的邏輯切出來進行統(tǒng)一處理，比如在Java中，我們可以定義@TenantContextAware注解，以聲明而非編碼的方式在需要的地方做對應(yīng)的租戶信息獲取及傳遞處理。

那么又如何保證開發(fā)者也牢記這個規(guī)則呢，由于多租戶是SaaS的天然屬性，我們可以反其道而行之，默認(rèn)支持多租戶邏輯，同時定義@TenantContextUnaware注解，在不需要多租戶的地方進行例外聲明，這就大大降低了開發(fā)團隊的負(fù)擔(dān)。

同理，類似Redis Key的維護，也建議定義統(tǒng)一的KeyGeneratePolicy來維護。

?

五 計算資源的隔離

隔離計算資源的方法也可以用一個詞來概括，那就是親和性，簡單來說就是租戶與集群計算資源的親和性設(shè)計。

計算與存儲除了“狀態(tài)”方面的差異外，還有一個非常重要的區(qū)別，計算的財務(wù)成本往往遠(yuǎn)高于存儲，比如我們一臺虛擬主機上可能只允許數(shù)百個線程同時處理請求。

正因為如此，寶貴的計算資源在非必要的情況下一般不會再進行細(xì)粒度的隔離，例如我們一般不會在運行時只允許某租戶的請求只提交給指定工作線程處理。

另外一方面，計算資源發(fā)生傾斜的后果，往往比存儲要嚴(yán)重的多，如同木桶效應(yīng)般，直接且顯著地影響整個集群的服務(wù)能力。

但特定場景下較粗粒度的隔離，有時候還是非常必要的。比如為了減少系統(tǒng)故障時租戶的影響范圍，我們可能會將租戶的請求哈希后提交給不同的線程池處理，因為這種情況下，反壓將會產(chǎn)生全局的影響。

另外我們也可能在特定場景下進行進程、集群層面的隔離。總的來說，對計算資源進行隔離，沒有既定的模式與套路，而且往往需要高超的資源操作水平，一般不到萬不得已不建議實施。

同樣地，如果一定要實施，那么也應(yīng)當(dāng)以組件化的方式進行，保證業(yè)務(wù)邏輯的純粹性。

通過上述對存儲和計算資源的隔離處理，我們的SaaS架構(gòu)整體看起來將會是下圖這個結(jié)構(gòu)。

在這里用一個表格就一些要點對兩種手段做個簡單的對比，便于大家更直觀地理解。

?

六 單實例架構(gòu)的擴展

面向企業(yè)的SaaS服務(wù)往往還有一些特點可能會引出一些高階需求，而獨立的單實例架構(gòu)有時候并不能完全滿足這些高階需求。此時就需要對原有架構(gòu)進行擴展，以實例級別的整體隔離，配合租戶級的請求分流手段，為SaaS帶來資源、軟件版本等多方面的隔離。

但需要注意的是，對單實例架構(gòu)的擴展，并沒有降低其架構(gòu)成熟度，與我們文中一直在強調(diào)的單實例架構(gòu)理念并不沖突。

比如我們往往會根據(jù)企業(yè)客戶的規(guī)模和特點對其保障等級進行分級，那如何進一步合理地隔離資源，保障不同級別客戶的使用體驗，也是一個無法逃避的問題。

這種情況下，我們就可以考慮將這類客戶的某些資源實施特殊的保護性隔離，或者干脆將單實例架構(gòu)擴展成為多實例架構(gòu)，將客戶分流到不同保障級別的資源池。

如果有個別客戶體量遠(yuǎn)超其他客戶，那么在成本允許的情況下，我們甚至可以考慮為其建設(shè)專屬資源池，對其進行重點保障，這種級別的保護并不意味著犧牲了小體量客戶的體驗，相反，往往大體量客戶才更容易發(fā)生一些影響穩(wěn)定性的突發(fā)事件，所以可以認(rèn)為是一種多贏的操作。

另外，SaaS往往能給客戶帶來更快的特性交付，但這種快速交付很可能帶來不佳的使用體驗，比如嚴(yán)重BUG的存在。

那么這個時候，如果我們的系統(tǒng)是多實例架構(gòu)，那么就可以很輕易地實現(xiàn)灰度發(fā)布，從而使得特性交付的過程更加穩(wěn)健，也是對品牌形象的一種保護。

?

七 總結(jié)

在實際開發(fā)中，我們往往容易忽視早期對類似多租戶等基礎(chǔ)層面的系統(tǒng)性規(guī)劃與設(shè)計，導(dǎo)致后期研發(fā)、維護成本持續(xù)增加，甚至在面臨一些新的商業(yè)機會的時候，無法靈活應(yīng)對。

好的架構(gòu)則能將這些本質(zhì)的特征透明化，做到業(yè)務(wù)層無感，從而提高研發(fā)效率。在企業(yè)SaaS的多租戶架構(gòu)設(shè)計環(huán)節(jié)，我們無法羅列或預(yù)判所有可能，在不同的技術(shù)選型下的多租戶實現(xiàn)也有很大差異，我們應(yīng)當(dāng)著重去發(fā)掘其技術(shù)本質(zhì)，從計算與存儲資源的隔離層面，系統(tǒng)地規(guī)劃與架構(gòu)，做好基礎(chǔ)組件的建設(shè)與沉淀。

只有拋開現(xiàn)象去歸納總結(jié)相關(guān)本質(zhì)方法，才能以不變應(yīng)萬變。

?

?

關(guān)于作者

張晉。網(wǎng)易智慧企業(yè)架構(gòu)師，負(fù)責(zé)旗下多款SaaS產(chǎn)品的架構(gòu)、基礎(chǔ)設(shè)施建設(shè)等相關(guān)工作，有豐富的C端、B端產(chǎn)品研發(fā)經(jīng)驗。目前主要關(guān)注企業(yè)級產(chǎn)品的技術(shù)架構(gòu)、研發(fā)管理等方面。

?

總結(jié)

以上是生活随笔為你收集整理的漫谈企业级SaaS的多租户设计的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。