SaaS的幾種架構(gòu)解析

時(shí)間：2023-03-14 08:12:01 | 來(lái)源：電子商務(wù)

時(shí)間：2023-03-14 08:12:01 來(lái)源：電子商務(wù)

文章轉(zhuǎn)載自:SaaS的幾種架構(gòu)解析 - 高效碼農(nóng)

SAAS成熟度模型分級(jí)

LEVEL1 定制開發(fā)
軟硬件都由SAAS服務(wù)商提供，軟件的使用者只需要按時(shí)間、用戶數(shù)、空間等逐步支付租賃使用費(fèi)用即可

LEVEL2 可配置
通過(guò)不同的配置滿足不同用戶的需求，而不需要為每個(gè)用戶進(jìn)行特定定制，以降低定制開發(fā)的成本。

LEVEL3 高性能的多租戶架構(gòu)
多租戶：通過(guò)一定的策略來(lái)保證不同租戶間的數(shù)據(jù)隔離，確保不同租戶即能共享同一個(gè)應(yīng)用的運(yùn)行實(shí)例，又能為用戶提供獨(dú)立的應(yīng)用體驗(yàn)和數(shù)據(jù)空間。實(shí)現(xiàn)方案有獨(dú)立數(shù)據(jù)庫(kù)、共享數(shù)據(jù)庫(kù)獨(dú)立數(shù)據(jù)架構(gòu)、共享數(shù)據(jù)庫(kù)共享數(shù)據(jù)架構(gòu)。

高性能：滿足多租戶并發(fā)訪問(wèn)的性能挑戰(zhàn)。

LEVEL4 可伸縮性的多租戶架構(gòu)
解決租戶數(shù)量增加因集中式數(shù)據(jù)庫(kù)帶來(lái)的性能瓶頸。

SAAS實(shí)現(xiàn)階段性成熟度推進(jìn)
定制開發(fā) --> 可配置 --> 多租戶 --> 高性能 --> 可伸縮

方式一：邏輯分層可遷移架構(gòu)(單體式)
采用最終以遷移至分布式SOA或微服務(wù)架構(gòu)為目標(biāo)的分層形式，相當(dāng)于本地SOA（邏輯分層模式是基于SOA思想， 物理分層模式還是單體）：

架構(gòu)特征:
界面層可以與整套應(yīng)用程序分離也可以不分離；

所有的業(yè)務(wù)邏輯基本都存在于一套應(yīng)用程序中，應(yīng)用服務(wù)也存在于同一套應(yīng)用程序中；

可以使用一個(gè)或多個(gè)數(shù)據(jù)源，但多個(gè)數(shù)據(jù)源可以給所有業(yè)務(wù)邏輯層和應(yīng)用服務(wù)層使用；

表示層可以調(diào)用應(yīng)用服務(wù)層，也可以調(diào)用業(yè)務(wù)邏輯層；

服務(wù)在應(yīng)用程序內(nèi)部相互調(diào)用。
架構(gòu)優(yōu)點(diǎn):
所有業(yè)務(wù)邏輯在同一套應(yīng)用程序中，所以不用考慮調(diào)用鏈治理、不用過(guò)多的考慮網(wǎng)絡(luò)通訊，也不用考慮分布式一致性事務(wù)，所以與之關(guān)聯(lián)的中間件都不是必須的。

架構(gòu)模式簡(jiǎn)單，所以對(duì)人員技能的要求比較低。

一個(gè)或多個(gè)數(shù)據(jù)源，但是由于在同一套程序中，所以事務(wù)比較好處理。

中間件比較少，最基礎(chǔ)的中間件就是一個(gè)ES用于全文檢索，一個(gè)MQ用于解耦和多播任務(wù)。

所有的業(yè)務(wù)邏輯在同一套應(yīng)用程序中，便于單元測(cè)試和集成測(cè)試；

部署簡(jiǎn)單，一臺(tái)服務(wù)器一個(gè)應(yīng)用程序，使用負(fù)載均衡應(yīng)對(duì)高并發(fā)；
由于業(yè)務(wù)邏輯都在同一個(gè)應(yīng)用程序中，服務(wù)治理可以集中做；

