微服務(wù)中如何正確實(shí)施的SOA

這篇文章將為大家詳細(xì)講解有關(guān)微服務(wù)中如何正確實(shí)施的SOA，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個(gè)參考，希望大家閱讀完這篇文章后對(duì)相關(guān)知識(shí)有一定的了解。

對(duì)于組織來說，能夠構(gòu)建、發(fā)展和擴(kuò)展大型應(yīng)用程序是至關(guān)重要的, 但所涉及的挑戰(zhàn)使其成為一項(xiàng)艱巨的任務(wù)。正因?yàn)槿绱? 微服務(wù)憑借能夠?qū)蝹€(gè)組件拆分成圍繞特定業(yè)務(wù)功能的獨(dú)立服務(wù)，已成為構(gòu)建現(xiàn)代云應(yīng)用程序的主要模式。

微服務(wù)架構(gòu)是一種分布式系統(tǒng)的方法，它可以促進(jìn)使用具有自身生命周期的細(xì)粒度服務(wù)。由于微服務(wù)主要是圍繞單個(gè)業(yè)務(wù)流程/功能而建模的，所以它們避免了傳統(tǒng)分層 (多層/n 層)體系結(jié)構(gòu)(如單體應(yīng)用) 的問題。微服務(wù)同時(shí)還集成了過去十年出現(xiàn)的技術(shù)和新興技術(shù)，因此避免了許多面向服務(wù)體系結(jié)構(gòu)實(shí)現(xiàn)的缺點(diǎn)。

雖然使用微服務(wù)在使大型應(yīng)用程序更易于管理方面有諸多好處，但是在任何情況下，構(gòu)建一個(gè)可靠的分布式系統(tǒng)都是非常具有挑戰(zhàn)性的，因?yàn)樵谔幚砉收?、一致性和性能等方面有很多需要考慮的因素。

下面詳細(xì)介紹了微服務(wù)架構(gòu)的實(shí)現(xiàn)路徑，并分析了該模式的優(yōu)缺點(diǎn)。同時(shí)討論了幫助開發(fā)人員和應(yīng)用架構(gòu)師，實(shí)現(xiàn)其應(yīng)用程序目標(biāo)的最優(yōu)方法。

關(guān)于域

SOA：面向服務(wù)的架構(gòu)

面向服務(wù)的體系架構(gòu)SOA是一種可根據(jù)需求通過網(wǎng)絡(luò)對(duì)松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用的方法。每個(gè)服務(wù)都將實(shí)現(xiàn)預(yù)定義的業(yè)務(wù)目標(biāo)，并執(zhí)行分離的工作單元。這些服務(wù)是獨(dú)立的，不依賴于其它服務(wù)的上下文或狀態(tài)。它們?cè)诜植际较到y(tǒng)體系結(jié)構(gòu)中工作。

在某些方面，SOA架構(gòu)是分布式技術(shù)（COM和CORBA）的進(jìn)化。與這些類似，SOA強(qiáng)調(diào)服務(wù)與消費(fèi)者（WSDL）以及特定服務(wù)發(fā)現(xiàn)（UDDI）、傳輸（SOAP）、中介（WS-mediation）、路由（WS-尋址）、安全（WS-security、WS-trust、WS- secure conversation等）和分布式計(jì)算的其他方面之間的嚴(yán)格契約。此外，SOA通過企業(yè)存儲(chǔ)庫(kù)、服務(wù)生命周期管理和服務(wù)級(jí)別監(jiān)控工具，強(qiáng)調(diào)對(duì)服務(wù)的設(shè)計(jì)、開發(fā)和運(yùn)營(yíng)治理

1 Introduction

微服務(wù)是一種體系結(jié)構(gòu)風(fēng)格。它是一種將單個(gè)應(yīng)用程序開發(fā)為一組小型服務(wù)的方法，每個(gè)服務(wù)都運(yùn)行自己的流程，并與輕量級(jí)機(jī)制通信，通常是 HTTP API。這些服務(wù)是圍繞業(yè)務(wù)功能構(gòu)建的，可以獨(dú)立部署。

微服務(wù)模式有著顯著的好處，特別是在支持復(fù)雜企業(yè)應(yīng)用程序的敏捷開發(fā)和交付方面。

微服務(wù)體系結(jié)構(gòu)模式將應(yīng)用程序分解為可管理的塊，從而實(shí)現(xiàn)執(zhí)行模塊級(jí)別，而在實(shí)踐中，通過單一代碼庫(kù)實(shí)現(xiàn)模塊級(jí)別是極其困難的。因此，單個(gè)服務(wù)的開發(fā)速度更快，也更容易理解和維護(hù)。

