如果我們的BaaS爲某SaaS提供區塊鏈服務，那麼必然面對的就是每個租戶的鏈上數據該如何隔離的問題。在Fabric中，一般來說我們有四種隔離方法，從軟到硬分別是：
1.狀態數據過濾隔離
我們知道狀態數據都存儲在一個KV數據庫，而我們可以通過構建特定的前綴實現數據存入和數據查詢時的過濾。也就是說在ChainCode中，只要是進行PutState時，Key必須是：{租戶ID}+“_”+原有Key的格式，這樣我們所有的狀態數據都是以{租戶ID}_開頭的，在進行查詢時也是，必須保證查詢出來的Key帶有同樣的前綴。如果是有區塊鏈瀏覽器提供的話，我們也需要給瀏覽器進行改造，使得在瀏覽數據前用戶必須選擇租戶ID，然後根據租戶ID展示數據。
優缺點：
這樣做可以實現一種邏輯上的數據隔離，實際上所有租戶的鏈上數據都存在同一個區塊鏈中，只是根據調解過濾而已，具有數據泄露的風險，還有因爲某租戶高頻交易導致整個區塊鏈交易大量堆積，排隊等待打包的情況。而且在瀏覽器中，用戶看到大量的區塊，但是點進去卻看不到任何交易（因爲這個區塊裏面的交易都不是該租戶的），也讓人比較迷惑。而且以後想單獨把某個租戶的所有數據獨立出來基本上是不現實的。
2.通道隔離
我們爲每個租戶都創建一個對應的通道，由於通道與通道之間是數據隔離的，所以可以實現租戶之間的數據隔離。這種就不需要在合約上增加租戶ID作爲前綴，合約編寫人員只需要關注業務邏輯即可，不需要關心多租戶對合約的影響。而我們要做的就是在SaaS新建一個租戶時，在Fabric中也對應新建一個通道，並且安裝部署對應的合約。
優缺點：
我們這樣做算的上是數據的所謂物理隔離（因爲不同通道是不同數據庫，或者是磁盤上不同文件夾位置），但是仍然要求各個通道的數據在同一個組織和節點下，所以還不能算真正的物理隔離。另外Fabric對多通道的支持能力比較有限，如果租戶有成千上萬個，那麼就要建那麼多通道，懷疑Fabric到時候會不會崩潰。另外合約部署也是，每次建個新的通道就需要建一個對應的合約，所以到時候在一臺機器上就可以看到上百上千個一模一樣的合約容器實例。
3.組織節點隔離
我們爲每個租戶創建對應的組織和節點，當然這裏我們可以使用新的服務器，如果服務器本身比較強悍，複用現有的服務器也可以。創建好組織節點後，加入現有的Fabric網絡，然後創建新的通道，將新組織節點和需要參與相關流程的節點加入到該通道中，然後安裝部署合約，創建新的網關，在SaaS中配置新租戶對應的新網關的地址。
優缺點：
這樣做最大的好處是實現了真正意義上的租戶之間的物理隔離，不同租戶使用不同的服務器，但是部署非常麻煩，從加入網絡、建立通道、部署合約、創建網關等等都需要新做一遍。另外還有一個問題是排序節點仍然是共用的，所以如果成千上萬的租戶都在發起交易時，排序節點可能成爲瓶頸，導致交易堵塞排隊等待打包的情況。
4.鏈隔離
這是終極隔離方案了，每來一個租戶，我們就創建一條全新的鏈，也就是說從機器到所有節點都是獨立存在的，每個租戶之間沒有任何關係，如果真有關係可能就是在同一個BaaS平臺上被管理吧。
優缺點：
這麼做最大的優點就是徹底的數據隔離，無限的擴展性，理論上來說，不管租戶有100W個還是1000W個，他們之間都互不影響。缺點也很明顯：1是麻煩，每來一個租戶做的準備工作特別多，2是佔用資源嚴重。
總結
由於有這麼多隔離方案，所以我們在實際使用中可以將多種方案混合着使用，比如說我們要求物理隔離的情況下，將2通道隔離和3組織節點隔離混合起來用。假如租戶ID是一個自增的int類型，那麼我們可以按租戶ID個位來決定所在的通道，按租戶ID的十位和以上部分來決定組織節點的位置。我們在創建一個新組織節點時，自動創建10個通道，然後接下來10個租戶就分配到該組織節點的通道中，如果通道滿了，又創建一個新組織節點和對應的10個通道，如此循環往復。
另外還需要說的是，不管是哪種隔離方案，我們都應該做到MSP用戶的隔離，也就是說在操作合約進行Invoke、Query時，都應該使用本租戶對應的用戶和證書來處理，而不應該使用同一個MSP用戶。