SaaS架構經驗總結

2B Saas系統最近幾年都很火。不少創業公司都在嘗試建立企業級別的應用 cRM, HR,銷售, Desk Saas系統。不少Saas創業公司也拿了大額風投。畢竟Saas相對傳統軟件的優點很是明顯。   

最近一年，有幸架構一個Crm saas 系統，上線了幾個月來，各方面都比滿意。整個系統建立過程，踩了不少坑，收穫也比較多。總結一下Saas系統架構一些特色：

 

1.分層設計

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. 容量估計

 

暫時先寫這麼多了。有時間再補充。