微服务理论之五:微服务架构 vs. SOA架构
一、面向服務(wù)的架構(gòu)SOA
面向服務(wù)的架構(gòu)是一種軟件體系結(jié)構(gòu),應(yīng)用程序的不同組件通過網(wǎng)絡(luò)上的通信協(xié)議向其他組件提供服務(wù)。通信可以是簡單的數(shù)據(jù)傳遞,也可以是兩個或多個服務(wù)彼此協(xié)調(diào)連接。這些獨特的服務(wù)執(zhí)行一些小功能,例如驗證付款、創(chuàng)建用戶帳戶或提供社交登錄等。
面向服務(wù)的架構(gòu)不太關(guān)于如何對應(yīng)用程序進行模塊化構(gòu)建,更多的是關(guān)于如何通過分布式、單獨維護和部署的軟件組件的集成來組成應(yīng)用程序。這些通過技術(shù)和標(biāo)準(zhǔn)來實現(xiàn),通過技術(shù)和標(biāo)準(zhǔn)使得組件能夠更容易地通過網(wǎng)絡(luò)(尤其是IP網(wǎng)絡(luò))進行通信和協(xié)作。
SOA架構(gòu)中有兩個主要角色:服務(wù)提供者(Provider)和服務(wù)使用者(Consumer)。而軟件代理則可以扮演這兩個角色。該Consumer層是用戶(人、應(yīng)用程序或第三方的其它組件)與SOA交互的點,和Provider層則由SOA架構(gòu)內(nèi)的所有服務(wù)所構(gòu)成。
SOA首先在90年代中期得名,當(dāng)時一家名為Gartner Group的公司認識到了這個軟件架構(gòu)的新趨勢,并在全球推廣。通過這樣做,他們設(shè)法大大加快了這種架構(gòu)模式的采用和進一步發(fā)展。然而,使用分布式服務(wù)作為軟件體系結(jié)構(gòu)的最早記錄可追溯到二十世紀80年代初。
二、微服務(wù)架構(gòu)
微服務(wù)架構(gòu)在某種程度上是面向服務(wù)的架構(gòu)SOA繼續(xù)發(fā)展的下一步。基本上,這種架構(gòu)類型是開發(fā)軟件,網(wǎng)絡(luò)或移動應(yīng)用程序作為獨立服務(wù)套件(又稱微服務(wù))的一種特殊方式。這些服務(wù)的創(chuàng)建僅限于一個特定的業(yè)務(wù)功能,如用戶管理、用戶角色、電子商務(wù)車、搜索引擎、社交媒體登錄等。此外,它們是完全獨立的,也就是說它們可以寫入不同的編程語言并使用不同的數(shù)據(jù)庫。集中式服務(wù)管理幾乎不存在,微服務(wù)使用輕量級HTTP、REST或Thrift API進行通信。
這個詞本身起源于2011年5月在威尼斯附近舉行的軟件架構(gòu)師研討會。他們第一次使用“微服務(wù)”這個術(shù)語來描述參與者看到的一個共同的架構(gòu)風(fēng)格,其中許多參會者都在探索相似的內(nèi)容。2012年5月,同一個團隊決定將“微服務(wù)”作為最合適的名稱。然而實際上,微軟、亞馬遜、Netflix和Facebook等主要的科技公司已經(jīng)在微服務(wù)架構(gòu)方面工作了十多年。
乍一看,微服務(wù)架構(gòu)似乎談?wù)摰氖桥cSOA相同的事情。不過,如果引用微軟服務(wù)領(lǐng)域的先驅(qū)Martin Flower的話,他曾經(jīng)說過,“我們應(yīng)該把SOA看作微服務(wù)的超集”。
微服務(wù)中的這個“微”字給很多人帶來了很多誤解。從字面意思上,“微”會讓人聯(lián)想到一個微服務(wù)就應(yīng)該是功能足夠單一,甚至出現(xiàn)一個服務(wù)的實現(xiàn)可能只需要幾十或者上百行代碼的說法,這應(yīng)該是最誤導(dǎo)人的觀點。從技術(shù)角度出發(fā),確實可以通過簡短的代碼實現(xiàn)功能單一的服務(wù),但從一個整體架構(gòu)考慮,如果是以這樣的方式實現(xiàn)各個微服務(wù),則在整個服務(wù)體系范疇當(dāng)中包含太多功能邊界,那么對于服務(wù)運營的分工和邊界就很難界定,給服務(wù)接下來的持續(xù)運營和維護帶來困擾;另外拆分過于細化的服務(wù),勢必將帶來大量無謂的分布式事務(wù)調(diào)用,給業(yè)務(wù)帶來額外的工作量和風(fēng)險。
正因為有了“微服務(wù)”中所謂“微”服務(wù)的說法,那如何對這些微服務(wù)進行快速的部署、發(fā)布,更高效的利用服務(wù)計算資源。(Docker本身提供的核心能力還是在技術(shù)資源層面),還有一系列問題,遠不是單單的Docker平臺能解決的問題:
微服務(wù)化的應(yīng)用架構(gòu)如何進行有效的服務(wù)管控。
在分布式服務(wù)體系下,服務(wù)鏈路跟蹤、鏈路分析、實時業(yè)務(wù)指標(biāo)的監(jiān)控等問題,也都是事先微服務(wù)架構(gòu)時一定會面臨的問題,擴大到更大范圍就是整體服務(wù)平臺的管控能力。
分布式事務(wù)難題
服務(wù)化后的應(yīng)用如何解決隨之而來的分布式事務(wù)問題,一定需要針對業(yè)務(wù)的需求在事務(wù)一致性和性能間做好平衡,一套穩(wěn)定、成熟的分布式事務(wù)解決方案也是構(gòu)建微服務(wù)架構(gòu)首先要思考好的技術(shù)方向問題。
自動化運維和平臺穩(wěn)定性。
微服務(wù)架構(gòu)相比之前獨立應(yīng)用的部署方式,從服務(wù)器的數(shù)量以及服務(wù)交互復(fù)雜程度都上升到一個新的等級,原有運維平臺和工具是否能高效支撐微服務(wù)架構(gòu)的運維也需要好好斟酌。
微服務(wù)帶來了服務(wù)間錯綜復(fù)雜的調(diào)用關(guān)系,如何能在大促、秒殺、機器故障時,這些服務(wù)都能穩(wěn)定提供服務(wù)?這對于整個平臺的高可用性和穩(wěn)定性提出了非常高的要求:
1、微服務(wù)的服務(wù)設(shè)計:
微服務(wù)中服務(wù)邊界的劃分一定是從業(yè)務(wù)的維度,以什么樣的服務(wù)顆粒度定義服務(wù)?什么樣的數(shù)據(jù)模型支撐服務(wù)能力的線性擴展?如何保持設(shè)計出的服務(wù)具有很好的業(yè)務(wù)前瞻性?在高效滿足現(xiàn)有業(yè)務(wù)需求的前提下,還能保持整個服務(wù)能力的通用性,為接下來其他業(yè)務(wù)的服務(wù)接入提供業(yè)務(wù)的擴展能力?這些問題都是微服務(wù)架構(gòu)在落地過程中,實施團隊都將面臨的問題。
2、原有組織架構(gòu)是否滿足微服務(wù)架構(gòu)持續(xù)發(fā)展的需要:
服務(wù)強調(diào)持續(xù)的演變,需要組建對應(yīng)的組織或者對現(xiàn)有的組織架構(gòu)進行調(diào)整,圍繞以服務(wù)為中心的持續(xù)運營,這對應(yīng)很多企業(yè)原有的信息中心架構(gòu)是一個不大的沖擊和改變。
那么,差異在哪里呢?可以說,兩種架構(gòu)比起不同的架構(gòu)有更多的相似之處,然而,它們是兩種不同類型的架構(gòu)。下面會詳細分析這一點。
三、SOA特點、微服務(wù)特性特點
SOA的主要特性:
IBM對SOA的定義:SOA是一種構(gòu)造分布式系統(tǒng)的方法,它將業(yè)務(wù)應(yīng)用功能以服務(wù)的形式提供給最終用戶應(yīng)用或其他服務(wù)。
面向服務(wù)的分布式計算
服務(wù)間松散耦合
支持服務(wù)的組裝
服務(wù)的注冊和自動發(fā)現(xiàn)
以服務(wù)契約方式定義服務(wù)交互方式
“中心化”的SOA服務(wù)架構(gòu),即傳統(tǒng)軟件廠商提出的以ESB(企業(yè)服務(wù)總線)實現(xiàn)SOA的方案;還有一種是“去中心化”的服務(wù)架構(gòu)。
微服務(wù)的主要特性:
定義:圍繞業(yè)務(wù)領(lǐng)域組件來創(chuàng)建應(yīng)用,這些應(yīng)用可獨立地進行開發(fā)、管理和迭代。在分散的組件中使用云架構(gòu)和平臺式部署、管理和服務(wù)功能,使產(chǎn)品交付變得更加簡單。
以下是Martin Fowler對于微服務(wù)架構(gòu)的典型特征的描述:
分布式服務(wù)組成的系統(tǒng)。
按照業(yè)務(wù)而不是技術(shù)來劃分組織。
做有生命的產(chǎn)品而不是項目
智能化服務(wù)端點與傻瓜式服務(wù)編排。
自動化運維。
系統(tǒng)容錯。
基礎(chǔ)設(shè)施自動化
服務(wù)快速演化。
去中心化的治理技術(shù)。
去中心化的管理數(shù)據(jù)。
從本質(zhì)上來說,“微服務(wù)”是SOA的一種演變后的形態(tài),與SOA的方法和原理沒有本質(zhì)上的區(qū)別。將傳統(tǒng)SOA與微服務(wù)典型特征做一個對比解讀,會發(fā)現(xiàn)鮮明差異:(67頁)
四、SOA vs. MicroServices
SOA簡單理解為應(yīng)用的垂直拆分,微服務(wù)理解為應(yīng)用的垂直拆分+水平拆分,是SOA的演進。提高了靈活性,但是需要額外考慮分布式鎖、分布式事務(wù)等問題。
下面進一步解釋上表所述的不同之處:
開發(fā)方面 - 在這兩種體系結(jié)構(gòu)中,可以使用不同的編程語言和工具開發(fā)服務(wù),從而將技術(shù)多樣性帶入開發(fā)團隊。開發(fā)可以在多個團隊中組織,但是在SOA中,每個團隊都需要了解常見的通信機制。另一方面,使用微服務(wù),服務(wù)可以獨立于其他服務(wù)運行和部署。因此,頻繁部署新版本的微服務(wù)或獨立擴展服務(wù)會更容易。您可以在這里進一步閱讀有關(guān)微服務(wù)的這些好處。
“上下文邊界” - SOA鼓勵組件的共享,而微服務(wù)嘗試通過“上下文邊界”來最小化共享。上下文邊界是指以最小的依賴關(guān)系將組件及其數(shù)據(jù)耦合為單個單元。由于SOA依靠多個服務(wù)來完成業(yè)務(wù)請求,構(gòu)建在SOA上的系統(tǒng)可能比微服務(wù)要慢。
通信 - 在SOA中,ESB可能成為影響整個系統(tǒng)的單一故障點。由于每個服務(wù)都通過ESB進行通信,如果其中一個服務(wù)變慢,可能會阻塞ESB并請求該服務(wù)。另一方面,微服務(wù)在容錯方面要好得多。例如,如果一個微服務(wù)存在內(nèi)存錯誤,那么只有該微服務(wù)會受到影響。所有其他微服務(wù)將繼續(xù)定期處理請求。
互操作性 - SOA通過消息中間件組件促進了多種異構(gòu)協(xié)議的使用。微服務(wù)試圖通過減少集成選擇的數(shù)量來簡化架構(gòu)模式。因此,如果您想要在異構(gòu)環(huán)境中使用不同協(xié)議來集成多個系統(tǒng),則需要考慮SOA。如果您的所有服務(wù)都可以通過相同的遠程訪問協(xié)議訪問,那么微服務(wù)對您來說是一個更好的選擇。
大小Size - 最后一點但并非最不重要的一點,SOA和微服務(wù)的主要區(qū)別在于規(guī)模和范圍。微服務(wù)架構(gòu)中的前綴“微”是指內(nèi)部組件的粒度,意味著它們必須比SOA架構(gòu)的服務(wù)往往要小得多。微服務(wù)中的服務(wù)組件通常有一個單一的目的,他們做得很好。另一方面,在SOA服務(wù)中通??常包含更多的業(yè)務(wù)功能,并且通常將它們實現(xiàn)為完整的子系統(tǒng)。
五、結(jié)論
我們不能簡單地說一種架構(gòu)比另一種架構(gòu)更好。這主要取決于您正在構(gòu)建的應(yīng)用程序的目的。SOA更適合需要與許多其他應(yīng)用程序集成的大型復(fù)雜企業(yè)應(yīng)用程序環(huán)境。這就是說,小型應(yīng)用程序不適合SOA架構(gòu),因為它們不需要消息中間件組件。而微服務(wù)架構(gòu),在另一方面,是更適合于較小和良好的分割,基于Web的系統(tǒng)。另外,如果您正在開發(fā)移動或Web應(yīng)用程序,那么微服務(wù)作為開發(fā)人員可以為您提供更大的控制權(quán)。最后,我們可以得出結(jié)論,因為它們服務(wù)于不同的目的,微服務(wù)和SOA確實是不同類型的體系結(jié)構(gòu)。
總結(jié)
以上是生活随笔為你收集整理的微服务理论之五:微服务架构 vs. SOA架构的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: php数组变量太大后台返回500,PHP
- 下一篇: 【转】不同内核浏览器的差异以及浏览器渲染