Saas化產品和項目型交付產品能統一嗎？

目前，在業務推進方面，產品和項目之爭越來越多。歸根結底，還是因爲既有的Saas化產品如何應付傳統企業項目交付的問題。本文從項目型產品和Saas化產品的關係，架構等方面嘗試給出答案。

1. 前言

如果說爲單個企業實施定製化項目是IT服務商的嬰孩時期，通過產品積累以較低成本爲多個企業實施定製化項目就是IT服務商的少年時期，通過產品SAAS化爲所有企業提供滿足個性化的服務就是IT服務商的青年時期，最終，通過產品的平臺化爲所有企業提供一體化的服務就是IT服務商的壯年時期。成長的過程是不可避免的，因爲身邊很多年少時期的客戶，而花費很多精力去迎合他們，降低了自己的成長速度，並不是一個好的方法。
較好的辦法就是通過開動腦筋，保持現有成長速度不變的情況下，滿足年少客戶的需求。
個人認爲，SAAS化產品路線和項目化實施並不矛盾，是一個不斷演進的過程，是同一事物的不同成長階段。任何的SAAS化產品都是從項目型產品進化而來的。

2. 項目型和SaaS化產品

2.1 Saas化產品長什麼樣？

指標	SAAS化產品	項目型產品
雲部署	√	×
多租戶	√	×
可配置	√	√
可擴展	√	√
數據隔離	√	×
高可用	√	√
熱部署	√	×
獨立升級	×	√
數據可控	×	√
自助註冊	√	×
可監控	√	×
淺色風格	√	√
新手導航	√	√
客戶互動	√	×

從各項指標對比來看，項目型產品和Saas化產品確實不同。並且，從商業模式上也是不同的。但是否意味着爲了項目需求和Saas需求，要走兩條不同路線呢？個人認爲，從商業模式上確實要走兩條路，但在技術實現上是相同的。

2.2 技術實現的演進關係

Saas軟件並不是天生存在的，是一步步演進形成的。公認的，按照成熟度等級可分爲：

• level 1:定製開發

最初級的Saas應用成熟度在應用架構上，跟傳統的項目型軟件應用架構幾乎沒有差別。在這種模式下，軟件服務提供商爲每個客戶定製一套軟件，併爲其部署。每個客戶使用一個獨立的數據庫實例和應用服務器實例。數據庫中的數據結構和應用的代碼可能都根據客戶需求做過定製化修改。

有些 SaaS 軟件公司專門爲單一企業提供軟件服務，也就是一對一的軟件交付模式，客戶可以要求將軟件安裝到自己公司內部，也可託管到服務商那裏。定製能力是衡量企業管理軟件好壞的最重要指標之一， 這也是爲什麼有些軟件開發商在 SaaS 早期堅持採用單重租賃的軟件設計方案。

• level 2: 可配置

第二級成熟度模型相對於最初級的成熟度模型，增加了可配置性。希望通過不同的配置來滿足不同客戶的需求，而不需要爲每個客戶進行特定定製，以降低定製開發成本。這是目前成熟的傳統軟件可以達到的程度。

但是，在第二季成熟度模型中，軟件的部屬架構並沒有發生太大的變化，依然是爲每個客戶獨立部屬一個運行實例。只是每個運行實例運行的是同一份代碼，通過配置的不同來滿足不同客戶的個性化需求。
多重租賃架構下的自定製或自定義功能是 SaaS 軟件的另一核心技術， 領先廠商的產品已經將自定製做到出神入化的地步。客戶可以根據自己公司的業務流程， 自定義字段、 菜單、 報表、 公式、 權限、 視圖、 工作流和審批流等， 做到 S a a S軟件的量身定製，而且不需要編程
知識。

• level 3:高性能多租戶架構

