大客戶私有部署的SaaS方案思考

概述

近來公司需要給大客戶做私有部署，由於客戶分公司較多，業務廣泛，集團希望共享客戶資源，統一服務流程，共享監控資料和統計資料，需要我們這邊深入考慮部署方案。
　　目前我們使用的SaaS架構是多租戶中的第三種方案，即共享資料庫，共享 Schema，共享資料表。如果你不瞭解神碼是SaaS？請移步維基百科詳細查閱（軟體即服務-SaaS）。簡單來說是實現了在多使用者環境下（此處的多使用者一般是面向企業使用者）共用相同的系統或程式元件，並且可確保各使用者間資料的隔離性，由廠商提供統一託管和升級，是雲端計算時代的產物。由於絕大多數SaaS解決方案都基於多租戶架構，所以有必要先了解下神碼是多租戶架構。

多租戶

軟體多租戶：指的是一種軟體架構，其中一個例項的軟體在伺服器上執行，並提供多租戶。租戶是一組使用者，他們共享具有軟體例項特定許可權的公共訪問許可權。通過多租戶架構，軟體應用程式旨在為每個租戶提供例項的專用共享 - 包括其資料，配置，使用者管理，租戶個人功能和非功能屬性。多租戶與單租戶（多例項架構）形成對比，其中單獨的軟體例項代表不同的租戶執行。

多租戶資料隔離方案

在當下雲端計算時代，多租戶技術在共用的資料中心以單一系統架構與服務提供多數客戶端相同甚至可定製化的服務，並且仍可以保障客戶的資料隔離。目前各種各樣的雲端計算服務就是這類技術範疇，例如阿里雲資料庫服務（RDS）、阿里雲伺服器等等。
多租戶在資料儲存上存在三種主要的方案，分別是：
　　1. 獨立資料庫

　　這是第一種方案，即一個租戶一個數據庫，這種方案的使用者資料隔離級別最高，安全性最好，但成本較高。
　　優點： 為不同的租戶提供獨立的資料庫，有助於簡化資料模型的擴充套件設計，滿足不同租戶的獨特需求；如果出現故障，恢復資料比較簡單。
　　缺點： 增多了資料庫的安裝數量，隨之帶來維護成本和購置成本的增加。

這種方案其實與傳統的一個客戶、一套資料、一套部署類似，差別只在於軟體統一部署在運營商那裡。如果面對的是銀行、醫院等需要非常高資料隔離級別的租戶，可以選擇這種模式，提高租用的定價。如果定價較低，產品走低價路線，這種方案一般對運營商來說是無法承受的。

2. 共享資料庫，獨立 Schema

　　這是第二種方案，即多個或所有租戶共享Database，但是每個租戶一個Schema（也可叫做一個USER）。底層庫比如是：DB2、ORACLE等，一個數據庫下可以有多個SCHEMA
　　優點： 為安全性要求較高的租戶提供了一定程度的邏輯資料隔離，並不是完全隔離；每個資料庫可支援更多的租戶數量。
　　缺點： 如果出現故障，資料恢復比較困難，因為恢復資料庫將牽涉到其他租戶的資料，如果需要跨租戶統計資料，存在一定困難。

3. 共享資料庫，共享 Schema，共享資料表
　　這是第三種方案，即租戶共享同一個Database、同一個Schema，但在表中增加TenantID多租戶的資料欄位。這是共享程度最高、隔離級別最低的模式，即每插入一條資料時都需要有一個客戶的標識。這樣才能在同一張表中區分出不同客戶的資料。
　　優點： 三種方案比較，第三種方案的維護和購置成本最低，允許每個資料庫支援的租戶數量最多。
　　缺點： 隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量； 資料備份和恢復最困難，需要逐表逐條備份和還原; 供應商服務不穩定時，一損俱損，全部租戶都受到影響。

如果希望以最少的伺服器為最多的租戶提供服務，並且租戶接受犧牲隔離級別換取降低成本，這種方案最適合。 在SaaS實施過程中，有一個顯著的考量點，就是如何對應用資料進行設計，以支援多租戶，而這種設計的思路，是要在資料的共享、安全隔離和效能間取得平衡。

選擇合理的實現模式

瞭解了這麼多，再回到我們業務上來。目前從客戶需求上來看，大致有幾點重要訴求：

1. 管理層對資料共享方面傾向度更高，尤其是Boss。
2. 監控和統計方面，不同的分公司主要關心自己的業務監控，而Boss想打通整個服務流程。
3. 另外客戶有自己的大資料分析平臺，希望日後能做資料探勘。

整體上使用者對資料共享要求較高，安全隔離和效能方面，由於是私有部署在自己機房，可以通過硬體升級來實現水平擴容。分公司有些業務差別較大，分開服務商有助於適配自己公司業務，所以比較適合第三種方案。

不同分公司之間想要共享業務流程，可以加入到相同的組（集合）中來。便於資料交流和業務分發，比如IM轉接，熱線轉接，工單流轉等。程式碼上需要改造的是，登入時需要檢測是否開啟了共享組，讀取自己所在的共享組資訊。也可以通過配置檔案實現功能模組的共享和資料表的共享。

配置檔案改動：

; 共享組開關 default 0
shared.switch = 1
;共享服務商列表 
shared.list = 1,2,3,4,5
;共享模組列表 1-im 2-cc 3-tt 
shared.module = 1,2,3
;共享資料表
shared.table = 'user,...'

業務轉接時邏輯改動:

<?php
$sharedInfo = array(
      'task_id'=>1001,//主鍵id
      'task_content'=>'您有一個來分公司1的轉接請求’，
      'transfer_reason'=>'來找你的',
      'task_source'=>1//任務來源服務商id
      ...
);

對於im來說，可以做到單向或雙向跨服務商轉接會話，共享監控資料，統計服務記錄。
入口處，只顯示本服務商的技能組;
工作臺上可以控制多個服務商技能組;
監控處，自行決定是否展示別的服務商資料，預設只展示本服務商的資料;
統計處，同監控。

整體結構大致如下：

實現的效果是，可以自由組合不同服務商，實現資料共享。

另外，如果真的要做元件式的功能，我們需要引入一套ORM框架，實現使用者登入就完成功能配置模型的初始化。省去在各個功能處大量的if/else工作。

以上就是我對私有部署，多租戶模型共享的理解和方案，如果不合理地方，歡迎指正。

參考：

1. 資料層的多租戶淺談
2. SaaS多租戶資料隔離的三種方案
3. 多租戶和單租戶SaaS的架構對比