微服務中如何正確實施的SOA

這篇文章將為大家詳細講解有關微服務中如何正確實施的SOA，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

對于組織來說，能夠構建、發展和擴展大型應用程序是至關重要的, 但所涉及的挑戰使其成為一項艱巨的任務。正因為如此, 微服務憑借能夠將單個組件拆分成圍繞特定業務功能的獨立服務，已成為構建現代云應用程序的主要模式。

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

雖然使用微服務在使大型應用程序更易于管理方面有諸多好處，但是在任何情況下，構建一個可靠的分布式系統都是非常具有挑戰性的，因為在處理故障、一致性和性能等方面有很多需要考慮的因素。

下面詳細介紹了微服務架構的實現路徑，并分析了該模式的優缺點。同時討論了幫助開發人員和應用架構師，實現其應用程序目標的最優方法。

關于域

SOA：面向服務的架構

面向服務的體系架構SOA是一種可根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用的方法。每個服務都將實現預定義的業務目標，并執行分離的工作單元。這些服務是獨立的，不依賴于其它服務的上下文或狀態。它們在分布式系統體系結構中工作。

在某些方面，SOA架構是分布式技術（COM和CORBA）的進化。與這些類似，SOA強調服務與消費者（WSDL）以及特定服務發現（UDDI）、傳輸（SOAP）、中介（WS-mediation）、路由（WS-尋址）、安全（WS-security、WS-trust、WS- secure conversation等）和分布式計算的其他方面之間的嚴格契約。此外，SOA通過企業存儲庫、服務生命周期管理和服務級別監控工具，強調對服務的設計、開發和運營治理

1 Introduction

微服務是一種體系結構風格。它是一種將單個應用程序開發為一組小型服務的方法，每個服務都運行自己的流程，并與輕量級機制通信，通常是 HTTP API。這些服務是圍繞業務功能構建的，可以獨立部署。

微服務模式有著顯著的好處，特別是在支持復雜企業應用程序的敏捷開發和交付方面。

微服務體系結構模式將應用程序分解為可管理的塊，從而實現執行模塊級別，而在實踐中，通過單一代碼庫實現模塊級別是極其困難的。因此，單個服務的開發速度更快，也更容易理解和維護。

另外，這種方法更傾向于輕量級消息總線。簡單來說，基于微服務構建的應用程序，其目的是盡可能地做到解耦和聚合。它們擁有自己的單個域邏輯，并更多地充當過濾器——接收請求，根據需要適當地應用邏輯，并產生響應。

微服務體系結構的本質并不新鮮，分布式系統的概念由來已久。微服務體系結構也類似于SOA。微服務背后的理念是構建大型的、復雜的、長期存在的應用程序，即隨著時間的推移，而演進成一套統一的（有組織的或相互連接的）服務。“微服務”這一術語強烈表明了服務應該是小型的。

然而，盡管擁有小型服務是可取的，但這不應該是主要目標。相反，你的目標應該在于將系統分解為服務，以解決開發和部署的問題。有些服務可能確實很小，而另一些可能相當大。

應用程序的發展演變

單層應用程序

在早期發展進程中，應用程序作為一個單一實體開發部署。這些單層應用程序易于部署，因為它們只有一個代碼基和部署配置。

可伸縮性對于這種應用程序來說，是一個巨大的挑戰，因為它只能通過復制整個應用程序來實現。這將直接增加企業的成本，并隨著流量和負載的增加而造成資源浪費。

多層 (或 n 層)

單層/整體應用的缺點導致了多層體系結構的產生。這種新體系結構將應用程序分解為邏輯分布式層，從而實現了高效的可伸縮性。這種方法通常將表示層、數據層和業務邏輯層分離。所以，擴展方法單獨應用于這些層，而不是應用于整個應用。

但是，當使用該模式構建的應用程序增長時，它會在業務邏輯層上產生應變，并引出單體架構的許多缺點。同樣，作為一個單一實體，可伸縮性是具有挑戰性的，成本也是高昂的。

面向服務的體系結構 (SOA)

SOA發展演變過程中，其理念是實現將應用程序視為業務功能的愿景。

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

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

2 Microservices——Artefacts

為什么是微服務——新模式？

IT的發展已經極大地改變了全球商業的前景。在早期，IT被認為是商業/組織的援助之手，用于減少業務功能/單元的手工工作。

如今，IT正被用來改造業務, 產生更多的收入。所以，現在IT不僅僅是一個支持功能，而是主要的業務功能。