多租戶單實例的應用架構纔是通常真正意義上的Saas應用架構。多租戶單實例的應用架構可以有效的降低Saas應用的硬件及運行維護成本，最大化的發揮Saas應用的規模效應。不過，與傳統的企業應用不同，Saas應用更具備互聯網應用的許多特徵。與傳統單實例的企業應用相比，其數據量和併發量都會有明顯的增加。因此，對於基於傳統應用改造的多租戶應用，還面臨着大量的性能方面的挑戰。

• level 4: 可伸縮性的多租戶架構

在實現了多租戶單實例的應用架構後，隨着租戶數量的逐漸增加，集中式部屬會成爲性能瓶頸。需要通過一定策略實現水平擴展。隨着租戶數量的進一步增大，該架構可以保證僅通過再多部屬幾個實例來滿足更多租戶的使用。

因此，從項目型產品到Saas化產品是同一產品的不同成熟度等級。顯而易見的是，如果實現了高成熟度的產品，則會兼容低成熟度的產品。即，實現了Saas化產品，完全可以滿足項目實施對產品的要求。

2.3 關於輕量化的理解

**目前，有些工業化Saas軟件給人的感覺就是輕量化——功能不多，只能滿足基本的業務需求。那麼，輕量化是否就是Saas軟件的特徵呢？沒有那個Saas軟件將輕量化作爲它的特徵。輕量化不是最終目的，滿足需求才是最終目的。輕量化可以當作產品由小到大過程中的一個階段或者是滿足特定客戶羣體的一個產品版本。只要可配置性做好了，我們的產品完全可以做到按需變化，想輕量就輕量，想複雜就複雜。

如果非要說，Saas軟件必須是輕量化的，也可以這樣理解：依託軟件平臺，軟件本身可以實現輕量化，即部分功能通過平臺實現，減少軟件本身的開發和維護工作量。這就要求Saas軟件是基於平臺的軟件。平臺可以是工業互聯網Paas平臺等。

2.4 如何兼顧項目實施和Saas化產品？

1. 採用組件化技術，將系統劃分成細粒度的模塊，將不同模塊甚至不同功能拆分成組件；
2. 配置性，通過數據可配置、功能可配置、流程可配置及頁面可配置，實現靈活配置；
3. 統一管理，抽取公共業務組件，統一維護。如果組件無法同時滿足，則拆分爲更細粒度的組件。

2.5 小結

綜上所述，採用Saas化架構，是歷史前進的趨勢。技術上講，項目型產品是Saas化產品的最低成熟度等級，實現了高等級成熟度，則可以兼容低等級成熟度。商業模式上，項目型實施和Saas化推廣是不同的商業模式。Saas化產品不等於輕量化。輕量化只是在產品無法滿足各類用戶個性化需求的情況下，一種折中的實現方式，是最終Saas化產品的一個階段。可以採用不同的方式，同時兼顧目前項目實施的需求和未來Saas化需求。

3. SaaS產品實現和微服務架構

Saas化軟件模式大約在2003年就出現了。而微服務架構大約在2014年出現。所以說，實現Saas化產品並不一定使用微服務架構。早期的salesForce,八百客，早期的阿里巴巴等的Saas化產品，肯定不是基於微服務的架構。但隨着軟件設計方法的不斷髮展，微服務架構也迎合了時代發展的要求。

3.1 軟件架構演進歷史

軟件架構一般劃分爲應用架構和基礎架構。其中應用架構是指構建業務系統本身需要關注的設計內容，而基礎架構是指部署業務系統時需要考慮的設計內容。

基礎架構演進路線爲:

graph TD
  A[大型機] -->B[小型機]
  B[小型機] -->C[PC Server]
  C[PC Server] -->D[雲計算]

應用架構的演進路線爲：

graph TD
A[面向過程] -->B[對象組件]
B[對象組件] -->C[多層架構]
C[多層架構] -->D[微服務架構]

面對的業務場景爲：

graph TD
A[科學計算] -->B[信息服務]
B[信息服務] -->C[企業應用]
C[企業應用] -->D[互聯網+]

