經過微服務來正確實施SOA

對於組織來講，可以構建、發展和擴展大型應用程序是相當重要的, 但所涉及的挑戰使其成爲一項艱鉅的任務。正由於如此, 微服務憑藉可以將單個組件拆分紅圍繞特定業務功能的獨立服務，已成爲構建現代雲應用程序的主要模式。

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

雖然使用微服務在使大型應用程序更易於管理方面有諸多好處，可是在任何狀況下，構建一個可靠的分佈式系統都是很是具備挑戰性的，由於在處理故障、一致性和性能等方面有不少須要考慮的因素。

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

SOA：面向服務的架構

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

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

Introduction

微服務是一種體系結構風格。它是一種將單個應用程序開發爲一組小型服務的方法，每一個服務都運行本身的流程，並與輕量級機制通訊，一般是 HTTP API。這些服務是圍繞業務功能構建的，能夠獨立部署。

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

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

另外，這種方法更傾向於輕量級消息總線。簡單來講，基於微服務構建的應用程序，其目的是儘量地作到解耦和聚合。它們擁有本身的單個域邏輯，並更多地充當過濾器——接收請求，根據須要適當地應用邏輯，併產生響應。

微服務體系結構的本質並不新鮮，分佈式系統的概念由來已久。微服務體系結構也相似於SOA。微服務背後的理念是構建大型的、複雜的、長期存在的應用程序，即隨着時間的推移，而演進成一套統一的（有組織的或相互鏈接的）服務。「微服務」這一術語強烈代表了服務應該是小型的。

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

應用程序的發展演變

單層應用程序

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

可伸縮性對於這種應用程序來講，是一個巨大的挑戰，由於它只能經過複製整個應用程序來實現。這將直接增長企業的成本，並隨着流量和負載的增長而形成資源浪費。

多層 (或 n 層)

單層/總體應用的缺點致使了多層體系結構的產生。這種新體系結構將應用程序分解爲邏輯分佈式層，從而實現了高效的可伸縮性。這種方法一般將表示層、數據層和業務邏輯層分離。因此，擴展方法單獨應用於這些層，而不是應用於整個應用。

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

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

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

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

雖然這種模式爲構建有效的應用程序體系結構提供了框架，但因爲沒必要要的複雜抽象和遺留協議，它的實踐一般是無效的。開發人員將嘗試使用 SOA 來鏈接範圍普遍的應用程序，它們都採用不一樣的語言，須要爲企業服務總線提供額外的層。這致使了過期、昂貴的配置，沒法跟上技術和商業環境的發展。

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 專一於獨立的技術系統, 微服務專一於獨立的業務系統。

微服務模式的目標不是將各類應用程序鏈接在一塊兒，而是建立一個由獨立開發、獨立部署的服務，組成的單1、聚合的應用程序，每一個服務都遵循單一職責原則。然而，「微」這個表述，對於微服務的特性來講，可能會具備一點兒欺騙性，由於大小並非微服務定義的特徵。雖然微服務一般很小，但更重要的是每一個服務本身封裝的流程能夠獨立開發和部署。開發人員經過限制一個服務可作的事情範圍，來確保這些服務不會無心中和許多解耦的單體一塊兒結束。

與現代雲同樣，服務之間的通訊是經過基於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 上向一些微服務發出請求來處理傳入的請求。在此示例中，來自桌面客戶端的細粒度請求只是代理到相應的服務，而來自移動客戶端的每一個粗粒度請求都經過聚合調用多個服務的結果來進行處理的。

Advantages of Microservices

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

模塊化

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

    特定於服務的數據庫

微服務是鬆散耦合的，而且擁有本身的數據庫，所以服務不會經過持有數據庫鎖來阻止其餘服務。

    故障隔離

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

    可伸縮性

在我的服務水平上的擴展變得更具備成本效益，並隨需應變。能夠併發地處理單個任務，而不會影響應用程序的其他部分。

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

    技術/語言靈活性

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

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

微服務體系結構容許開發人員自由地獨立開發和部署服務。
    小團隊能夠開發微服務。
    不一樣服務的代碼能夠用不一樣的語言編寫。
    易於集成和自動部署（使用開源持續集成工具，如 Jenkins、Hudson 等）。
    易於理解和修改的開發人員，從而能夠幫助一個新的團隊變得高效快速。
    api能夠更有效地進行版本控制，由於單個服務能夠遵循本身的方案。主要版本能夠在應用程序級別執行，而服務能夠根據須要更新。
    將應用程序的組件分離開來，就不太可能出現單個錯誤或硬件故障致使整個系統癱瘓的狀況。失敗的進程能夠被隔離，而且向下的端點能夠被退休直到到達（消除單個故障點）。
    開發者可使用最新的技術。
    圍繞業務功能的代碼。
    啓動web容器更快，因此部署也更快。
    當應用程序的某個部分須要更改時，只能修改和從新部署相關的服務——不須要修改和從新部署整個應用程序。
    更好的故障隔離：若是一個微服務失敗，另外一個將繼續工做（儘管一個總體應用程序的一個問題區域可能會危及整個系統）。
    易於擴展和與第三方服務集成。
    沒有長期致力於技術棧。

Drawbacks of Microservices

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

複雜的業務流程

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

    服務間通訊

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

    測試

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

    微服務體系結構帶來了大量的操做開銷。
    要求有 DevOps 技能。
    分佈式系統管理起來很複雜。
    因爲分佈式部署，默認跟蹤問題。隨着服務數量的增長，整個產品的管理變得愈來愈複雜。

結論

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

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

微服務體系結構有許多優勢。例如，單個服務更容易理解，能夠獨立於其餘服務進行開發和部署。使用新語言和框架也容易得多，由於你能夠一次嘗試一個服務的新技術。

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

在開發微服務時，還須要處理一些複雜的分佈式數據管理問題。儘管存在這些缺點，但對於快速發展的大型複雜應用程序（尤爲是SaaS風格的應用程序）來講，微服務體系結構是有意義的。

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

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