另外，這種方法更傾向于輕量級(jí)消息總線。簡(jiǎn)單來說，基于微服務(wù)構(gòu)建的應(yīng)用程序，其目的是盡可能地做到解耦和聚合。它們擁有自己的單個(gè)域邏輯，并更多地充當(dāng)過濾器——接收請(qǐng)求，根據(jù)需要適當(dāng)?shù)貞?yīng)用邏輯，并產(chǎn)生響應(yīng)。

微服務(wù)體系結(jié)構(gòu)的本質(zhì)并不新鮮，分布式系統(tǒng)的概念由來已久。微服務(wù)體系結(jié)構(gòu)也類似于SOA。微服務(wù)背后的理念是構(gòu)建大型的、復(fù)雜的、長(zhǎng)期存在的應(yīng)用程序，即隨著時(shí)間的推移，而演進(jìn)成一套統(tǒng)一的（有組織的或相互連接的）服務(wù)?！拔⒎?wù)”這一術(shù)語強(qiáng)烈表明了服務(wù)應(yīng)該是小型的。

然而，盡管擁有小型服務(wù)是可取的，但這不應(yīng)該是主要目標(biāo)。相反，你的目標(biāo)應(yīng)該在于將系統(tǒng)分解為服務(wù)，以解決開發(fā)和部署的問題。有些服務(wù)可能確實(shí)很小，而另一些可能相當(dāng)大。

應(yīng)用程序的發(fā)展演變

單層應(yīng)用程序

在早期發(fā)展進(jìn)程中，應(yīng)用程序作為一個(gè)單一實(shí)體開發(fā)部署。這些單層應(yīng)用程序易于部署，因?yàn)樗鼈冎挥幸粋€(gè)代碼基和部署配置。

可伸縮性對(duì)于這種應(yīng)用程序來說，是一個(gè)巨大的挑戰(zhàn)，因?yàn)樗荒芡ㄟ^復(fù)制整個(gè)應(yīng)用程序來實(shí)現(xiàn)。這將直接增加企業(yè)的成本，并隨著流量和負(fù)載的增加而造成資源浪費(fèi)。

多層 (或 n 層)

單層/整體應(yīng)用的缺點(diǎn)導(dǎo)致了多層體系結(jié)構(gòu)的產(chǎn)生。這種新體系結(jié)構(gòu)將應(yīng)用程序分解為邏輯分布式層，從而實(shí)現(xiàn)了高效的可伸縮性。這種方法通常將表示層、數(shù)據(jù)層和業(yè)務(wù)邏輯層分離。所以，擴(kuò)展方法單獨(dú)應(yīng)用于這些層，而不是應(yīng)用于整個(gè)應(yīng)用。

但是，當(dāng)使用該模式構(gòu)建的應(yīng)用程序增長(zhǎng)時(shí)，它會(huì)在業(yè)務(wù)邏輯層上產(chǎn)生應(yīng)變，并引出單體架構(gòu)的許多缺點(diǎn)。同樣，作為一個(gè)單一實(shí)體，可伸縮性是具有挑戰(zhàn)性的，成本也是高昂的。

面向服務(wù)的體系結(jié)構(gòu) (SOA)

SOA發(fā)展演變過程中，其理念是實(shí)現(xiàn)將應(yīng)用程序視為業(yè)務(wù)功能的愿景。

隨著越來越多的企業(yè)走向自動(dòng)化/數(shù)字化，IT因服務(wù)于快速變化的業(yè)務(wù)需求，已然發(fā)展為業(yè)務(wù)的支柱。這些快速變化的業(yè)務(wù)需求，使得開發(fā)人員開始將他們的應(yīng)用設(shè)想為業(yè)務(wù)功能的集合，因此與組件在堆棧中的位置相比，隔離組件更符合他們的用途。例如，開發(fā)人員可以創(chuàng)建一個(gè)用來處理用戶身份驗(yàn)證、計(jì)費(fèi)訂單服務(wù)或處電子郵件發(fā)送通知的用戶服務(wù)，因?yàn)槊總€(gè)服務(wù)都更小、更集中，這樣可以提供更有效的可伸縮性。