使用的開發(fā)人員較少；

可以實(shí)現(xiàn)顯示層（即表示層和界面層可合并-傳統(tǒng)的MVC，主要針對(duì)WEB應(yīng)用）；

傳統(tǒng)的SOA不允許暴露業(yè)務(wù)邏輯，只允許通過(guò)服務(wù)層暴露服務(wù)，這個(gè)架構(gòu)允許暴露部分業(yè)務(wù)邏輯可以獲得一些細(xì)粒度的服務(wù)，降低開發(fā)難度。

架構(gòu)缺點(diǎn):
子系統(tǒng)不具備隔離性，一個(gè)子系統(tǒng)的崩潰有可能會(huì)導(dǎo)致其他子系統(tǒng)的崩潰，只能依靠應(yīng)用程序中的服務(wù)治理手段，或在負(fù)載均衡層治理單個(gè)接口。 或采用路由分發(fā)的形式，每個(gè)部署的應(yīng)用程序包含了完整的代碼，但是因?yàn)槁酚煞职l(fā)的原因，該部署只提供了部分接口服務(wù)。

系統(tǒng)的水平擴(kuò)展不夠靈活，只有整體的水平應(yīng)用程序復(fù)制的手段，所以不適合超大的應(yīng)用系統(tǒng)。

不適合需要分庫(kù)的系統(tǒng)。

前端UI組件化依賴于前端的分別實(shí)現(xiàn)，或依賴于共同的H5頁(yè)面。

所有業(yè)務(wù)領(lǐng)域?qū)佣急仨毭嫦驅(qū)ο笤O(shè)計(jì)編程。

代碼增多容易混亂。

應(yīng)用程序會(huì)很龐大。

成熟度模型的滿足：

定制開發(fā)：滿足度高

可配置：滿足度中，通常通過(guò)配置+AOP切面編程實(shí)現(xiàn)

多租戶：滿足度低，通常只適合共享數(shù)據(jù)庫(kù)共享數(shù)據(jù)模型模式

高性能：滿足度低，調(diào)優(yōu)手段有限，只能通過(guò)多實(shí)例負(fù)載均衡、查詢優(yōu)化、編程優(yōu)化、緩存配置、路由分發(fā)的形式滿足。

伸縮性：滿足度低，多數(shù)都使用同一個(gè)數(shù)據(jù)庫(kù)，同一種緩存策略，相同的NOSQL。

技術(shù)選型建議：
PHP > JAVA > GOLANG

單線程同步編程模型下PHP與JAVA的開發(fā)時(shí)間成本幾乎一致，多線程異步方案JAVA時(shí)間成本要高一些，因?yàn)槎夹枰狣DD領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，單線程同步編程模型實(shí)現(xiàn)時(shí)間不會(huì)有多少潮劇。多線程異步模型JAVA要處理更多的鎖與內(nèi)存， 這種架構(gòu)PHP不適合使用異步多線程編程模型。

人力成本PHP低于JAVA，部署復(fù)雜度PHP低于JAVA，可復(fù)用可伸縮性JAVA高于PHP，項(xiàng)目可測(cè)試程度JAVA高于PHP。

技術(shù)方案中可能存在的不確定性：

架構(gòu)師是否能按設(shè)計(jì)目標(biāo)完成建模與分層分配；

開發(fā)組成員的素質(zhì)是否能支撐領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)和單元測(cè)試；
總結(jié)說(shuō)明：
簡(jiǎn)單易懂，開發(fā)快，人力成本低。滿足業(yè)務(wù)需求，且可遷移。但是，調(diào)優(yōu)手段有限，在系統(tǒng)的復(fù)雜度上（并發(fā)性應(yīng)該足以支撐）升到一定程度后，需要更換到分布式SOA以及微服務(wù)（通常在A B輪融資后）。

方式二：SOA架構(gòu)(分布式)

架構(gòu)特征：
松散耦合，方案一僅提供了邏輯層面的松散耦合，SOA在此基礎(chǔ)之上還提供了物理層面的松散耦合。