Gartner 在其2015的10大戰略技術趨勢中表示：“為了迅速地應對數字業務和規模系統的快速變化需求，計算必須從靜態模式轉向動態模式。規則、模式和代碼可以通過應用程序動態地組裝，以及配置網絡所需的所有元素。”

這種在應用體系結構中思維的轉變，也帶來了實踐上的轉變。Gartner 的進一步預測表明，“對于許多組織來說，面向 Web-Scale IT 未來邁出的第一步應該是 DevOps ——以協調的方式將開發和運維結合在一起，以推動應用服務的快速、持續的增量開發。”

使用 Web-Scale IT 企業可以更輕松地構建類似于 Amazon、Google 和 Facebook 提供的應用程序和基礎架構。Web-Scale IT 能夠使企業在其 IT 設置中，進一步擁抱云，向內部用戶提供大型服務提供商的能力。

從SOA分化

微服務模式在定義特性方面比 SOA 更清晰，它提供了一個滿足現代應用程序體系結構需求的框架。微服務通常被稱為：正確實施的 SOA 。

SOA 專注于獨立的技術系統, 微服務專注于獨立的業務系統。

微服務模式的目標不是將各種應用程序連接在一起，而是創建一個由獨立開發、獨立部署的服務，組成的單一、聚合的應用程序，每個服務都遵循單一職責原則。然而，“微”這個表述，對于微服務的特性來說，可能會具有一點兒欺騙性，因為大小并不是微服務定義的特征。雖然微服務通常很小，但更重要的是每個服務自己封裝的流程可以獨立開發和部署。開發人員通過限制一個服務可做的事情范圍，來確保這些服務不會無意中和許多解耦的單體一起結束。

與現代云一樣，服務之間的通信是通過基于REST的API，通過HTTP完成的，傳遞JSON數據，通常通過消息隊列來確保可靠性。單個微服務通常是異步處理的，由API調用、推送隊列、調度或 webhook 等事件觸發。一個圍繞通信和處理的輕量級、高效框架，進一步將微服務與SOA區分開來。

將應用程序分解為多個服務

這里還有一些其他的體系結構風格可以進行擴展。《可伸縮性的藝術》一書，描述了一個非常有用的三維可伸縮性模型：伸縮立方（Scale Cube），如下圖所示。

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

使用 Z 軸收縮時，每個服務器都運行一份相同的代碼副本。在這方面，它類似于 X 軸縮放。最大的區別在于每個服務器只負責數據的一個子集。與X軸伸縮一樣，Z軸收縮可以提高應用程序的容量和可用性。

但是，兩種方法都無法解決開發增加和應用程序復雜性的問題。

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

Z 軸伸縮會拆分相似的服務, Y 軸伸縮會拆分不同的服務。在應用層，Y 軸縮放將一個整體應用程序拆分為一組服務。

每個服務都實現了一系列相關功能，如訂單管理、客戶管理等。

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

理想情況下，每個服務應該只有一小部分職責。SRP（單一責任原則）將類的責任定義為需要更改的原因，并且類應該只有一個原因需要更改。將SRP應用于服務設計也是有意義的。

微服務體系結構–通信機制

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

直接調用

應用程序客戶端 （如本機移動應用程序）可以對各個服務發出基于 REST 的 HTTP 請求，如下圖所示。

單個服務的 API

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

例如，顯示一個Web頁面可能需要調用大量服務。例如，Amazon.com描述了一些頁面如何需要調用100多個服務。即使是在高速互聯網連接上發出如此多的請求，更不用說低帶寬、高延遲的移動網絡了，這將非常低效，并導致用戶體驗差。

API 網關模式

這是一種更好的方法，因為客戶端將在網絡上對被稱為API網關的前端服務器發出每個頁面的少量請求，可能只有一個請求。

API 網關位于應用程序客戶端和微服務之間，它提供了針對客戶端量身定做的 API。API 網關為移動客戶端提供粗粒度的API，為使用高性能網絡的桌面客戶端提供細粒度的 API。在此示例中, 桌面客戶端發出多個請求以檢索有關產品的信息, 而移動客戶端則發出單個請求。

API 網關通過在高性能 LAN 上向一些微服務發出請求來處理傳入的請求。在此示例中，來自桌面客戶端的細粒度請求只是代理到相應的服務，而來自移動客戶端的每個粗粒度請求都通過聚合調用多個服務的結果來進行處理的。

3 Advantages of Microservices

組件的分離為構建和維護高度可伸縮的需求，提供了更有效的環境。獨立開發、獨立部署的較小的服務更容易維護、修復和更新，從而為響應當今不斷變化的環境提供更敏捷的功能。

• 模塊化