雖然這種模式為構(gòu)建有效的應(yīng)用程序體系結(jié)構(gòu)提供了框架，但由于不必要的復(fù)雜抽象和遺留協(xié)議，它的實(shí)踐通常是無效的。開發(fā)人員將嘗試使用 SOA 來連接范圍廣泛的應(yīng)用程序，它們都采用不同的語言，需要為企業(yè)服務(wù)總線提供額外的層。這導(dǎo)致了過時(shí)、昂貴的配置，無法跟上技術(shù)和商業(yè)環(huán)境的發(fā)展。

2 Microservices——Artefacts

為什么是微服務(wù)——新模式？

IT的發(fā)展已經(jīng)極大地改變了全球商業(yè)的前景。在早期，IT被認(rèn)為是商業(yè)/組織的援助之手，用于減少業(yè)務(wù)功能/單元的手工工作。

如今，IT正被用來改造業(yè)務(wù), 產(chǎn)生更多的收入。所以，現(xiàn)在IT不僅僅是一個(gè)支持功能，而是主要的業(yè)務(wù)功能。

Gartner 在其2015的10大戰(zhàn)略技術(shù)趨勢(shì)中表示：“為了迅速地應(yīng)對(duì)數(shù)字業(yè)務(wù)和規(guī)模系統(tǒng)的快速變化需求，計(jì)算必須從靜態(tài)模式轉(zhuǎn)向動(dòng)態(tài)模式。規(guī)則、模式和代碼可以通過應(yīng)用程序動(dòng)態(tài)地組裝，以及配置網(wǎng)絡(luò)所需的所有元素。”

這種在應(yīng)用體系結(jié)構(gòu)中思維的轉(zhuǎn)變，也帶來了實(shí)踐上的轉(zhuǎn)變。Gartner 的進(jìn)一步預(yù)測(cè)表明，“對(duì)于許多組織來說，面向 Web-Scale IT 未來邁出的第一步應(yīng)該是 DevOps ——以協(xié)調(diào)的方式將開發(fā)和運(yùn)維結(jié)合在一起，以推動(dòng)應(yīng)用服務(wù)的快速、持續(xù)的增量開發(fā)?！?/p>

使用 Web-Scale IT 企業(yè)可以更輕松地構(gòu)建類似于 Amazon、Google 和 Facebook 提供的應(yīng)用程序和基礎(chǔ)架構(gòu)。Web-Scale IT 能夠使企業(yè)在其 IT 設(shè)置中，進(jìn)一步擁抱云，向內(nèi)部用戶提供大型服務(wù)提供商的能力。

從SOA分化

微服務(wù)模式在定義特性方面比 SOA 更清晰，它提供了一個(gè)滿足現(xiàn)代應(yīng)用程序體系結(jié)構(gòu)需求的框架。微服務(wù)通常被稱為：正確實(shí)施的 SOA 。

SOA 專注于獨(dú)立的技術(shù)系統(tǒng), 微服務(wù)專注于獨(dú)立的業(yè)務(wù)系統(tǒng)。

微服務(wù)模式的目標(biāo)不是將各種應(yīng)用程序連接在一起，而是創(chuàng)建一個(gè)由獨(dú)立開發(fā)、獨(dú)立部署的服務(wù)，組成的單一、聚合的應(yīng)用程序，每個(gè)服務(wù)都遵循單一職責(zé)原則。然而，“微”這個(gè)表述，對(duì)于微服務(wù)的特性來說，可能會(huì)具有一點(diǎn)兒欺騙性，因?yàn)榇笮〔⒉皇俏⒎?wù)定義的特征。雖然微服務(wù)通常很小，但更重要的是每個(gè)服務(wù)自己封裝的流程可以獨(dú)立開發(fā)和部署。開發(fā)人員通過限制一個(gè)服務(wù)可做的事情范圍，來確保這些服務(wù)不會(huì)無意中和許多解耦的單體一起結(jié)束。

與現(xiàn)代云一樣，服務(wù)之間的通信是通過基于REST的API，通過HTTP完成的，傳遞JSON數(shù)據(jù)，通常通過消息隊(duì)列來確?？煽啃?。單個(gè)微服務(wù)通常是異步處理的，由API調(diào)用、推送隊(duì)列、調(diào)度或 webhook 等事件觸發(fā)。一個(gè)圍繞通信和處理的輕量級(jí)、高效框架，進(jìn)一步將微服務(wù)與SOA區(qū)分開來。

將應(yīng)用程序分解為多個(gè)服務(wù)

