SAAS成熟度模型分級
LEVEL1 定製開發
軟硬件都由SAAS服務商提供，軟件的使用者只需要按時間、用戶數、空間等逐步支付租賃使用費用即可
LEVEL2 可配置
通過不同的配置滿足不同用戶的需求，而不需要爲每個用戶進行特定定製，以降低定製開發的成本。
LEVEL3 高性能的多租戶架構
多租戶：通過一定的策略來保證不同租戶間的數據隔離，確保不同租戶即能共享同一個應用的運行實例，又能爲用戶提供獨立的應用體驗和數據空間。實現方案有獨立數據庫、共享數據庫獨立數據架構、共享數據庫共享數據架構。
高性能：滿足多租戶併發訪問的性能挑戰。
LEVEL4 可伸縮性的多租戶架構
解決租戶數量增加因集中式數據庫帶來的性能瓶頸。
SAAS實現階段性成熟度推進
定製開發 --> 可配置 --> 多租戶 --> 高性能 --> 可伸縮
方式一：邏輯分層可遷移架構(單體式)
採用最終以遷移至分佈式SOA或微服務架構爲目標的分層形式，相當於本地SOA(邏輯分層模式是基於SOA思想， 物理分層模式還是單體)：
架構特徵:
界面層可以與整套應用程序分離也可以不分離；
所有的業務邏輯基本都存在於一套應用程序中，應用服務也存在於同一套應用程序中；
可以使用一個或多個數據源，但多個數據源可以給所有業務邏輯層和應用服務層使用；
表示層可以調用應用服務層，也可以調用業務邏輯層；
服務在應用程序內部相互調用。
架構優點:
所有業務邏輯在同一套應用程序中，所以不用考慮調用鏈治理、不用過多的考慮網絡通訊，也不用考慮分佈式一致性事務，所以與之關聯的中間件都不是必須的。
架構模式簡單，所以對人員技能的要求比較低。
一個或多個數據源，但是由於在同一套程序中，所以事務比較好處理。
中間件比較少，最基礎的中間件就是一個ES用於全文檢索，一個MQ用於解耦和多播任務。
所有的業務邏輯在同一套應用程序中，便於單元測試和集成測試；
部署簡單，一臺服務器一個應用程序，使用負載均衡應對高併發；
由於業務邏輯都在同一個應用程序中，服務治理可以集中做；
使用的開發人員較少；
可以實現顯示層(即表示層和界面層可合併-傳統的MVC，主要針對WEB應用)；
傳統的SOA不允許暴露業務邏輯，只允許通過服務層暴露服務，這個架構允許暴露部分業務邏輯可以獲得一些細粒度的服務，降低開發難度。
架構缺點:
子系統不具備隔離性，一個子系統的崩潰有可能會導致其他子系統的崩潰，只能依靠應用程序中的服務治理手段，或在負載均衡層治理單個接口。 或採用路由分發的形式，每個部署的應用程序包含了完整的代碼，但是因爲路由分發的原因，該部署只提供了部分接口服務。
系統的水平擴展不夠靈活，只有整體的水平應用程序複製的手段，所以不適合超大的應用系統。
不適合需要分庫的系統。
前端UI組件化依賴於前端的分別實現，或依賴於共同的H5頁面。
所有業務領域層都必須面向對象設計編程。
代碼增多容易混亂。
應用程序會很龐大。
成熟度模型的滿足：
定製開發：滿足度高
可配置：滿足度中，通常通過配置+AOP切面編程實現
多租戶：滿足度低，通常只適合共享數據庫共享數據模型模式
高性能：滿足度低，調優手段有限，只能通過多實例負載均衡、查詢優化、編程優化、緩存配置、路由分發的形式滿足。
伸縮性：滿足度低，多數都使用同一個數據庫，同一種緩存策略，相同的NOSQL。
技術選型建議：
PHP > JAVA > GOLANG
單線程同步編程模型下PHP與JAVA的開發時間成本幾乎一致，多線程異步方案JAVA時間成本要高一些，因爲都需要DDD領域驅動設計，單線程同步編程模型實現時間不會有多少潮劇。多線程異步模型JAVA要處理更多的鎖與內存， 這種架構PHP不適合使用異步多線程編程模型。
人力成本PHP低於JAVA，部署複雜度PHP低於JAVA，可複用可伸縮性JAVA高於PHP，項目可測試程度JAVA高於PHP。
技術方案中可能存在的不確定性：
架構師是否能按設計目標完成建模與分層分配；
開發組成員的素質是否能支撐領域驅動設計和單元測試；
總結說明：
簡單易懂，開發快，人力成本低。滿足業務需求，且可遷移。但是，調優手段有限，在系統的複雜度上(併發性應該足以支撐)升到一定程度後，需要更換到分佈式SOA以及微服務(通常在A B輪融資後)。
方式二：SOA架構(分佈式)
架構特徵：
鬆散耦合，方案一僅提供了邏輯層面的鬆散耦合，SOA在此基礎之上還提供了物理層面的鬆散耦合。
暴露API，企業外部也可以調用，方案一同樣提供該特性，但是方案一的暴露API的方式比較統一死板，SOA可以根據需要對不同服務使用不同的API暴露方案。
可重用的服務和可重組服務(方案一僅在邏輯層面重用和重組，物理層面欠缺)；
標準化的服務接口；
精確定義的服務契約；
架構優點：
有根本的獨立性和平臺中性，每個服務都可以與平臺和語言無關，這是方案一不具備的。
重複使用性和服務的獨立性，方案一也具備重複使用性，但是其中的服務會於應用框架產生耦合，不具備獨立性。
擴展性，方案一也具備可擴展性，但其擴展性會受到平臺、語言以及應用框架的限制。
共享的業務服務，方案一同樣具備。
可定製業務流程，這通常在企業商務服務中很有用；
6.有版本治理，這是相當於方案一最重要的一個優點，方案一很難實現多個版本的服務共存，除非將版本治理加入命名空間。
架構缺點：
只討論相對於方案1的缺點
需要更多的中間件，增加開發難度。
架構設計需要更多的精力。
成熟度模型的滿足：
定製開發：滿足度高
可配置：滿足度高，配置、AOP切面編程以及流程控制服務；
多租戶：滿足度中，共享數據庫獨立數據模型模式、共享數據庫共享數據模型模式。
高性能：滿足度中，多實例負載均衡、查詢優化、編程優化、多進程、多線程、異步、非阻塞IO的形式滿足，
伸縮性：滿足度中，多數都使用同一個數據庫，同一種緩存策略，相同的NOSQL。但是因爲是分佈式服務，其伸縮性要比方案1要高。
技術選型建議：
JAVA > PHP > GOLANG
如果需要在可複用、易伸縮、高穩定、低延遲等企業級開發目標上得到滿足，那麼最好選擇JAVA技術路線，此外JAVA SOA架構技術成熟度高。
如果追求開發效率，則使用PHP。PHP SOA架構通常不使用EJB，且服務調用一般使用簡單Json RPC, gRpc, hprose等簡單的rpc服務，服務註冊發現即可以使用客戶端註冊發現也可以使用中間件，服務治理通常在服務端完成，分佈式一致性事務往往採用最簡單的MQ隊列補償保證最終一致性，編程模型通常都是多進程、單線程，較爲簡單，但這些都是以犧牲一定性能換取的簡單。
如果追求兩者平衡，可以使用混合開發，JAVA僅做關鍵核心業務應用服務，PHP可開發業務規則和業務流程的組織。
人力成本上JAVA高於PHP， JAVA需要更多的架構，更多的懂中間件的開發者。項目可測試度JAVA依然高於PHP。
技術方案中可能存在的不確定性：
架構師是否能按設計目標完成建模、分層分配與子系統劃分；
開發組成員的素質是否能支撐領域驅動設計和單元測試；
開發組成員是否有足夠分佈式架構編程知識；
開發組成員是否有足夠的中間件即其它與分佈式有關的知識，EJB/ZOOKKEEPER/Tcc/Saga/Mq等
總結說明：
增加的設計與開發成本可以一定提升SAAS的性能和伸縮性，並將服務從邏輯層面和物理層面全部解耦。
方式三：微服務(分佈式)
微服務可以看做一種特殊的SOA架構， 它和SOA相比，它去掉了EJB，並且提供更細的服務粒度。
微服務通常有兩種架構形式，第一種客戶端直聯，第二種是通過API接口網關模式，對於SAAS而言，第一種可以直接放棄了。看一下第二種架構圖(網上找的，實在懶得畫了)：
架構特徵：
服務組件化；
按業務組織團隊；
做”產品“的態度；
智能端點與啞管道(服務調用方式，實時，異步中間件)
去中心化治理(組件能針對不同的業務特點選擇不同的技術平臺)
去中心化管理數據(多個不同的MySql實例，各服務之間進行“無事務”的調用，數據一致性，只要求數據在最後的處理狀態是一致的即可。補償機制)
基礎設施自動化(自動化測試、自動化部署)
容錯設計(快速檢測出故障資源並儘可能地自動回覆服務是必須被設計和考慮的)
演進式設計
架構優點：
容器化獨立部署、擴展性強；
服務簡單，只關注一個業務功能；
服務自冾，可以直接被外部或其他服務調用，不像SOA需要更高層的業務邏輯組織；
每個服務可以由不同的團隊開發，並且可以使用不同的平臺和語言；
松耦合；
架構缺點：
較高的運維開銷；
較高的領域驅動設計和DEVOPS要求；
並行的團隊開發可能會產生重複性勞動；
需要解決分佈式系統的複雜性；
跨進程之間的事務、大量的異步處理、多個微服務之間的整體測試都需要有一整套的解決方案；
成熟度模型的滿足：
定製開發：滿足度高
可配置：滿足度高，配置、AOP切面編程以及流程控制服務；
多租戶：滿足度高，共享數據庫獨立數據模型模式、共享數據庫共享數據模型模式、獨立數據庫模式。
高性能：滿足度高，多實例負載均衡、查詢優化、編程優化、多進程、多線程、異步、非阻塞IO、容器化的形式滿足，
伸縮性：滿足度高，數據庫拆分，獨立部署的服務，熱部署。
技術選型建議：
JAVA > GOLANG > PHP
JAVA的技術成熟度最高，可選中間件最多。
GOLANG適合從單體到微服務的遷移，不適合從零開始；
PHP社區的微服務只在摸索之中，教育系統常用， 可選中間件較少；
開發成本GOLANG > JAVA > PHP， GOLANG是因爲開源社區不夠成熟，從業人員較少。PHP只在能招聘到技術專家的前提下開發成本較低。
總結說明：
微服務可能是最能滿足SAAS4個成熟度模型的架構模式，但是它對團隊和開發人員的素質要求較高。
當前架構選型二分檢索表
簡單設計了一個選擇初始架構方案的檢索表，因爲每個架構方案都能滿足可配置多租戶的需求，只是對高性能和伸縮性的支持不同，所以當然從“不差錢”開始作爲第一選項：
1、創業階段，投入資金有限(<4個高程)，接受架構緩慢遷移...................2
1、一般土豪，資金不是問題(>=4個人高程)，需要更多的爲未來考慮............4
2、未來1-2年之內預設的直接用戶並不多，不超過50萬..........................A
2、未來1-2年之內預設的直接用戶非常多，遠高於50萬..........................3
3、未來的業務上升曲線異常陡峭，不會有太多架構遷移時間.....................B
3、未來的業務不會比現在複雜太多，或上升平緩，階段性有足夠時間遷移.........C
4、未來的業務異常複雜，需要高度的性能和伸縮性.............................D
4、未來的業務並不複雜，伸縮性和性能可滿足.................................E
A.PHP分層可遷移架構(單體， 如果出於培養團隊需要可直接上JAVA)；
B.PHP微服務架構(分佈式)；
C.PHP SOA架構(分佈式)；
D.JAVA微服務架構(分佈式)；
E.JAVA SOA架構(分佈式)；
選擇的是初始的架構模式，階段性架構遷移需要根據以後的情況選擇，當然，一種技術路線切換到另一種，即使架構模式已經爲未來留出足夠遷移準備，事實上在人力和時間上依然是一個高成本高投入的過程，這點也是要考慮的。
PHP和JAVA的混合模式一般只適合從PHP平臺遷移至JAVA平臺的團隊，混合開發模式不會減少JAVA需要的分工人員，只是能幫助JAVA減少一些業務邏輯表示的工作量。