ToB Saas系統最近幾年都很火。很多創業公司都在嘗試創建企業級別的應用 cRM, HR,銷售, Desk Saas系統。很多Saas創業公司也拿了大額風投。畢竟Saas相對傳統軟件的優勢非常明顯。
最近一年，有幸架構一個Crm saas 系統，上線了幾個月來，各方面都比滿意。整個系統創建過程，踩了很多坑，收獲也比較多。總結一下Saas系統架構一些特點：
Saas系統分級：
SaaS系統架構成熟度模型的5個級別——從“混亂”到“烏托邦“
第0級（混亂）：每次新增一個客戶，都會新增軟件的一個實例。
第1級（受控的混亂）：所有客戶都運行在軟件的同一個版本上，而且任何的定制化都通過修改配置來實現。
第2級（多租戶[multi-tenant]、高層建築[Highrise]）：所有的客戶都已經可以在軟件的同一個版本上運行了，而且他們都在同一個“實例”上運行。
第3級（多租戶， 擴建[Build-Out]）：此時你已經擁有了多租戶、單一版本的軟件模型。不過你還是可以通過硬件擴展（scale-out）的方式來進行擴充。
第4級（烏托邦）：如同第3級，除非你可以找出有效的方式，以在不同的“實例”上運行不同版本的軟件。
應用程序必須支持多租戶：
多租戶可以分為幾個不同的類別（如列表下方的圖所示）：
1.1，雲中的簡單虛擬化，其中只對硬件進行共享。
1.2，共享應用程序，對每個租戶使用不同的數據庫。
1.3，共享應用程序和數據庫（效率最高，真正的多租戶）。
1.分層設計
Saas系統分層大概是：
Saas系統分層
Saas系統分層：租戶識別>應用層>數據訪問層>緩存層>數據庫
業務代碼都是寫在應用層。
租戶識別可以用spring攔截器實現，然后使用ThreadLocal傳遞給后端
數據庫和緩存層對應用層應該是透明的。程序員在寫代碼的時候，只關心業務邏輯，不應該擔心多租戶的問題。
2.數據隔離要透明
saas系統說起來很簡單，任何系統似乎加個tenant_id(租戶id)就變成saas系統了。比如原來的用戶登錄是：
select username,password from users where email='abc@qq.com'改成
select username,password from users where email='abc@qq.com' and tenant_id =1;對於復雜業務的saas系統，這樣做法非常危險，而且開發效率很低。你想想如果那個程序員寫sql時候忘了加 “ and tenant_id =1” . 結果不堪設想。
比較好做法是在數據庫訪問層對SQL進行改寫。
TenantContext.exec("select username,password from users where email='abc@qq.com' ");在連接池根據TenatnContext改寫Sql.
這樣做好處是，一來程序猿最多把系統搞down了，也不至於信息串了互相泄露。二來將來做分表分庫也很方便，上層應用不用修改。
3. 租戶識別方案
比較好做法是通過url識別租戶。系統是給租戶生成一個隨機的三級域名，比如 abc.crm.baidu.com. 如果客戶想使用自己的域名，可以在cname到我們生成的三級域名，並在管理系統里面做綁定。
這樣一個租戶可以有兩個域名，訪問saas,一個隨機生成的三級域名，另外一個租戶自己的域名.代碼里面可以根據過來的域名，判斷是那個租戶然后初始化TenantContext.
如果不想通過域名來做，也可以通過登錄名來判斷。這種方式要涉及到租戶切換問題。
4. 智能DNS
以后補充。
5. 租戶管理系統（計費，訂購，定制，充值，催繳）
Saas系統是必須考慮計費系統和租戶控制系統。這個系統需要都是獨立設計。比如那個租戶購買了那些模塊，一個月多少錢。租戶可以創建最多的用戶數。計費到期郵件提醒等功能。
計費方式一般有兩種，周期性計費，類似月租方案，和使用量計費,用多少付多少。 周期性計費比較簡單。也可以兩者結合起來。
6. 定制化開發
SAAS的優勢在於一套系統多人使用，似乎和定制化開發有沖突。比如A客戶想要A功能，B客戶不想要。但定制化開發是無法避免的，比如CRM系統這樣復雜的系統，不可能一套系統滿足所有公司的要求。定制化開發盡可能分系統，分模塊去做。然后通過控制台中配置不同租戶訂購不同模塊，那些模塊可以在前端頁面上顯示。不同的子系統需要分開部署。前端可通過nginx根據url分發，比如 abc.crm.baidu.com/bi/xxx/xx這個地址，就分發到BI子系統。不要嘗試OSGI去搞模塊化，這個是個大坑。
還有開發和產品，現有需求一定要分析清楚，不要一上線發現后患無窮。新功能盡量做的獨立可以配置。
7. 灰度升級
SAAS付費企業客戶對系統問題都特別敏感。 為了減少升級可能出現問題的影響范圍，一般都采用灰度升級策略。如果使用了url來區分不同租戶，灰度升級配置就會很方便。可以配置nginx 來根據域名做分發，比如租戶A（aaa.com）到實例1（版本1.0），租戶B(bbb.com)到實例2(版本). 當需要域名配置非常多的時候，nginx配置文檔會亂。這塊時候可以考慮使用nignx_lua來寫一些擴展模塊。
8. 容量估計
9. Saas平台架構分層分析
Saas平台架構需要完成從用戶申請鏈接saas到用戶對自己購買的功能模塊的應用整個過程，用戶用起saas看似簡單快捷，但這個過程卻需要saas平台架構默默完成的非常復雜的處理過程。通過對saas平台架構的了解，可以清晰的分化數據的處理過程，讓用戶也可以明白saas平台架構處理數據的優勢。下面介紹：saas平台架構分為哪幾部分。
saas平台架構之呈現層：
saas平台架構的呈現層可以使用的客戶端可能都瀏覽器或本地客戶端。如果是瀏覽器則需要Web界面技術、交互技術等技術（如：HTMl5技術、CSS3技術、Ajax技術等）的支持，如果是軟件客戶端則需要遠程桌面技術、軟件交互技術等技術支持。
saas平台架構之調度層：
saas平台架構的調度層體現分布式系統的特性之一。調度層首先負責識別並通過AAA認證每個用戶請求，然后根據業務處理器的負載、業務特征進行合理的調度。通過應用這樣的架構SaaS平台可以橫向擴展。此外在存儲、緩存等方面為了滿足平台的橫向擴展需求，調度層也必須具有良好的可擴展性。
saas平台架構之業務層：
saas平台架構的業務層負責接收調度層轉發過來的請求，而且還要通過對接受到的請求執行真正的業務邏輯。一般來說業務邏輯的執行使用一台服務器就夠了。因此業務層實際是由一排對等的服務器組成的，每台服務器都執行相同的業務邏輯。
saas平台架構之數據層：
saas平台架構的數據庫集群用於處理存儲關系性很強並且對事務性要求很高的業務數據，這類數據目前還要用傳統的數據庫集群技術來解決，saas平台架構的數據庫集群主要是根據業務特征制定數據拆分方案。同時分布式數據庫用於存放海量但關系性不強的數據（如：用戶的操作日志等）。
以上是對“Saas系統架構的思考，多租戶Saas架構設計分析”的介紹，從saas平台架構處理數據可以看出saas平台的應用有很強的優勢，如用戶使用saas非常方便簡單只要瀏覽器或本地客戶端接口，saas平台處理數據要經過層層認證saas產品安全可靠，saas平台優化處理數據提高saas性能。
多租戶Saas系統架構還應該滿足以下需求：
| 編號 | 需求 | 描述 |
|---|---|---|
| 1 | 軟件授權 | 雲平台付費授權機制，可按時間、功能、數量等進行付費授權 |
| 2 | 組織入駐 | 允許組織主動申請加入平台 |
| 3 | 實名認證 | 個人實名認證、組織實名認證 |
| 4 | 資質審核 | 個人和組織的資質審核，如對獲得的證書或榮譽進行審核 |
| 5 | 組織綁定 | 個人賬戶綁定組織，與組織建立關聯關系 |
| 6 | 組織解綁 | 個人賬戶與組織進行解綁 |
| 7 | 賬戶注銷 | 個人賬戶注銷，並銷毀所有個人資料和檔案 |
| 8 | 統一登錄 | 即 SSO |
| 9 | 統一注冊 | 提供統一的用戶注冊頁面 |
部分資料整理自：
http://www.ruanally.com
http://qk.gam7.com
http://www.ruanbe.com