這里還有一些其他的體系結(jié)構(gòu)風(fēng)格可以進(jìn)行擴(kuò)展。《可伸縮性的藝術(shù)》一書，描述了一個(gè)非常有用的三維可伸縮性模型：伸縮立方（Scale Cube），如下圖所示。

在這個(gè)模型中，通過在負(fù)載均衡器之后，運(yùn)行多份應(yīng)用副本來伸縮應(yīng)用的方式叫做X軸伸縮。這是提高應(yīng)用程序容量和可用性的一個(gè)好方法。

使用 Z 軸收縮時(shí)，每個(gè)服務(wù)器都運(yùn)行一份相同的代碼副本。在這方面，它類似于 X 軸縮放。最大的區(qū)別在于每個(gè)服務(wù)器只負(fù)責(zé)數(shù)據(jù)的一個(gè)子集。與X軸伸縮一樣，Z軸收縮可以提高應(yīng)用程序的容量和可用性。

但是，兩種方法都無法解決開發(fā)增加和應(yīng)用程序復(fù)雜性的問題。

為了解決這些問題，我們需要應(yīng)用 Y 軸伸縮。

Z 軸伸縮會(huì)拆分相似的服務(wù), Y 軸伸縮會(huì)拆分不同的服務(wù)。在應(yīng)用層，Y 軸縮放將一個(gè)整體應(yīng)用程序拆分為一組服務(wù)。

每個(gè)服務(wù)都實(shí)現(xiàn)了一系列相關(guān)功能，如訂單管理、客戶管理等。

作為一種模式，微服務(wù)通過將功能元素分解為單個(gè)服務(wù)，來提升 Y 軸的可伸縮性, 而不是通過傳統(tǒng)的復(fù)制。

理想情況下，每個(gè)服務(wù)應(yīng)該只有一小部分職責(zé)。SRP（單一責(zé)任原則）將類的責(zé)任定義為需要更改的原因，并且類應(yīng)該只有一個(gè)原因需要更改。將SRP應(yīng)用于服務(wù)設(shè)計(jì)也是有意義的。

微服務(wù)體系結(jié)構(gòu)–通信機(jī)制

在微服務(wù)架構(gòu)中，客戶端與應(yīng)用之間，以及應(yīng)用組件之間的通信模式與單體應(yīng)用不同。讓我們先來看一下應(yīng)用客戶端如何與微服務(wù)交互的問題。在此之后，我們將研究應(yīng)用程序中的通信機(jī)制。

直接調(diào)用

應(yīng)用程序客戶端 （如本機(jī)移動(dòng)應(yīng)用程序）可以對(duì)各個(gè)服務(wù)發(fā)出基于 REST 的 HTTP 請(qǐng)求，如下圖所示。

單個(gè)服務(wù)的 API

和客戶端所需的數(shù)據(jù)之間的粒度可能存在明顯的粒度不匹配。

例如，顯示一個(gè)Web頁(yè)面可能需要調(diào)用大量服務(wù)。例如，Amazon.com描述了一些頁(yè)面如何需要調(diào)用100多個(gè)服務(wù)。即使是在高速互聯(lián)網(wǎng)連接上發(fā)出如此多的請(qǐng)求，更不用說低帶寬、高延遲的移動(dòng)網(wǎng)絡(luò)了，這將非常低效，并導(dǎo)致用戶體驗(yàn)差。

API 網(wǎng)關(guān)模式

這是一種更好的方法，因?yàn)榭蛻舳藢⒃诰W(wǎng)絡(luò)上對(duì)被稱為API網(wǎng)關(guān)的前端服務(wù)器發(fā)出每個(gè)頁(yè)面的少量請(qǐng)求，可能只有一個(gè)請(qǐng)求。

API 網(wǎng)關(guān)位于應(yīng)用程序客戶端和微服務(wù)之間，它提供了針對(duì)客戶端量身定做的 API。API 網(wǎng)關(guān)為移動(dòng)客戶端提供粗粒度的API，為使用高性能網(wǎng)絡(luò)的桌面客戶端提供細(xì)粒度的 API。在此示例中, 桌面客戶端發(fā)出多個(gè)請(qǐng)求以檢索有關(guān)產(chǎn)品的信息, 而移動(dòng)客戶端則發(fā)出單個(gè)請(qǐng)求。

API 網(wǎng)關(guān)通過在高性能 LAN 上向一些微服務(wù)發(fā)出請(qǐng)求來處理傳入的請(qǐng)求。在此示例中，來自桌面客戶端的細(xì)粒度請(qǐng)求只是代理到相應(yīng)的服務(wù)，而來自移動(dòng)客戶端的每個(gè)粗粒度請(qǐng)求都通過聚合調(diào)用多個(gè)服務(wù)的結(jié)果來進(jìn)行處理的。

