一、面向服務(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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。