微服務以服務為單位;每個服務都有自己的邊界，你不能簡單地繞過邊界，這樣你就可以獨立地開發、部署和擴展服務。

• 特定于服務的數據庫

微服務是松散耦合的，并且擁有自己的數據庫，因此服務不會通過持有數據庫鎖來阻止其他服務。

• 故障隔離

微服務體系結構具有更好的故障隔離;一個服務的問題不會影響其他服務，其他服務將繼續正常工作。

• 可伸縮性

在個人服務水平上的擴展變得更具有成本效益，并隨需應變。可以并發地處理單個任務，而不會影響應用程序的其余部分。

分離應用程序的組件使單個錯誤或硬件故障導致整個系統癱瘓(消除單個故障點)的可能性降低。失敗的進程可以被隔離，并且可以退出端點直到到達。

• 技術/語言靈活性

每個單獨的服務都可以基于開發人員的首選項、任務適用性或與某個庫匹配的不同語言。

除此之外, 以下幾點也是微服務的主要優勢：

• 微服務體系結構允許開發人員自由地獨立開發和部署服務。

• 小團隊可以開發微服務。

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

• 易于集成和自動部署（使用開源持續集成工具，如 Jenkins、Hudson 等）。

• 易于理解和修改的開發人員，從而可以幫助一個新的團隊變得高效快速。

• api可以更有效地進行版本控制，因為單個服務可以遵循自己的方案。主要版本可以在應用程序級別執行，而服務可以根據需要更新。

• 將應用程序的組件分離開來，就不太可能出現單個錯誤或硬件故障導致整個系統癱瘓的情況。失敗的進程可以被隔離，并且向下的端點可以被退休直到到達（消除單個故障點）。

• 開發者可以使用最新的技術。

• 圍繞業務功能的代碼。

• 啟動web容器更快，所以部署也更快。

• 當應用程序的某個部分需要更改時，只能修改和重新部署相關的服務——不需要修改和重新部署整個應用程序。

• 更好的故障隔離：如果一個微服務失敗，另一個將繼續工作（盡管一個整體應用程序的一個問題區域可能會危及整個系統）。

• 易于擴展和與第三方服務集成。

• 沒有長期致力于技術棧。

4 Drawbacks of Microservices

將應用程序分離到獨立的服務意味著現在有更多的活動組件需要維護。這也帶來了一些挑戰。

• 復雜的業務流程

雖然微服務的一個主要優點是精簡的編排功能，但更多的服務意味著要維護更多的部署流。DevOps 在這個模式中扮演著更為重要的角色，因為每個服務都必須在它的整個生命周期中正確地配置。

• 服務間通信

分離的服務需要一種可靠、有效的方式來進行通信，同時又不會減慢整個應用程序的速度。通過網絡交付數據會帶來延遲和潛在的故障，這會影響用戶體驗。一種常見的方法是引入消息隊列作為可靠的傳輸層。

• 測試

雖然保持代碼和依賴關系緊密意味著為特定服務提供更簡單的開發環境，但它確實帶來了與整個應用程序相關的測試挑戰。服務通常需要相互通信，或者依賴于數據源或API。獨立地測試一個服務將需要一個完整的測試環境才能有效。

• 微服務體系結構帶來了大量的操作開銷。

• 要求有 DevOps 技能。

• 分布式系統管理起來很復雜。

• 由于分布式部署，默認跟蹤問題。隨著服務數量的增加，整個產品的管理變得越來越復雜。

5 結論

單體應用是用于構建企業應用程序的常用模式。它在小型應用程序中工作得相當好：開發、測試和部署小型單片應用程序相對簡單。

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

微服務體系結構有許多優點。例如，單個服務更容易理解，可以獨立于其他服務進行開發和部署。使用新語言和框架也容易得多，因為你可以一次嘗試一個服務的新技術。

微服務體系結構也有一些明顯的缺陷。特別是，應用程序要復雜得多，并且有更多的活動部件。你需要高度自動化，例如PaaS，才能有效地使用微服務。

在開發微服務時，還需要處理一些復雜的分布式數據管理問題。盡管存在這些缺點，但對于快速發展的大型復雜應用程序（尤其是SaaS風格的應用程序）來說，微服務體系結構是有意義的。

有許多策略可以漸進地將現有的單體應用程序演化為微服務體系結構。開發人員應該將新功能作為獨立的服務實現，并編寫粘合代碼將服務與單體集成。

迭代地識別組件以從整體中提取并轉換為服務也是有意義的。雖然這種改進并不容易，但它比開發和維護一個笨重的單體應用程序要好。

關于微服務中如何正確實施的SOA就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。