典型的 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.htm