3 Advantages of Microservices

組件的分離為構(gòu)建和維護(hù)高度可伸縮的需求，提供了更有效的環(huán)境。獨(dú)立開發(fā)、獨(dú)立部署的較小的服務(wù)更容易維護(hù)、修復(fù)和更新，從而為響應(yīng)當(dāng)今不斷變化的環(huán)境提供更敏捷的功能。

• 模塊化

微服務(wù)以服務(wù)為單位;每個(gè)服務(wù)都有自己的邊界，你不能簡(jiǎn)單地繞過邊界，這樣你就可以獨(dú)立地開發(fā)、部署和擴(kuò)展服務(wù)。

• 特定于服務(wù)的數(shù)據(jù)庫(kù)

微服務(wù)是松散耦合的，并且擁有自己的數(shù)據(jù)庫(kù)，因此服務(wù)不會(huì)通過持有數(shù)據(jù)庫(kù)鎖來阻止其他服務(wù)。

• 故障隔離

微服務(wù)體系結(jié)構(gòu)具有更好的故障隔離;一個(gè)服務(wù)的問題不會(huì)影響其他服務(wù)，其他服務(wù)將繼續(xù)正常工作。

• 可伸縮性

在個(gè)人服務(wù)水平上的擴(kuò)展變得更具有成本效益，并隨需應(yīng)變?？梢圆l(fā)地處理單個(gè)任務(wù)，而不會(huì)影響應(yīng)用程序的其余部分。

分離應(yīng)用程序的組件使單個(gè)錯(cuò)誤或硬件故障導(dǎo)致整個(gè)系統(tǒng)癱瘓(消除單個(gè)故障點(diǎn))的可能性降低。失敗的進(jìn)程可以被隔離，并且可以退出端點(diǎn)直到到達(dá)。

• 技術(shù)/語言靈活性

每個(gè)單獨(dú)的服務(wù)都可以基于開發(fā)人員的首選項(xiàng)、任務(wù)適用性或與某個(gè)庫(kù)匹配的不同語言。

除此之外, 以下幾點(diǎn)也是微服務(wù)的主要優(yōu)勢(shì)：

• 微服務(wù)體系結(jié)構(gòu)允許開發(fā)人員自由地獨(dú)立開發(fā)和部署服務(wù)。

• 小團(tuán)隊(duì)可以開發(fā)微服務(wù)。

• 不同服務(wù)的代碼可以用不同的語言編寫。

• 易于集成和自動(dòng)部署（使用開源持續(xù)集成工具，如 Jenkins、Hudson 等）。

• 易于理解和修改的開發(fā)人員，從而可以幫助一個(gè)新的團(tuán)隊(duì)變得高效快速。

• api可以更有效地進(jìn)行版本控制，因?yàn)閱蝹€(gè)服務(wù)可以遵循自己的方案。主要版本可以在應(yīng)用程序級(jí)別執(zhí)行，而服務(wù)可以根據(jù)需要更新。

• 將應(yīng)用程序的組件分離開來，就不太可能出現(xiàn)單個(gè)錯(cuò)誤或硬件故障導(dǎo)致整個(gè)系統(tǒng)癱瘓的情況。失敗的進(jìn)程可以被隔離，并且向下的端點(diǎn)可以被退休直到到達(dá)（消除單個(gè)故障點(diǎn)）。

• 開發(fā)者可以使用最新的技術(shù)。

• 圍繞業(yè)務(wù)功能的代碼。

• 啟動(dòng)web容器更快，所以部署也更快。

• 當(dāng)應(yīng)用程序的某個(gè)部分需要更改時(shí)，只能修改和重新部署相關(guān)的服務(wù)——不需要修改和重新部署整個(gè)應(yīng)用程序。

• 更好的故障隔離：如果一個(gè)微服務(wù)失敗，另一個(gè)將繼續(xù)工作（盡管一個(gè)整體應(yīng)用程序的一個(gè)問題區(qū)域可能會(huì)危及整個(gè)系統(tǒng)）。

• 易于擴(kuò)展和與第三方服務(wù)集成。

• 沒有長(zhǎng)期致力于技術(shù)棧。

4 Drawbacks of Microservices

