你們在做saas的哪一層saas的由來saas的成熟度saas系統的三大要素

saas現在可能還是一個比較新的概念，或者說還不是那麼普及，那麼現在我們就來看一下saas的由來并且來看一下saas是不是以後軟體發展的趨勢。

從做項目說起

    軟體公司從做項目開始，針對某個行業會針對性的做不同的項目，項目中包含的内容可能相當，也可能不相同，以XX公司為例，假設XX公司做辦公自動化業務。

這也就是傳統的項目型結構，在項目型結構中，如下圖：

在圖中可以看到，每個項目都會有不同的需求，其中很多是相同的，很多是不同的。

比如功能1，功能3和功能5，這些是相同的。

當這樣的項目非常多的時候，我們就會從中發現很多相同的部分，于是就有了産品。

軟體産品

還是上面的公司，從項目到産品是一個封裝的過程，将相同的部分提練出來，然後将不同的部分開發出來，進行定制化。

根據不同的使用者需求，進行子產品化的定制，并且銷售給不同的使用者，這樣成本會得到很好的控制同時也能産生相當可觀的利潤。

其它子產品根據情況進行定制。

這樣看起來是沒有什麼問題，但是新的問題來了，對于一些不想花大的價錢來使用軟體的使用者來說，産品的價格對于他們來說還是非常高，而且還會增加很大的營運成本，包括資料庫的更新，軟體的更新，硬體的維護和管理等。

于是就有了我們提到了saas，他很好的解決了這些問題，來看一下saas軟體的優勢：

給使用者的優勢：

拿來即用

無需維護

按需使用

随處可用

風險減小

成本降低

先天防毒

給供應商的優勢：

節省銷售成本

節省維護成本

穩健的經驗模式

第一級、可定制

第一級成熟度類似于上世紀90年代初的應用服務提供商(Application Service Provider)所采用的軟體傳遞模式。在符合這一級成熟度的系統中，每個客戶擁有一個為其定制的應用執行個體，這一單獨的執行個體運作在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系統的一大挑戰就是要確定配置 軟體應用的過程本身是簡單且易于為客戶所直接了解并使用的，而且應該無需考慮付出任何額外的開發和維護成本。