JNPF雲平台之多租戶的探索

2021-10-10 15:49:51 字數 2366 閱讀 2568

在雲領域我們常常會聽到乙個詞:多租戶。這個詞在不同的語境中有著不同的含義。本文將介紹雲平台中的多租戶的概念以及實現多租戶支援的思路。

剛開始接觸這個概念時,你肯定感覺「租戶」這個詞怪怪的。但假設我們換個詞,我相信你立即就有感覺了。這個詞就是「客戶」(這裡的客戶指的就是商業上面的客戶)。

乙個租戶就是乙個客戶,比方我們開發的服務是給 *** 企業使用的,那該企業就是我們的乙個客戶/租戶;假設這個服務是面向網際網路的,那麼使用該服務的每乙個網際網路使用者都是乙個客戶/租戶。

開發人員辛辛苦苦開發出乙個服務。提供給了個人/企業使用,這樣就完事了麼?當然不應該僅僅是這樣。我們開發出乙個服務。最好是可以同一時候提供給多個個人/企業使用。並且這些客戶最好是共享同一套服務執行時(runtime),這樣可以大大減少服務的運維成本:

另外,這樣也能夠減少服務的開發成本:

多租戶場景舉例

如果我們要開發的服務是乙個部落格平台,這個服務是面向網際網路使用者的,每乙個網際網路使用者都是我們的客戶(乙個使用者就是乙個租戶)。

在不支援多租戶的環境中,為了隔離每乙個使用者的資料,至少我們在設計資料庫表時會考慮大多數表都存在乙個 user_id 字段。用於 crud 資料時使用該欄位進行使用者隔離。

crud:這是業務邏輯實現的一部分

使用者隔離:須要增加 user_id。做業務關聯

1 是「純」業務邏輯部分的實現。這是必須實現的;

2 則是為了多使用者部落格平台而須要考慮的,這並非部落格平台本身的業務邏輯。

這裡假設能得到平台的多租戶支援,就不用考慮第 2 點了。這樣能夠將注意力集中於第 1 點業務邏輯實現上,這是很典型的乙個多租戶場景。

我們能夠這樣理解多租戶支援:

那麼這個服務就是支援多「客戶」的,即該服務支援多租戶。這裡的「服務」能夠是應用,能夠是 saas 平台,也能夠是 paas 平台。只是按眼下我們熟悉的雲平台看,應用的多租戶支援應該是最常規的。這是由於應用面向的是使用者,這個群體是非常龐大的。

多租戶支援從實現的角度看。「是一種軟體架構技術」,之所以強調它是屬於架構層面是由於要實現它必須在做技術架構時就要將其考慮在內。

一種租戶模型

本文一開始我們提到使用「客戶」來置換「租戶」來理解租戶的含義。再從「商業」這個方面來看的話,我們不難發現租戶事實上就是其雲環境中的商業模式實現的一部分。商業模式是多樣的。這意味著租戶的劃分也是多樣的。這裡我們描寫敘述當中一種可能的租戶棧:

saas 和 paas 面向的是開發商、系統等非端使用者角色。這一部分通常是由雲平台開發人員決定的(**商業模式)。特別是私有/企業雲平台一般不會考慮形如「在 paas 平台上支援執行多個 saas 平台」這種場景。所以以下我們很多其它的是環繞「應用對多租戶支援」進行討論。

應用多租戶的使用場景前面已經介紹過了。如今如果我們是乙個雲平台開發人員,為了滿足支援應用支援多租戶的需求,在雲平台中我們須要提供以下幾個支援:

這些支援能夠分為兩類:

租戶的管理:不會直接面向應用的端使用者。面向的是應用的運維。平台應該提供詳細實現

租戶資料/狀態的隔離:從請求開始就應該能夠區分這個請求是來自於哪個租戶,請求處理時在呼叫鏈路上也須要帶上租戶上下文。資料的訪問是依照租戶隔離的。呼叫平台提供的服務時也是租戶隔離的

第 1 點比較easy實現。這是乙個業務模型方面的問題,能夠依據業務域來抽象租戶模型,比方企業應用通常是依照「組織機構」來區分租戶的;

第 2 點是乙個純技術的需求。須要在平台技術實現上支援按「租戶」的執行時隔離,我們強調的是隔離,由於在實現時我們要達到的目標就是隔離,僅僅只是這裡是按租戶(租戶僅僅是乙個商業概念,技術層面我們最好能夠將其進行抽象。盡量減小商業模式多樣化對技術架構的衝擊)。我們能夠將租戶對映到乙個抽象概念上,這個抽象概念能夠實現我們的隔離需求。

前面我們討論多租戶支援都是自上而下的:從應用多租戶需求到資料隔離實現;如今我們再換種視角,自下而上:先通過命名空間隔離資料,再將命名空間提供給應用多租戶的實現使用。自下而上的目的主要是在平台內部,我們可以通過「命名空間」來進行資料/狀態隔離的抽象。終於的理想情況是命名空間不僅可以支援應用多租戶實現,還可以可選擇性地暴露命名空間 apis。讓應用可以進行某些資料的隔離(比方快取)。方便業務實現。

隔離的實現

租戶請求從開始到結束平台都須要知曉這個請求對映的命名空間。從請求處理棧我們能夠這樣大致劃分一下:

在這個棧中每一層平台都是須要知道這個請求相應的命名空間的。平台能夠提供乙個統一登入的服務,將租戶資訊對映為命名空間並儲存到使用者會話中,這樣每次該使用者的請求:

前面談了這麼多,如今我們能夠腦補出一種支援應用多租戶的雲平台:

(這裡的設計思路也包括了有的租戶要求獨享資源的場景)

自動化測試平台的探索

只做了基本的幾個控制項,在文字框內輸入要生成的檔案數量,點選生成後在相應的目錄下生成對應的檔案 對應的 也很簡單,就乙個from表單,如下 1 doctype html 2 html lang en 3 head 4 meta charset utf 8 5 title 測試檔案生成頁 生成 sty...

雲平台的軟體架構

雲計算的軟體架構層 通過對現在雲計算的整體分析,可以發現其軟體架構分為三層,分別是核心服務層 服務管理層以及使用者訪問層,核心服務層是雲 計算軟甲你的中心,主要是對於系統中的硬體 軟體以及應用程式進行融合,然後在呈現給客戶,具有一定的多樣性與穩定性,也需要適應各種應用程式 服務管理層是對於核心服務層...

PaaS平台上多租戶的資料拓展 自定義 續

動態拓展,是資料訪問層在執行時,甚至是在二次開發中,才會遇到或者需要解決的問題,它很重要,卻不一定如它的重要性那樣迫切.在服務層面,我們為了保持架構的拓展性和可維護行,自然而然想到soa,想到了服務的切分.那在資料層面的,為了保持庫的簡潔,易維護,同時為了儲存海量資料,我們自然而然的要對庫做切分,需...