暴露API，企業(yè)外部也可以調(diào)用，方案一同樣提供該特性，但是方案一的暴露API的方式比較統(tǒng)一死板，SOA可以根據(jù)需要對(duì)不同服務(wù)使用不同的API暴露方案。

可重用的服務(wù)和可重組服務(wù)（方案一僅在邏輯層面重用和重組，物理層面欠缺）；

標(biāo)準(zhǔn)化的服務(wù)接口；

精確定義的服務(wù)契約；

架構(gòu)優(yōu)點(diǎn)：
有根本的獨(dú)立性和平臺(tái)中性，每個(gè)服務(wù)都可以與平臺(tái)和語(yǔ)言無(wú)關(guān)，這是方案一不具備的。

重復(fù)使用性和服務(wù)的獨(dú)立性，方案一也具備重復(fù)使用性，但是其中的服務(wù)會(huì)于應(yīng)用框架產(chǎn)生耦合，不具備獨(dú)立性。

擴(kuò)展性，方案一也具備可擴(kuò)展性，但其擴(kuò)展性會(huì)受到平臺(tái)、語(yǔ)言以及應(yīng)用框架的限制。

共享的業(yè)務(wù)服務(wù)，方案一同樣具備。

可定制業(yè)務(wù)流程，這通常在企業(yè)商務(wù)服務(wù)中很有用；
6.有版本治理，這是相當(dāng)于方案一最重要的一個(gè)優(yōu)點(diǎn)，方案一很難實(shí)現(xiàn)多個(gè)版本的服務(wù)共存，除非將版本治理加入命名空間。

架構(gòu)缺點(diǎn)：

只討論相對(duì)于方案1的缺點(diǎn)

需要更多的中間件，增加開發(fā)難度。

架構(gòu)設(shè)計(jì)需要更多的精力。

成熟度模型的滿足：

定制開發(fā)：滿足度高

可配置：滿足度高，配置、AOP切面編程以及流程控制服務(wù)；

多租戶：滿足度中，共享數(shù)據(jù)庫(kù)獨(dú)立數(shù)據(jù)模型模式、共享數(shù)據(jù)庫(kù)共享數(shù)據(jù)模型模式。

高性能：滿足度中，多實(shí)例負(fù)載均衡、查詢優(yōu)化、編程優(yōu)化、多進(jìn)程、多線程、異步、非阻塞IO的形式滿足，

伸縮性：滿足度中，多數(shù)都使用同一個(gè)數(shù)據(jù)庫(kù)，同一種緩存策略，相同的NOSQL。但是因?yàn)槭欠植际椒?wù)，其伸縮性要比方案1要高。

技術(shù)選型建議：

JAVA > PHP > GOLANG

如果需要在可復(fù)用、易伸縮、高穩(wěn)定、低延遲等企業(yè)級(jí)開發(fā)目標(biāo)上得到滿足，那么最好選擇JAVA技術(shù)路線，此外JAVA SOA架構(gòu)技術(shù)成熟度高。

如果追求開發(fā)效率，則使用PHP。PHP SOA架構(gòu)通常不使用EJB，且服務(wù)調(diào)用一般使用簡(jiǎn)單Json RPC, gRpc, hprose等簡(jiǎn)單的rpc服務(wù)，服務(wù)注冊(cè)發(fā)現(xiàn)即可以使用客戶端注冊(cè)發(fā)現(xiàn)也可以使用中間件，服務(wù)治理通常在服務(wù)端完成，分布式一致性事務(wù)往往采用最簡(jiǎn)單的MQ隊(duì)列補(bǔ)償保證最終一致性，編程模型通常都是多進(jìn)程、單線程，較為簡(jiǎn)單，但這些都是以犧牲一定性能換取的簡(jiǎn)單。

如果追求兩者平衡，可以使用混合開發(fā)，JAVA僅做關(guān)鍵核心業(yè)務(wù)應(yīng)用服務(wù)，PHP可開發(fā)業(yè)務(wù)規(guī)則和業(yè)務(wù)流程的組織。

