前幾天跟朋友聚會的時候，朋友說他們公司準備自己搞一套saas系統，以實現多個第三方平台的業務接入需求。聊完以後，實在手癢難耐，於是花了兩天時間自己實現了兩個saas系統多租戶資料隔離實現方案。俗話說「獨樂樂不如眾樂樂」，所以我把我的「研究成果」寫出來，讓大家樂呵樂呵。
在分享我的研究成果之前，我們先了解一下相關的定義吧。如果對這部分內容熟悉的同學，可以直接略過。
也就是說，我只需要能連線上網際網路，並且給saas平台交租金，我就能用saas平台給我提供的系統服務。這方面最典型的例子就是各種雲平台，例如阿里雲。既然我能通過網際網路使用saas平台提供的服務，那麼其他人當然也是可以的。於是這就產生了乙個多租戶的問題。
多租戶問題，簡單來說，是一種架構設計方式，就是在一台或者一組伺服器上執行的saas系統，可以為多個租戶（客戶）提供服務，目的是為了讓多個租戶在網際網路環境下使用同一套程式，且保證租戶間的資料隔離。從這種架構設計的模式上，不難看出來，多租戶架構的重點就是同一套程式下多個租戶資料的隔離。由於租戶資料是集中儲存的，所以要實現資料的安全性，就是看能否實現對租戶資料的隔離，防止租戶資料不經意或被他人惡意地獲取和篡改。
目前saas多租戶系統的資料隔離有三種解決方案，即為每個租戶提供獨立的資料庫、獨立的表空間、按欄位區分租戶，每種方案都有其各自的適用情況。下面我們依次講解這3種方案。
這種方案的實現方式是所有租戶共享同乙個應用，但應用後端會連線多個資料庫系統，乙個租戶單獨使用乙個資料庫系統。這種方案的使用者資料隔離級別最高，安全性最好，租戶間的資料能夠實現物理隔離。但成本較高。
這種方案的實現方式，就是所有租戶共享同乙個應用，應用後端只連線乙個資料庫系統，所有租戶共享這個資料庫系統，每個租戶在資料庫系統中擁有乙個獨立的表空間。
這種方案是多租戶方案中最簡單的設計方式，即在每張表中都新增乙個用於區分租戶的字段（如租戶id或租戶**）來標識每條資料屬於哪個租戶，其作用很像外來鍵。當進行查詢的時候每條語句都要新增該欄位作為過濾條件，其特點是所有租戶的資料全都存放在同乙個表中，資料的隔離性是最低的，完全是通過欄位來區分的。
獨立資料庫系統高少
隔離級別最高，安全性最好，能夠滿足不同租戶的獨特需求，出現故障時恢復資料比較容易
資料庫需要獨立安裝，維護成本和購置成本高
共享資料庫，獨立表空間中較多
提供了一定程度的邏輯資料隔離，乙個資料庫系統可支援多個租戶
出現故障的情況下，資料恢復相對而言比較複雜
按租戶id欄位區分
低非常多
維護和購置成本最低，每個資料庫能夠支援的租戶數量最多
隔離級別最低，安全性也最低，資料備份和恢復非常複雜，需要逐表逐條備份和還原
前面咱們說的那三種資料隔離解決方案，都是多個租戶共享乙個應用例項的。如果你是土豪，非常的不差錢，那這裡就還有一種乙個租戶乙個應用例項的解決方案，直接為土豪量身定製，純24k鈦合金的。
這種方案是在多例項系統的基礎上進行負載均衡，將租戶的訪問請求路由到其專屬的租戶系統上去。這種多例項的部署架構，可以為每個租戶定製**，以及提供特色服務。當然，使用這種解決方案提供服務的租戶，那也肯定不差錢，能負擔高額租金的「大客戶」了。
saas系統中需要解決的最核心的問題是租戶的資料隔離問題，我們看到解決這個問題有好幾種方式，這就需要我們在業務場景中去根據實際情況進行選擇。
EEPlat PaaS中的多租戶資料隔離模式
eeplat paas支援三種租戶的資料隔離技術 sparce column tenantid欄位隔離 每乙個租戶獨立資料庫。eeplat paas平台產品提供了更加強大的元模型體系。2 tenantid欄位隔離。tenantid的字段隔離是為每乙個業務表加上tenantid欄位。用以區分租戶的資料...
多租戶使用者管理系統中常見的業務場景
在多租戶使用者管理系統中，常見的業務場景有以下幾種 使用者註冊 使用者通過填寫手機號碼等資訊，進行註冊操作 該場景這重驗證使用者手機號碼的有效性，一般通過簡訊驗證碼進行驗證 租戶註冊 使用者通過填寫租戶的相關資訊，註冊租戶，該使用者預設為租戶的超級管理員。該場景注重收集租戶的相關資訊 使用者登入 通...
PaaS平台上多租戶的資料拓展 自定義 續
動態拓展,是資料訪問層在執行時,甚至是在二次開發中,才會遇到或者需要解決的問題,它很重要,卻不一定如它的重要性那樣迫切.在服務層面,我們為了保持架構的拓展性和可維護行,自然而然想到soa,想到了服務的切分.那在資料層面的,為了保持庫的簡潔,易維護,同時為了儲存海量資料,我們自然而然的要對庫做切分,需...