將應(yīng)用程序分離到獨(dú)立的服務(wù)意味著現(xiàn)在有更多的活動(dòng)組件需要維護(hù)。這也帶來了一些挑戰(zhàn)。

• 復(fù)雜的業(yè)務(wù)流程

雖然微服務(wù)的一個(gè)主要優(yōu)點(diǎn)是精簡(jiǎn)的編排功能，但更多的服務(wù)意味著要維護(hù)更多的部署流。DevOps 在這個(gè)模式中扮演著更為重要的角色，因?yàn)槊總€(gè)服務(wù)都必須在它的整個(gè)生命周期中正確地配置。

• 服務(wù)間通信

分離的服務(wù)需要一種可靠、有效的方式來進(jìn)行通信，同時(shí)又不會(huì)減慢整個(gè)應(yīng)用程序的速度。通過網(wǎng)絡(luò)交付數(shù)據(jù)會(huì)帶來延遲和潛在的故障，這會(huì)影響用戶體驗(yàn)。一種常見的方法是引入消息隊(duì)列作為可靠的傳輸層。

• 測(cè)試

雖然保持代碼和依賴關(guān)系緊密意味著為特定服務(wù)提供更簡(jiǎn)單的開發(fā)環(huán)境，但它確實(shí)帶來了與整個(gè)應(yīng)用程序相關(guān)的測(cè)試挑戰(zhàn)。服務(wù)通常需要相互通信，或者依賴于數(shù)據(jù)源或API。獨(dú)立地測(cè)試一個(gè)服務(wù)將需要一個(gè)完整的測(cè)試環(huán)境才能有效。

• 微服務(wù)體系結(jié)構(gòu)帶來了大量的操作開銷。

• 要求有 DevOps 技能。

• 分布式系統(tǒng)管理起來很復(fù)雜。

• 由于分布式部署，默認(rèn)跟蹤問題。隨著服務(wù)數(shù)量的增加，整個(gè)產(chǎn)品的管理變得越來越復(fù)雜。

5 結(jié)論

單體應(yīng)用是用于構(gòu)建企業(yè)應(yīng)用程序的常用模式。它在小型應(yīng)用程序中工作得相當(dāng)好：開發(fā)、測(cè)試和部署小型單片應(yīng)用程序相對(duì)簡(jiǎn)單。

然而，對(duì)于大型、復(fù)雜的應(yīng)用程序，單塊體系結(jié)構(gòu)成為開發(fā)和部署的障礙。持續(xù)的交付是很難做到的，并且您常常被永久地鎖定在你最初的技術(shù)選擇上。對(duì)于大型應(yīng)用程序，使用將應(yīng)用程序分解為s組服務(wù)的微服務(wù)體系結(jié)構(gòu)更有意義。

微服務(wù)體系結(jié)構(gòu)有許多優(yōu)點(diǎn)。例如，單個(gè)服務(wù)更容易理解，可以獨(dú)立于其他服務(wù)進(jìn)行開發(fā)和部署。使用新語言和框架也容易得多，因?yàn)槟憧梢砸淮螄L試一個(gè)服務(wù)的新技術(shù)。

微服務(wù)體系結(jié)構(gòu)也有一些明顯的缺陷。特別是，應(yīng)用程序要復(fù)雜得多，并且有更多的活動(dòng)部件。你需要高度自動(dòng)化，例如PaaS，才能有效地使用微服務(wù)。

在開發(fā)微服務(wù)時(shí)，還需要處理一些復(fù)雜的分布式數(shù)據(jù)管理問題。盡管存在這些缺點(diǎn)，但對(duì)于快速發(fā)展的大型復(fù)雜應(yīng)用程序（尤其是SaaS風(fēng)格的應(yīng)用程序）來說，微服務(wù)體系結(jié)構(gòu)是有意義的。

有許多策略可以漸進(jìn)地將現(xiàn)有的單體應(yīng)用程序演化為微服務(wù)體系結(jié)構(gòu)。開發(fā)人員應(yīng)該將新功能作為獨(dú)立的服務(wù)實(shí)現(xiàn)，并編寫粘合代碼將服務(wù)與單體集成。

迭代地識(shí)別組件以從整體中提取并轉(zhuǎn)換為服務(wù)也是有意義的。雖然這種改進(jìn)并不容易，但它比開發(fā)和維護(hù)一個(gè)笨重的單體應(yīng)用程序要好。

關(guān)于微服務(wù)中如何正確實(shí)施的SOA就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺得文章不錯(cuò)，可以把它分享出去讓更多的人看到。