Sander Hoogendoorn認為，向微服務遷移就意味著向分布式系統進行遷移，在這里，我們必須要處理延遲、認證與授權、無法到達的消息。通過使用微服務，我們能夠將大型系統拆分為更小的組件，從而實現對架構的重新掌控。借助于微服務，我們可以通過擴展并部署單個或一組組件的方式，實現小的變更或添加單獨的特性。

Hoogendoorn會在9月12至13日舉行的SwanseaCon 2016上做最終的主題演講，這是在南威爾士舉行的第二個有關敏捷開發和軟件匠藝的會議。InfoQ對他進行了采訪，我們討論了多個話題，包括單體架構的軟件產品的問題、如何使用微服務來構建最小化的可行產品、微服務的測試、微服務如何適應持續交付、微服務的優勢和劣勢，針對希望實現微服務的組織，他還給出了自己的建議。

有很多人針對微服務相關的話題撰寫過文章，涵蓋了如何使用和測試微服務、因使用微服務而創建的分布式系統所帶來的額外復雜性該如何進行處理，并提供了在組織中實現微服務的建議。

InfoQ：在組織中，采用單體架構的軟件產品的最大問題是什么？

Sander Hoogendoorn：單體的系統，不管是采用什么語言編寫，運行在什么平臺上，隨著時間的推移都會不斷增長。這意味著會有很多不同的人針對它們來開展工作，每個人在寫代碼的時候，都有其自己的風格。在系統存在的這些年中，會有特性的添加、修改和移除，這通常會導致不穩定架構的出現。另外，系統不是隔離運行的，通常會與更為廣泛的系統進行集成，這樣的話，會帶來大量的外部接口。

因為很難集成新的特性，所以很多的組織在推出某項新特性的時候會耗費很長的時間才能將其推向市場。創新會減緩，經常會很難甚至根本不可能去擁抱新的技術。

InfoQ：微服務是如何為這些問題提供解決方案的呢？

Hoogendoorn：微服務架構的基本理念就是將大型的系統拆分為更小的組件，因此幫助組織實現對系統架構的重新掌控。這些組件之間的交流會通過易于使用的協議來實現，如基于HTTP的REST和JSON。這個詞的前綴“微”意味著組件會按照代碼行或服務端點的數量來進行衡量，但是我更喜歡采用領域驅動設計范式中的有界上下文（bounded context）來拆分系統，在這里每個組件會負責處理系統領域中一個獨立的部分。

在InfoQ關于微服務反模式的文章中，Vijay Alagarasan闡述了微服務與面向服務架構（SOA）之間的關聯關系：

如果你沒有合適的人、文化和投入的話，SOA不會實現其業務價值。微服務架構與SOA沒有本質的差異，它們的目標是一致的，但是微服務的方式更加精細，我可以這樣說，微服務就是實現了可擴展性的SOA。

InfoQ：你們如何使用微服務構建最小化的可行產品（Minimum Viable Product）呢？

Hoogendoorn：按照最小化可行產品的思考方式，意味著要持續關注為產品新增價值，這需要通過提供該價值的最小版本來實現。微服務允許我們通過擴展一個或一組組件，為其添加獨立的特性，并將它們（獨立地）部署到系統之中。如果搭建了對應的持續交付功能，那么部署所修改組件的新版本就可以通過每日的基礎代碼來進行，當然這需要有相應的自動化測試。按照這種方式，在組織內部就可以持續地實現小的變更。

InfoQ：測試微服務可以采用什么方式呢？

Hoogendoorn：當你將整個系統拆分為很小的組件時，就需要在很多不同的級別來進行測試。首先，單元測試要覆蓋到組件內部的所有內容。其次，服務接口需要進行測試，驗證它是否會產生正確的輸出或文檔，比如JSON對象或PDF。下游的應用或其他的組件如果使用該組件所提供的服務，那么它們也需要進行測試，檢驗組件的輸出是否依然正確。在微服務架構中，服務是松耦合的，通常會使用基于HTTP協議的REST和JSON，因此對于某個服務接口的變更，團隊不一定馬上就能意識得到。在組件的每次變更之后，都要運行自動化測試，這樣的話，整個管道（pipeline）就能盡可能快地發現破壞性的變更。隨著組件和服務數量的增長，測試的數量也會快速膨脹，在微服務架構中，我推薦讓所有的測試都能實現自動化。

在一個關于微服務開發和測試的采訪中，來自Redgate軟件的Jose Lima則認為在微服務中，你并不需要將所有的測試都實現自動化，可以由其他的人實現功能檢查，而不一定通過測試人員來完成：

