淺談SaaS應用開發的難度

標籤：

最近做SaaS應用的很多，這種模式是未來的一種趨勢，這種模式的最大好處就是雲端運算的好處--節約資源。網上有很多人覺得SaaS很簡單，就是一個多使用者租賃模式。這種認識也不能說不對，因為SaaS確實一般都採用多使用者租賃模式。但這種說法非常的不全面，是一盲人摸象。而且很多人認為SaaS模式的架構非常簡單，那就只能說他沒有真正做過SaaS模式或者他們做的SaaS應用是一種非常低級的模式，根本談不上是雲端運算的範疇，就是一個把區域網路的東西放到了公網而已。

作為一種雲端運算模型，一個典型的SaaS模式需要以下三種計算模型支撐：
1）分散式運算模型
      這是基本的模型，也是後兩種模型的基礎；現在非常火的Hadoop其實只是分散式運算模型中一種，而且並不是特別的複雜；
2）分布式資料存放區和訪問模型
      這種模型很多，GFS，HFS，TFS都屬於這類，當然一些分散式資料庫包括阿里的Ocean資料庫都屬於這一類；分散式資料庫訪問和存模數型是SaaS公司專屬應用程式的基礎，對於企業級的應用底層資料節點不採用資料庫當然是可以的，但如果採用資料庫，好處也是非常多的，至少要簡單很多。現有的分散式資料庫對於SaaS應用，特別是SaaS公司專屬應用程式來說採用GreenPlum這類資料庫並不是不可以，但需要根據你的SaaS應用的業務本身進行權衡（主要是資料分離方式和效率的問題）。特別是牽扯到關聯查詢的時候，對於一個按使用者分離和隔離的公司專屬應用程式，如果資料節點採用關聯式資料庫，那麼80%的公司專屬應用程式的關聯查詢都會落到一個節點中，查詢的效率會比較高。如果採用分散式資料庫，一般都很難做到這點，因為分散式資料庫處理這類查詢的時候，都需要把資料集中到一個節點進行處理，雖然可以採用一些策略來減少無效資料的傳輸，但玩玩效果不大。（分散式資料庫中的A表和B表並不一定在一個資料節點的）
3）分布式部署與營運模型
     作為雲端運算下的SaaS應用，必須是可以支撐橫向擴充（Scala out)的,而這些節點（包括應用節點和資料節點）的增加和管理完全靠人力去完成，基本是不可能的事情，因此只要是雲端運算模型下的SaaS應用，分布式部署與營運支撐模型就是必須的；

以上三種模型就構成了SaaS應用的基礎，但SaaS應用又有自己的特殊性，因為牽扯到事務，資料的整理和分離，SaaS應用的分布式資料存放區和訪問往往不能簡單的採用已有的一些開源分布式系統，或者一些開源的分散式資料庫系統，因為在大型的SaaS應用中，資料的分割（分布的基礎）往往也不能做到單一，而資料的分割又會影響資料訪問的路由策略。這就導致通用型的做法不太適合具體的需求。

SaaS的這種基礎實際上就已經非常具有技術含量了，而SaaS業務應用本身，在邏輯上就更難了，並不是訪問資料庫加上一個隔離欄位那麼簡單。一般SaaS系統除了基本的多使用者租賃（注意，設計SaaS的時候一定要以軟隔離為基礎，這樣可以做到最大化的自由，而且不會影響資料庫隔離和資料庫執行個體隔離的需求 ）還會牽扯到線上許可，多時區，多語言，以及功能、頁面、流程的可配置。特別是更深層次的應用更會涉及到線上跨企業資源共用和流程協作的問題，處理這類問題會非常棘手。特別是SaaS線上企業級應用，你需要面對的問題會更加複雜（商務規則的分與合）。如果在做架構的時候，如果沒有考慮到這些問題，後面的噩夢會很多。甚至你可能玩不轉。

SaaS應用其實並不簡單，哪怕就是一個CRM線上應用，也是非常具有業務和技術含量的。根據我的分析，紛享銷客和銷售易雖然融了不少的資，但他們的系統架構還算不上真正意義下的雲端運算模式下的SaaS。金蝶，用友，速達的線上應用雖然沒有深入研究，但通過他們使用者的一些反饋，我感覺60%的可能性是偽雲端運算SaaS應用。當然，如果知道內幕的，可以告訴我。

如果僅僅是號稱，難度都不大，但如果真正做實，雲端運算下的SaaS應用其實難度是不小的。

????

著作權聲明：本文為博主原創文章，未經博主允許不得轉載。

淺談SaaS應用開發的難度