3.2 爲什麼選擇微服務架構？

微服務的本質：一種更優的分工合作機制，加速分工，促進合作，幫我們成就更大的夢想！

從產品來說，各類自研應用採用微服務架構是是爲了能夠藉助平臺的力量，藉助雲計算的力量，成爲有生命力的產品。這就要求我們的架構也最好使用分佈式架構，以充分利用雲計算提供的各層能力。傳統分層架構，如MVVM,SSH框架等，是單體架構，不具備搭建分佈式系統的能力，如果要將單體架構改造成分佈式架構，還需要藉助其他框架，如EJB等，才能實現。將來和工業互聯網平臺的融合，也只能是集成式的淺融合。

從工業互聯網平臺來說，工業互聯網平臺白皮書推薦的技術架構也是分佈式微服務架構，也就是說是業內事實上的標準。這樣，我們的平臺可以將各類應用通用的權限、用戶、消息等做成公共組件，統一維護，降低產品維護成本。另外，藉助雲計算能力，我們的平臺可以集成大數據分析平臺，智能決策平臺，爲各類應用提供高價值功能，使應用成爲開放的，不斷升級的產品。如果走不同的架構，那麼需要兩個團隊來維護，還會有團隊協同問題，難於管理。

從團隊和研發管理來說，不會像以往的傳統軟件研發那樣，需要依靠那些既懂業務，又懂開發的人員負責從業務到開發一條龍。這大大降低了對人員的要求，每個人只需要是單個領域的專家，促進了人員的分工合作，具備了把產品做大的可能性。

當然，微服務存在缺點，就是管理和維護複雜。當我們的產品規模達到一定程度後，微服務管理和維護會比較複雜，需要專業團隊運維。

4. 項目實施的顧慮——微服務架構和前後端分離

項目實施的目標是爲了盈利。不管是Saas化產品和項目型產品，都是爲了滿足客戶的需求，業務上沒有顧慮。而提到微服務架構，大家詬病的就是一個功能的開發需要前端工程師和後端工程師兩人來完成，比起傳統項目一個人開發來說，看似成本高了一倍。如何解決這個問題？

第一種，接受微服務架構帶來的好處，而不採用前後端分離的開發方式。目前，我查到的資料來看，微服務架構一般是前後端分離的，而我們採用的Springboot框架，也是前後端分離的。第一條路可能行不通。

第二種，放棄微服務架構，採用傳統的單體分層架構。那就成了做傳統軟件了，無法有效的利用現有的雲計算、人工智能和平臺的能力。爲了節省幾個人工費，讓我們的產品倒退一大步，得不償失。

第三種，從根源入手，解決人力成本高的問題。我想到的，可以通過招聘或培養懂前後端的人做項目實施。這種有可能可以。通過軟件本身的可配置性和可擴展性實現，這個可能是根本解決辦法。如果產品配置性和擴展性做好了，是不是就意味着實施週期的降低，快速的交付。這樣，就可以降低項目實施的費用了。

參考

1. 爲什麼要前後端分離？優缺點？
2. 微服務到底改變了什麼？
3. 微服務，爲什麼可以加速分工，促進合作？
4. 微服務系列
5. 架構這麼多，該選哪一個？
6. 哪些業務適合微服務？
7. 微服務爲什麼從前後端分離開始？
8. 什麼是微服務架構，詳解？
9. 微服務的優勢和不足。
10. 詳細講解SaaS項目解決方案
11. SAAS產品設計原則及產品架構特點
12. SAAS軟件架構淺談和設計
13. Saas系統架構思考，多租戶架構設計分析。
14. Saas服務與傳統ERP軟件的區別？
15. Saas是什麼？和傳統軟件的區別？
16. saas模式和傳統軟件模式區別？
17. 互聯網時代的軟件革命-Saas架構設計-葉偉
18. 微服務設計-sam newman
19. Saas架構新特性-八百客，李智