saas的由來
saas現在可能還是一個比較新的概念，或者說還不是那么普及，那么現在我們就來看一下saas的由來並且來看一下saas是不是以后軟件發展的趨勢。
從做項目說起
軟件公司從做項目開始，針對某個行業會針對性的做不同的項目，項目中包含的內容可能相當，也可能不相同，以XX公司為例，假設XX公司做辦公自動化業務。
這也就是傳統的項目型結構，在項目型結構中，如下圖：
在圖中可以看到，每個項目都會有不同的需求，其中很多是相同的，很多是不同的。
比如功能1，功能3和功能5，這些是相同的。
當這樣的項目非常多的時候，我們就會從中發現很多相同的部分，於是就有了產品。
軟件產品
還是上面的公司，從項目到產品是一個封裝的過程，將相同的部分提練出來，然后將不同的部分開發出來，進行定制化。
根據不同的用戶需求，進行模塊化的定制，並且銷售給不同的用戶，這樣成本會得到很好的控制同時也能產生相當可觀的利潤。
其它模塊根據情況進行定制。
這樣看起來是沒有什么問題，但是新的問題來了，對於一些不想花大的價錢來使用軟件的用戶來說，產品的價格對於他們來說還是非常高，而且還會增加很大的運營成本，包括數據庫的升級，軟件的升級，硬件的維護和管理等。
於是就有了我們提到了saas，他很好的解決了這些問題，來看一下saas軟件的優勢：
給用戶的優勢：
- 拿來即用
- 無需維護
- 按需使用
- 隨處可用
- 風險減小
- 成本降低
- 先天防毒
給供應商的優勢：
- 節省銷售成本
- 節省維護成本
- 穩健的經驗模式
saas的成熟度
第一級、可定制
第一級成熟度類似於上世紀90年代初的應用服務提供商(Application Service Provider)所采用的軟件交付模式。在符合這一級成熟度的系統中，每個客戶擁有一個為其定制的應用實例，這一單獨的實例運行在SaaS服務提供商的硬件之上。從系統架構而言，這一級別的SaaS系統和傳統的本地安裝軟件非常相似，同一客戶的不同終端用戶使用客戶端軟件連接同一個應用實例，但這一客戶實例和服務提供商同時運行的其它客戶的應用實例相比是完全獨立的。
因此，傳統的服務器-客戶端的應用可以在花費少量開發資源和無需重新設計整個架構的前提被改造成符合這一級別的SaaS模式的系統。雖然相比起其它更為成熟的SaaS模式的系統，這一類型的系統所能給SaaS服務 提供商帶來的收益有限，但它確實可以讓SaaS服務提供商通過整合服務器硬件和管理來降低成本，因此目前有不少國內的軟件廠商就嘗試應用這種手段將其已有的傳統系統改造為相應的SaaS系統。
這種怎么看怎么像我們傳統意義上的軟件開發模式，就是找客戶，然后根據客戶的需求進行定制化的開發，也就是可定制的，但是需要多次開發，一個客戶擁有一個實例。
比如上面我們的例子，有可能會在應用服務提供商處產生多個軟件的實例。
第二級、可配置
在符合第二級成熟度的系統中，每個客戶還是各自擁有一個單獨的應用實例，但不同之處在於第一級中的用戶實例是根據每個客戶的需求單獨定制的，而在這里，每個客戶使用相同的代碼。SaaS服務提供商通過詳細的具體配置選項來允許客戶改變自身應用的外觀和系統行為。盡管如此，不同的應用實例之間還是保持完全獨立運行。
將所有客戶的應用實例集中於同一代碼庫之下極大的減少了對於SaaS服務提供商的服務需求，因為此時對系統代碼任何微小的改變都會立刻影響所有的當前客戶，這下也就可以節省為每個客戶的應用實例單獨升級或修改的成本。但是相比起第一級的成熟度模型，如果試圖將一個傳統的服務器-客戶端的應用改造成符合第二級成熟度的SaaS系統，將需要花費更多的重新架構和開發的成本。
最后，同第一級模型有一處類似的是，符合第二級成熟度模型的系統一樣需要SaaS服務提供商准備足夠的硬件和存儲空間來支持潛在的大量的同時運行的應用實例。
第三級、可配置和高效的多用戶支持
在第三級的成熟度模型中，服務提供商通過運行一個應用實例來為所有的客戶服務，同時通過可配置的元數據來給每一個客戶提供不同的用戶體驗和功能。可配置的權限控制和安全策略則確保了每一個客戶的數據被單獨存放且與其它客戶的數據相隔離。因此，從最終用戶的角度出發，他們將感受不到所使用的應用實例也在同一時間為其他客戶所共享。
這種方式解決了這樣一個問題，那就是隨着SaaS 服務供應商業務的發展和客戶的增多，只能通過提供更多的服務器資源來運行更多應用實例，現在SaaS服務供應商可以用同樣數量的服務器資源為更多的客戶服務，從而比起前兩級成熟度模型的系統，更有效的利用了硬件資源，降低了運營成本。
但這一架構的不利之處在於無法靈活的提升系統性能，除非使用數據分區技術來提高數據庫的性能，一般來說SaaS服務供應商將只能通過把系統轉移到更為強大的服務器上來提升性能。
第四級、可配置和高效的多用戶支持並且可擴展
在這一級也就是最后一級的成熟度模型中，SaaS服務供應商將通過運行一個負載均衡的具備權限驗證功能的平台來為眾多的客戶同時服務，每個客戶的業務數據將被單獨存放，同時提供使用可配置的元數據來為每一個客戶提供其自身需要的獨一無二的用戶體驗。符合這樣一個成 熟度的SaaS系統將可以輕易支持一個相當大的客戶數目，這是因為在其后台運行的服務和業務實例可以在不修改系統架構的基礎上隨着需求動態的增加和減少， 任何的系統變動和修復可以輕而易舉的同時作用於數以千計的客戶環境中，就如同只為單一客戶服務時同樣簡便。
saas系統的三大要素
從系統架構的角度來看，要設計一個符合實際業務需求的能夠支持多用戶同時訪問的SaaS系統就必須關注以下三大要素：可擴展(Scalable)、高效的多用戶支持(Multi-Tenant-Efficient)、可配置(Configurable)
可擴展
可擴展意味着最大程度的提高系統並發性，更有效的使用系統資源。比如說應用，優化資源鎖的持久性，使用無狀態的進程，使用資源池來共享線和數據庫連接等關鍵資源，緩存參考數據，為大型數據庫分區等技術。
高效的多用戶支持
可高效的多客戶支持則是設計基於SaaS模式的系統中最為重要的一環。比如說當一個用戶試圖通過某個基於SaaS模式的客戶關系管理應用(Customer Relationship Management)來訪問本公司的客戶數據時，它所連接的這一基於SaaS模式的客戶關系管理應用可能正同時被來自不同企業的成百上千個終端用戶所使 用，此時所有用戶完全不知道其他並發用戶訪問的存在。這種在SaaS應用中極為常見的場景就要求基於SaaS模式的系統可以支持在多用戶間最大程度共享資 源的同時嚴格區分和隔離屬於不同客戶的數據。
可配置
當在傳統的本地安裝軟件的使用環境中談論可配置性時，直接修改部分代碼進行二次開發來適應當前用戶的需求是比較常見的解決方案。但在基於SaaS模式的使用環境中，如果業務應用的任何部分被修改了，則這一修改將可能同時影響所有當前客戶的使用環境。因此，一般而言在SaaS模式的使用環境中，客戶使用元數據(Metadata)來為其終端用戶配置系統的界面以及相關的交互行為。由此可見，設計SaaS系統的一大挑戰就是要確保配置 軟件應用的過程本身是簡單且易於為客戶所直接理解並使用的，而且應該無需考慮付出任何額外的開發和維護成本。