人力成本上JAVA高于PHP， JAVA需要更多的架構(gòu)，更多的懂中間件的開發(fā)者。項(xiàng)目可測(cè)試度JAVA依然高于PHP。

技術(shù)方案中可能存在的不確定性：

架構(gòu)師是否能按設(shè)計(jì)目標(biāo)完成建模、分層分配與子系統(tǒng)劃分；

開發(fā)組成員的素質(zhì)是否能支撐領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)和單元測(cè)試；

開發(fā)組成員是否有足夠分布式架構(gòu)編程知識(shí)；

開發(fā)組成員是否有足夠的中間件即其它與分布式有關(guān)的知識(shí)，EJB/ZOOKKEEPER/Tcc/Saga/Mq等

總結(jié)說(shuō)明：

增加的設(shè)計(jì)與開發(fā)成本可以一定提升SAAS的性能和伸縮性，并將服務(wù)從邏輯層面和物理層面全部解耦。

方式三：微服務(wù)（分布式）
微服務(wù)可以看做一種特殊的SOA架構(gòu)， 它和SOA相比，它去掉了EJB，并且提供更細(xì)的服務(wù)粒度。

微服務(wù)通常有兩種架構(gòu)形式，第一種客戶端直聯(lián)，第二種是通過(guò)API接口網(wǎng)關(guān)模式，對(duì)于SAAS而言，第一種可以直接放棄了?？匆幌碌诙N架構(gòu)圖（網(wǎng)上找的，實(shí)在懶得畫了）：

架構(gòu)特征：

服務(wù)組件化；

按業(yè)務(wù)組織團(tuán)隊(duì)；

做”產(chǎn)品“的態(tài)度；

智能端點(diǎn)與啞管道（服務(wù)調(diào)用方式，實(shí)時(shí)，異步中間件）

去中心化治理（組件能針對(duì)不同的業(yè)務(wù)特點(diǎn)選擇不同的技術(shù)平臺(tái)）

去中心化管理數(shù)據(jù)（多個(gè)不同的MySql實(shí)例，各服務(wù)之間進(jìn)行“無(wú)事務(wù)”的調(diào)用，數(shù)據(jù)一致性，只要求數(shù)據(jù)在最后的處理狀態(tài)是一致的即可。補(bǔ)償機(jī)制）

基礎(chǔ)設(shè)施自動(dòng)化（自動(dòng)化測(cè)試、自動(dòng)化部署）

容錯(cuò)設(shè)計(jì)（快速檢測(cè)出故障資源并盡可能地自動(dòng)回復(fù)服務(wù)是必須被設(shè)計(jì)和考慮的）

演進(jìn)式設(shè)計(jì)

架構(gòu)優(yōu)點(diǎn)：

容器化獨(dú)立部署、擴(kuò)展性強(qiáng)；

服務(wù)簡(jiǎn)單，只關(guān)注一個(gè)業(yè)務(wù)功能；

服務(wù)自冾，可以直接被外部或其他服務(wù)調(diào)用，不像SOA需要更高層的業(yè)務(wù)邏輯組織；

每個(gè)服務(wù)可以由不同的團(tuán)隊(duì)開發(fā)，并且可以使用不同的平臺(tái)和語(yǔ)言；

松耦合；

架構(gòu)缺點(diǎn)：

較高的運(yùn)維開銷；

較高的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)和DEVOPS要求；

并行的團(tuán)隊(duì)開發(fā)可能會(huì)產(chǎn)生重復(fù)性勞動(dòng)；

需要解決分布式系統(tǒng)的復(fù)雜性；

跨進(jìn)程之間的事務(wù)、大量的異步處理、多個(gè)微服務(wù)之間的整體測(cè)試都需要有一整套的解決方案；

成熟度模型的滿足：

定制開發(fā)：滿足度高

可配置：滿足度高，配置、AOP切面編程以及流程控制服務(wù)；

