web 應用程式轉化為多租戶 SaaS技術探討及 解決方案
典型的 web 應用程式和 SaaS
Web應用銷售肯定需要搭建軟硬體環境以及系統部署及資料庫安裝。 SaaS 區別於其他應用程式的主要特徵就是能夠使客戶在使用應用程式時按照使用量付費。他們不需要為軟體購買許可，也不需要安裝、託管和管理它。這方面的操作全部由提供 SaaS 軟體的組織負責。
簡單來說就是以上三種：
1.租戶各自獨立使用應用和資料庫服務。
實現思路：租戶購買服務後，需要單獨部署系統和資料庫。nginx（或者其他伺服器）也需要配置對應的租戶服務的跳轉。跳轉可以根據二級域名（每個租戶分配一個獨立的二級域名。通過二級域名訪問單獨的應用或應用叢集，應用訪問該租戶獨立的資料庫例項。）或者使用租戶指定的域名。 【效能高，運維成本大，開發成本基本為零，硬體成本增加】
2.租戶共用一組應用服務，各自單獨的資料庫服務。
實現思路：租戶在註冊時，會分配一個租戶編碼。當租戶通過統一的域名訪問系統時，應用會根據使用者的會話ID或Token資訊，獲取使用者的租戶編碼，並根據租戶編碼，將租戶對應的資料來源繫結到當前請求中。 【改造成本適中】
3.租戶合用一組應用服務和單獨的資料庫服務。
實現思路：租戶在註冊時，會分配一個租戶編碼。當租戶通過統一的域名訪問系統時，應用會根據使用者的會話ID或Token資訊，感知使用者的租戶編碼，並根據租戶編碼，在資料庫找到對應的單獨表或者篩選屬於該租戶的資料。 【開發成本大，後期運營成本小，開發成本大】
實現方式
第一種情況無開發成本，只需運維部署 以下只探討情況二的實現方式。 融合第二種情況和第三種情況
改造內容
負載均衡改造內容
- 快取資料共享
- 檔案資源共享
- 資料庫資源共享
具體改造
- ecache切換為redis快取，整合redis框架
- 快取結構調整、以及舊方法改造
- redis操作工具類 【優先調整已用方法】
- 快取序列化方式選擇
- session redis快取共享改造
- 檔案系統通過掛載雲盤方式 【可靠後、暫排後期】？或者七牛雲【工期較長】
- redis視覺化管理介面（由於序列化問題，導致redis客戶端無法檢視快取具體內容）【暫未實現】
多租戶改造內容
- 動態資料來源建立
- 資料來源自動根據組織ID切換 【包括redis資料來源】
- 資料來源手動切換
- 資料庫事務問題【儘量不涉及到多資料來源事務】
過程解決的問題
參見整理文件
orgId維護思路
1）組織機構、人員新增組織ID欄位 orgId 2）新增新增租戶組織機構的方式：通過該方式能夠制定該機構的ID（不用原有機構ID生成策略），並設定orgId = this.id 【即orgId等於此機構的ID】 3）修改原機構update和insert：設定其orgId = 上級機構的orgId 4）對於其他業務資料表改造原則：
graph LR A[業務表] -->|不含公司ID|B2(業務表) A[業務表] -->|含公司ID|B1(業務表) A[業務表] -->|含UserID|B3(業務表) A[業務表] -->|不含含UserID|B4(業務表) B1 -->|業務資料量大|D1[新增OrgId] B1 -->|業務資料量小|D2[關聯office表查詢] B2-->D1 B3 -->|業務資料量小|D2 B4-->|無論資料量大小|D3[新增OrgId]5）單獨維護orgId引數表：包含資料庫連線資訊、失效時間、校區及人員的數量限制。
參考資料
https://www.jianshu.com/p/54f35fa2f374
https://www.ibm.com/developerworks/cn/cloud/library/cl-multitenantsaas/
資料層的多租戶淺談
https://www.jb51.net/article/133074.