有些人會認為測試自動化同樣也是一項必備的技能，但我并不認同。首先，我不相信測試自動化，其次，檢查自動化也可以由團隊的其他人員來執行，并非一定要由測試人員來執行。并沒有什么所謂的測試自動化，但肯定有檢查自動化——對我而言，測試涵蓋的內容要比檢查更多，檢查的過程可以進行自動化，不過只有你理解了要做什么以及這意味著什么之后，你才能夠將功能檢查做好（不管是否采用自動化），這樣的話就能檢查它的行為是否符合預期。

InfoQ：微服務是如何與持續交付協作的？

Hoogendoorn：借助持續交付，每項變更都會成為發布版本的備選內容。在微服務架構中，這意味著一個或一組組件會持續有新版本發布出來。因為這些組件會發布到分布式系統或互相協作的服務之中，所以設計良好部署管道就顯得尤為重要，管道需要集成自動化測試的功能，這甚至比持續交付與單體架構結合使用時更為重要。你可能會說在理論上持續交付和微服務能夠很好地進行協同。但在我的經驗中，組織內將會面臨大量的配置，這樣做并不一定總能讓事情變得更簡單。

按照Alagarasan的說法，如果你想要采用微服務的話，持續部署和自動化測試是必需的：

如果你還沒有采用持續部署的話，那么作為任意一家企業來講都應該在這方面進行投資，并致力于實現相關的文化變更。至少，如果你無法實現自動化測試和部署的話，那么就不要采用微服務。微服務的目標在于驅動敏捷性，其中會伴隨速度的變化；質量保證會涉及到每一個服務，每項服務都要具有自動化的單元、功能、安全以及性能測試。

InfoQ：微服務的優勢和劣勢是什么呢？

Hoogendoorn：往微服務架構遷移有助于將大型的系統拆分為更小的組件，從而實現對系統架構的重新掌控。這些獨立的組件更加易于管理、替換、部署、擴展和測試。采用新的技術，如新語言、框架或數據庫，也會變得更加容易，因為它們可以用于較少的一些組件中，而不必一次性地用到整個系統之中。但是，采用微服務也會帶來其他的影響。這些小組件之間的通信會大幅增加。實際上，組織必須要意識到往微服務的遷移就意味著往分布式系統進行遷移，在得到它所有收益的同時，也伴隨著分布式系統的所有缺點，包括必須要處理延遲、認證與授權、無法抵達的消息。

在InfoQ上一篇名為“微服務：分解應用以實現可部署性和可擴展性”的文章中，Chris Richardson也認為實現微服務就意味著創建分布式系統：

開發人員必須要處理創建分布式系統所帶來的額外的復雜性。開發人員必須要實現進程間的通信機制。要實現跨多個服務的用例的話，如果不使用分布式事務是很難完成的。IDE以及其他的開發工具關注于開發單體架構的應用，并沒有為開發分布式應用提供明確的支持。編寫涉及到多個服務的自動化測試用例也是很有挑戰的。在開發整體架構應用時，你無需處理這樣的問題。

InfoQ：對于希望實現微服務的組織，你有什么建議要給他們嗎？

Hoogendoorn：考慮采用微服務的組織應該有這樣做的正當理由，而不僅僅因為這是當下最火的技術。這樣做的理由可以包括當前的系統無法維護、新技術或平臺需要納入到系統中或者新特性推向市場的時間需要大幅減少。但是，當我們向微服務架構遷移的時候，還有很多的方面要考慮進來。它會改變我們設計、構建和測試軟件的方式，它會改變我們搭建部署管道、認證與授權的方式，還會改變團隊運維和協作的方式，這甚至會改變與組織內外利益相關者的交流方式。但是最為重要的是，需要意識到你將要構建的是分布式系統，這并不簡單。有時候，另外一種方案就是采用與微服務相同的設計技術來拆分單體應用，然后依然在單體應用中重構和模塊化我們的代碼。

Alagarasan建議與總經理和高級主管一起協作，推動實現微服務所需的文化變更：

微服務的目標在于解決三個最常見的問題，也就是提升用戶體驗、應對新需求的高度敏捷性和降低成本，我們借助細粒度的服務來交付業務功能，就可以解決這三個問題。這并不是什么銀彈，它需要訓練有素的平臺，在這里會以敏捷的方式來交付服務，從而使高質量成為了可能。（...）這是我們討論容器化、云應用等內容之前所必需的一小步。(...)大多數的行為都會帶來組織文化的變更，這是你自己所無法完成的，因此需要確保能夠與你的總經理和高級主管進行協作。

原文地址：http://www.infoq.com/cn/news/2016/09/microservices-distributed-system

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的微服务意味着分布式系统的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。