多租戶：滿足度高，共享數(shù)據(jù)庫(kù)獨(dú)立數(shù)據(jù)模型模式、共享數(shù)據(jù)庫(kù)共享數(shù)據(jù)模型模式、獨(dú)立數(shù)據(jù)庫(kù)模式。

高性能：滿足度高，多實(shí)例負(fù)載均衡、查詢優(yōu)化、編程優(yōu)化、多進(jìn)程、多線程、異步、非阻塞IO、容器化的形式滿足，

伸縮性：滿足度高，數(shù)據(jù)庫(kù)拆分，獨(dú)立部署的服務(wù)，熱部署。

技術(shù)選型建議：
JAVA > GOLANG > PHP

JAVA的技術(shù)成熟度最高，可選中間件最多。

GOLANG適合從單體到微服務(wù)的遷移，不適合從零開始；

PHP社區(qū)的微服務(wù)只在摸索之中，教育系統(tǒng)常用， 可選中間件較少；

開發(fā)成本GOLANG > JAVA > PHP， GOLANG是因?yàn)殚_源社區(qū)不夠成熟，從業(yè)人員較少。PHP只在能招聘到技術(shù)專家的前提下開發(fā)成本較低。

總結(jié)說(shuō)明：
微服務(wù)可能是最能滿足SAAS4個(gè)成熟度模型的架構(gòu)模式，但是它對(duì)團(tuán)隊(duì)和開發(fā)人員的素質(zhì)要求較高。

當(dāng)前架構(gòu)選型二分檢索表
簡(jiǎn)單設(shè)計(jì)了一個(gè)選擇初始架構(gòu)方案的檢索表，因?yàn)槊總€(gè)架構(gòu)方案都能滿足可配置多租戶的需求，只是對(duì)高性能和伸縮性的支持不同，所以當(dāng)然從“不差錢”開始作為第一選項(xiàng)：

1、創(chuàng)業(yè)階段，投入資金有限（<4個(gè)高程），接受架構(gòu)緩慢遷移...................2

1、一般土豪，資金不是問(wèn)題（>=4個(gè)人高程），需要更多的為未來(lái)考慮............4

2、未來(lái)1-2年之內(nèi)預(yù)設(shè)的直接用戶并不多，不超過(guò)50萬(wàn)..........................A

2、未來(lái)1-2年之內(nèi)預(yù)設(shè)的直接用戶非常多，遠(yuǎn)高于50萬(wàn)..........................3

3、未來(lái)的業(yè)務(wù)上升曲線異常陡峭，不會(huì)有太多架構(gòu)遷移時(shí)間.....................B

3、未來(lái)的業(yè)務(wù)不會(huì)比現(xiàn)在復(fù)雜太多，或上升平緩，階段性有足夠時(shí)間遷移.........C

4、未來(lái)的業(yè)務(wù)異常復(fù)雜，需要高度的性能和伸縮性.............................D

4、未來(lái)的業(yè)務(wù)并不復(fù)雜，伸縮性和性能可滿足.................................E

A.PHP分層可遷移架構(gòu)（單體， 如果出于培養(yǎng)團(tuán)隊(duì)需要可直接上JAVA）；

B.PHP微服務(wù)架構(gòu)（分布式）；

C.PHP SOA架構(gòu)（分布式）；

D.JAVA微服務(wù)架構(gòu)（分布式）；

E.JAVA SOA架構(gòu)（分布式）；

選擇的是初始的架構(gòu)模式，階段性架構(gòu)遷移需要根據(jù)以后的情況選擇，當(dāng)然，一種技術(shù)路線切換到另一種，即使架構(gòu)模式已經(jīng)為未來(lái)留出足夠遷移準(zhǔn)備，事實(shí)上在人力和時(shí)間上依然是一個(gè)高成本高投入的過(guò)程，這點(diǎn)也是要考慮的。

PHP和JAVA的混合模式一般只適合從PHP平臺(tái)遷移至JAVA平臺(tái)的團(tuán)隊(duì)，混合開發(fā)模式不會(huì)減少JAVA需要的分工人員，只是能幫助JAVA減少一些業(yè)務(wù)邏輯表示的工作量。