作者 | Pushpraj Malik
原文 | Microservices — Future Applications
來源 | DZone（點擊閱讀原文即可查看）
翻譯 | BoCloud博雲
對於組織來說，能夠構建、發展和擴展大型應用程序是至關重要的, 但所涉及的挑戰使其成爲一項艱鉅的任務。正因爲如此, 微服務憑藉能夠將單個組件拆分成圍繞特定業務功能的獨立服務，已成爲構建現代雲應用程序的主要模式。
微服務架構是一種分佈式系統的方法，它可以促進使用具有自身生命週期的細粒度服務。由於微服務主要是圍繞單個業務流程/功能而建模的，所以它們避免了傳統分層 (多層/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風格的應用程序）來說，微服務體系結構是有意義的。
有許多策略可以漸進地將現有的單體應用程序演化爲微服務體系結構。開發人員應該將新功能作爲獨立的服務實現，並編寫粘合代碼將服務與單體集成。
迭代地識別組件以從整體中提取並轉換爲服務也是有意義的。雖然這種改進並不容易，但它比開發和維護一個笨重的單體應用程序要好。
參考文獻：
1.Fowler, Martin, and Lewis, James [25 March 2014] Microservice Architecture.
2.http://martinfowler.com/articles/Microservices.html
3.http://Microservices.io/patterns/Microservices.html
4.http://www.infoq.com/presentations/Micro-Services