微服務是一種優化資源的體系結構方法，這些資源為復雜、快速、分布式基礎設施上的大規模服務和軟件提供計算、存儲和網絡。大多數有IT歷史的組織，傳統上都是在虛擬技術棧上構建軟件，這些技術棧由操作團隊手動維護。今天，開發人員大規模使用云服務來構建應用程序架構和自動化工作負載。面向機器架構的時代正在過去——面向應用程序的基礎設施正在流行。今天，這些資源提供了全堆棧的、開發人員構建應用程序體系結構所需的內容。開發團隊需要為應用程序架構更全面地開放資源，這證明了DevOps工具在功能強大的分布式架構上運行的深層需求。

[[279488]]

對技術工具、服務和平臺的需求包含在構成微服務的內容。無限的計算、網絡和存儲資源的平衡，為運行任意數量的服務提供了機會和障礙。就像任何一種過度興奮的、吸引技術社區注意的新方法一樣，在圍繞微服務的炒作中，往往沒有提及復雜性。從表面上看，開發、部署和管理軟件的完美方法可能要比最初出現的方法復雜得多。因此這是一個讓公司深入了解業務目標、團隊開發、工作流和用于構建應用程序架構的服務的旅程。通常，對于那些技術背景與微服務的現代方法不匹配的人來說，做出改變并不容易。微服務要求組織重新考慮運行其業務的現有軟件體系結構，以及組織如何適應需要新的技術技能和文化轉變來匹配的實踐。這種實踐有風險，并不是每個人都能做到。

盡管如此，大約90%的開發人員至少都在為一些工作負載考慮微服務架構。然而，當被更具體地問及它們在生產應用程序中的使用時，這個數字下降了。然而，與任何快速發展的新興技術一樣，要想理清所有的炒作，就要理解微服務如何實際應用于日常工作。這有助于從微服務的實際基礎開始，然后權衡軟件體系結構本身的好處和缺點。

微服務的定義

微服務是一種基于將應用程序構建為小型服務集合的軟件開發體系結構方法。對于構成“小型服務”的代碼量并沒有標準定義。一些專家說，這與查詢服務運行狀況時的“大小”有關。如果一個服務需要多個team來管理，那么它就太大了。每個服務都有自己獨特且定義明確的角色，在自己的流程中運行，并通過HTTP應用程序編程接口(API)或消息傳遞進行通信。每個微服務都可以獨立于應用程序中的所有兄弟服務進行部署、升級、擴展和重新啟動。它們通常由自動化系統編排，使實時應用程序的頻繁更新成為可能，而不會影響最終用戶。

個人可能更習慣使用應用程序的概念。但如今，一般的企業組織至少使用十幾種不同的軟件產品和集成。記錄業務開銷、進度跟蹤和工資管理等，是組織現在使用運行在云服務上應用程序的幾個例子。使用緊湊而專業的工具以提供優雅用戶體驗的方式完成每項工作是有意義的，類似于個人應用程序在社交網絡上發布照片、視頻和與他人聯系時所獲得的體驗。微服務使用包含云服務的分布式體系結構，以一種松耦合的模式組合在一起來進行擴展。就像樂高積木一樣，微服務中的組件可以在適當的位置構建一個統一的模型。

(微服務是小型、獨立擴展和管理的服務。每個服務有其自己獨特和良好定義的角色，運行自己的流程和通過HTTP API以或Messaging進行溝通)

首先，開發人員確定構建項目所需的獨立服務“部分”，例如搜索、身份驗證、消息傳遞和銷售處理。然后，從服務、庫和可用代碼片段、從開源到交鑰匙企業解決方案的大雜燴中進行選擇，并將所有內容整合到一個功能應用程序中。

云原生浪潮

云原生微服務的概念源于容器體系結構的發展。

在基于容器的體系結構之前，開發人員需要構建技術堆棧，然后將其部署到云服務或健壯的企業體系結構上。這些應用程序是面向機器的，并使用監控軟件及其在云服務和企業上的性能的一系列工具進行優化。這是超越面向服務架構(SOA)的一步，盡管有些人認為SOA只是由供應商重新命名以銷售相關產品的微服務，這是有一定道理的。

微服務可以被認為是SOA的一種類型。容器只是使方法更加廣泛可用，并降低了SOA帶來的風險程度。在虛擬機(VM)上運行的SOA需要時間和投資來構建、部署和運行。VM運行在操作系統上，而操作系統也必須進行移植才能在SOA環境中運行。這是一項繁重的手工工作，并且幾乎沒有為尋找實際運行SOA本身的好的方式而承擔風險的空間。

由Docker領頭，容器改變了游戲規則。Docker代表了SOA的發展和平臺即服務(PaaS)的時代。Docker通過其簡單、易用和低風險推動了采用率。它將Linux容器技術打包成開發人員可以訪問和使用的內容。構建、運行和管理容器技術只需很少的開銷——這與重量級的SOA世界形成了鮮明的對比，后者需要大量的投入，尤其是在網絡和存儲方面。

容器現在充當微服務的底層基礎，通過API網關和gRPC等新方法連接。總體而言，容器使SOA可以通過簡單地使技術更易于使用而大規模實施，所涉及的風險遠遠低于以往。微服務與DevOps、持續集成和持續交付(CI / CD)，以及容器的使用密切相關。事實上，“微服務”和“容器”這兩個術語經常一起使用。但是，容器和微服務并不是一回事。微服務可以在容器內運行，但它也可以作為完全配置的虛擬機運行。也就是說，基于容器和開源的平臺，如Docker和Kubernetes，是開發、部署和管理微服務的一種非常有效的方法。容器空間中已經存在許多成熟且健壯的工具、平臺和其他服務，這使得容器化非常適合基于微服務的應用程序。

雖然容器和微服務獨立存在并且用于不同的目的，但它們經常一起使用;它們甚至還被視為DevOps的好拍檔。容器是微服務的一種使能技術，這也是微服務通常在一個或多個容器中交付的原因。由于容器是隔離環境，因此無論用于創建每個微服務的編碼語言如何，它們都可用于快速安全地部署微服務。一旦基于微服務的應用程序達到顯著的規模，在沒有容器的情況下幾乎不可能管理它。運行在集群編排平臺(如Kubernetes或Mesos)之上的容器化微服務，包括在云中、本地或混合模式，是當前對向外擴展的云原生應用程序的定義。

重要的是要注意雖然容器是將代碼打包到微服務中的“嚴格”方式，但也可以將整個單體應用程序打包到容器中，而不需要創建微服務。隨著云計算的進一步發展，以及更多組織從傳統基礎架構中解放出來和/或開始評估無服務器架構的用例，打包可以而且很可能會發生變化。事實上，許多微服務的支持者表示，它們只是多云和無服務器計算的跳板，這是一種利用資源自動化功能和填補應用程序架構空白的新興方法。

有行業專家認為，將微服務和容器結合起來只是一個實施細節，而不是一個重要的抽象概念，除非在VM上有很多需要遷移到同一技術堆棧的傳統應用程序。

微服務的好處

通過使小型自治團隊能夠獨立開發，部署和擴展各自的服務，微服務基本上可以并行化開發 ——從而以指數方式加速生產周期。這種敏捷性是大型企業在多種報告中指出采用微服務所引用的首要原因，其次是改進的可擴展性。

微服務可以讓開發人員不必浪費時間重新解決已經解決的技術問題。持續集成和部署基本上構建在微服務架構中。微服務可以直接把很多基礎設施風險帶出項目。隨著基礎設施變得幾乎不可見，微服務團隊可以進行通常以小時周期運行的快速迭代，從而持續降低錯誤功能的風險，同時增加價值。

換句話說，使用微服務，團隊中的每個開發人員都可以忘記底層基礎設施，專注于自己的項目。然后在生產中，如果單個項目模塊不能完全正確地工作在一起，那么很容易對它們進行隔離、拆卸和重新配置，直到正確地工作為止。這些組件是松耦合的，就像樂高一樣。這種方式提供了使用可互換的部件在應用程序體系結構中大規模運行的能力。它們的獨立和獨立結構也帶來了安全性優勢，因為更容易通過自動化和實施安全策略的現代安全平臺進行控制。

隨著組織的發展，工程團隊可以更輕松地擴展和維持速度。微服務架構的主要好處不是技術，而在于團隊開發和人員管理。相比之下，當代碼庫增長到一定規模時，單體應用程序變得無法適應和管理。管理這種規模的應用程序架構的團隊絕不能讓單體架構失效。如果整體架構失效了，那么業務也會隨之流失。因此編寫腳本以防止應用程序泄漏并在主要版本升級之間構建各種補丁成為企業架構師的重要優先事項。功能是預先定義好的，并按照優先級與整體相適應;客戶則被夾在中間，并且做出的強制性決策可能是短期的解決方法，但會帶來較長期的問題，例如定制化的腳本隨著時間推移而失效，并且依賴于具有企業基礎架構記憶的人員。這本身是一個糟糕的體驗，因為新的軟件升級可能無法解決客戶遇到的問題。

一個主要問題是(單體)應用程序會變得極其復雜。它太大了，任何單個開發人員都無法完全理解。因此修復bug和正確實現新特性將變得困難且費時。更重要的是，這是一個惡性循環。如果代碼庫難以理解，那么將無法正確進行更改。許多組織已經達到了這樣一個階段，即管理單體應用整體結構的痛苦超過了采用新的微服務方法。微服務的采用是這類組織的優秀選擇，盡管它也有自己的挑戰。

微服務的缺點

微服務是經典單體應用的對立面，具有明顯的優勢。但是，與任何正在發展的技術一樣，早期采用曲線可能很陡峭。目前，Netflix和PayPal等大公司最有效地采用了這種方法，由于強大的內部資源和工程團隊，這些公司已經能夠轉向微服務架構。

Netlify首席執行官兼聯合創始人Mathias Biilmann表示:“當你擁有一個非常龐大、資源豐富的企業，個人團隊能夠管理每項服務并確保可重用性和可探索性時，這是非常棒的。”然而，對于其他人來說，痛苦是真實存在的。根據有關報告，只有1%的企業使用微服務表示他們對架構沒有任何挑戰。操作開銷、日志記錄和監視方面的挑戰以及缺乏技能被列為最主要的挑戰。離開單一的應用程序體系結構意味著失去將所有部分粘合在一起的固定工作流。最常見的情況是，因為IT團隊主要負責集成和維護許多不同服務的基礎設施，采用微服務體系結構會增加操作成本。團隊必須在微服務遠景與實際需要之間艱難地找到平衡，才能使其發揮作用并取得成功。

當將整體分解為微服務時，將冒著一個非常分散的系統風險，開發人員需要花費大量的時間和精力將服務和工具粘合在一起，并且缺乏可以跨項目工作的常見模式和平臺 。為了真正利用微服務，需要能夠構建可以實現一鍵設置的“膠水”供應商。”

(遷移到微服務，通常為帶來了大量運維挑戰，因為集成和維護很多不同服務的基礎設施責任落在了IT團隊)

LAMP堆棧的出現可以作為一個很好的對比。Linux、Apache web服務器、MySQL和 PHP等免費工具為web開發開辟了新的可能性。但當公司圍繞WordPress、Drupal和Joomla等項目構建集成工具時，LAMP體系結構才真正起飛。

在真正的微服務方法中，團隊只運行他們需要的小服務，而不運行其它任何負載。但是，這種實施和編配工作已經超出了許多中小型組織的工程范圍。將一個整體分割成許多更小的、獨立的服務在速度和敏捷性方面有許多優勢，但也有許多挑戰。微服務架構可以增加支持和維護的運營開銷，因為每個服務都有自己的語言和要求。這也使得監控和安全性變得更加復雜，因此需要更高水平的自動化和工具。而且由于服務之間的通信現在通過網絡進行，因此它會對服務發現、消息傳遞、緩存和容錯產生新的要求，這些要求可能會給系統帶來壓力，如果處理不當可能會導致性能問題。雖然Service Mesh解決了許多這樣的問題，但是引入一個沒有流量管理的Service Mesh服務，它自己就會產生一些問題，這些問題可能會導致更嚴重的性能問題。

可以提前做所有想做的測試，并且這會對要發布的代碼相當有信心。但是當真正把它投入生產時，就會遇到各種各樣的問題，因為實際上并不知道代碼在生產中會如何表現。流量管理實際上是將部署與發布解耦。部署是指擁有新代碼、新版本并將其投入生產，但還不占用任何客戶流量。可以做煙霧測試、內部測試，這些測試都在生產中運行。當發布一個版本時，就會開始思考：要給這個新版本的代碼帶來什么樣的流量?如果有能力把流量控制到非常精細的水平的話，可以分割、控制、并逐步推出新的代碼更改。

沒有工程資源或技能將穩定的基礎架構與現有的開源代碼和工具結合在一起的組織，很難 讓微服務的好處大于挑戰。操作和性能問題也可能困擾那些沒有就其服務(依賴關系和版本兼容性)進行溝通的團隊，并且必須在生產失敗時撤回已經寫入的代碼。幸運的是，微服務市場正在起飛。許多公司現在不僅生產微服務本身，還生產無縫連接它們所需的平臺、工具和框架。

微服務不適合所有人

分布式服務的基礎架構已經成熟，但是更高的效率只能來自于更好的聲明式系統，這些聲明式系統來自于改進的自動化技術和改進的可觀察性。因為沒有任何微服務是完全相同的，這么做可能很棘手。它們的任何自定義工作流程就像雪花一樣。不同之處在于底層的體系結構，以及如何適應針對不同工作負載的微服務方法的不斷開發。

設置邊界很重要，這樣微服務就不會被認為是萬靈藥或有趣項目的分支，因為微服務需要更多的管理。開發者大批量地構建微服務要追溯回2014年至2016年的鼎盛時期，這些開發者在喝茶聊天的時候決定了新的微服務該怎么構建。因此現在如果有幾十個團隊決定創建自己的微服務，會發生什么?雖然管理是完全可能的，但是會犧牲效率，從而影響優化和獲得更好性能的過程。

毫無疑問，微服務是有效的。但是，一個構建良好的單體應用整體架構也可以擴展，并且在許多場景中仍然是很好的選擇。例如，運行相同服務或工作程序的多個實例不一定需要微服務。創建不可伸縮的微服務也是完全可能的。因此在確定解決方案之前，首先考慮面臨的問題是很重要的。

就基礎設施和技術支持而言，生態體系現已接近關鍵的規模。微服務正迅速成為DevOps工具包中的一個工具，從而更好、更深入地利用資源。這進而創建了新的空間來交付額外的服務，從而進一步實現聲明性的和優雅的工作流、工具和平臺的潛力。

向著微服務過渡的業務和流程決策

云原生微服務是一種真正令人興奮的架構演化，尤其是在構建、部署和管理復雜分布式應 用程序方面。然而，大多數圍繞微服務的討論直接涉及到技術：持續集成和部署、容器、 編排器等等。雖然技術實現很重要，但是還有一些更重要的事情需要考慮。

微服務必須與組織的目標相適應。開發人員可以構建微服務，但是體系結構只有與業務目標相結合時才有價值。因此必須提出關鍵問題，從業務用例、現有團隊、技能和職責開始——采用微服務的決策取決于組織的目標和遠景。組織中具有實現復雜體系結構經驗的人員必須提出一個重要的問題，并在繼續前進之前得到答案：我們是否適合微服務體系結構?

Container Solutions的CEO和聯合創始人Jamie Dobson曾表示，客戶找過來希望使用微服務作為技術問題的解決方案，實際上卻常常是組織問題的技術解決方案。

評估云原生服務。評估企業采用云原生微服務與企業本身的關系，而與企業的規模、行業甚至實際技術關系不大。首先，從決策到執行的微服務遷移應該由企業的組織和管理方式驅動：

商業模式：軟件可以差異化業務嗎?如果是這樣，開發團隊必須繼續增長和擴展，因為組織需要更多的資源和服務功能。基于微服務的體系結構允許更快的迭代開發，可以在跨多個團隊的工作流中使用。依賴專有的、統一解決方案的組織將不太適合微服務方法。系統記錄管理(ERP)到服務級別協議(SLA)類的商業軟件協議意味著，如果企業選擇遵循將它們帶入微服務討論的路徑，那么它們將發生根本性的轉變。對于完全依賴于商業軟件平臺的組織來說，實現微服務的成本可能會更高。微服務所需的在敏捷性和可伸縮性方面的工程支持和開銷成本將超過它們的價值。

文化和內部流程：微服務需要一套新的工具和流程，并打破舊的工具和流程。對于負責管理單體的組織來說，突然改變工作流可能是一個困難的轉變。接受DevOps原則是微服務成功的關鍵。然而，舉例來說，團隊可能會抗拒從傳統的瀑布方法轉向敏捷方法。微軟首席云開發布道師Bridget Kromhout曾表示，“如果你意識到所涉及的人有著他們自己的習慣而且他們也許在不遠的未來就要退休了，那么這種抵制并不是完全不合理的，而且他們不喜歡一切改變的想法，他們只是以他們喜歡的方式看待問題。”

微服務的基本復雜性在于應用程序體系結構本身：根據體系結構，每個服務都需要自己的支持團隊、工具和基礎設施。并不是每家公司都在正確的位置采取行動。專家強調，并不是說錯誤地采用這種體系結構是不可能的，只是這個過程會更長或更復雜。對于許多有著錯誤商業動機或文化的組織來說，成本將高于收益。Bridget Kromhout再次強調：不能通過實施正確的技術解決方案來解決組織中的每一個問題，因為組織是復雜的系統，其中也有可能以不可預知方式行事的人。

那么，什么時候微服務不適合企業呢?

敏感行業：某些行業，例如金融服務和醫療保健，面臨法律、報告和合規要求，需要與新技術相協調。可追溯性因素：與更年輕、更緊湊或更敏捷的組織相比，一家在商業領域經營數十年的全球性公司，尤其是平均員工保留時間超過10年的公司，很可能更難適應向全新架構的巨變。“停滯不前”的公司：這些是規避風險的公司，決策鏈很長，層次結構僵化。因此當采用一種新的響應性微服務范例時，這些組織并不十分適合，甚至可能會對所需的快速適應產生抵觸。

New Relic的首席站點可靠性工程師Jonathan Owens表示，考慮轉向容器和微服務架構的組織應該問自己以下問題：您的運營團隊向開發人員提供了什么產品，該產品使用了什么抽象層? 該產品是否適合您的業務，還是容器更合適? 容器是否更好，以至于您愿意更改抽象層，從而更改運營團隊提供的整個產品，以便使用它們?您是否已準備好創建新角色來管理此新抽象的規模和可靠性?

沒有哪個組織會在一夜之間發生這樣的變化。從一個理想化的新架構到第一個產品部署的過程需要改變許多想法并創建新的流程，這并不總是很有趣。尋找具有微服務專業知識且能夠做出必要的工具和架構決策的工程師也很困難。這些專家包括難以捉摸的“全棧開發人員”，他們了解每一層的應用程序：從網絡和托管環境，到數據建模、業務邏輯、API和用戶界面以及用戶體驗(UI / UX)。這些人處于獨特的位置，可以看到技術體系結構和組織是如何相互關聯的。要實現成功的微服務轉換，組織需要一個按比例構建的技術體系結構，但維護該結構的團隊也同樣重要。

這就是為什么許多正在向微服務過渡的組織選擇與專業服務公司合作，這些公司專門幫助客戶使用各種不同的架構來構建云原生應用程序。這些顧問可以幫助評估組織對微服務的需求和適用性，或指導他們采用更合適的替代方案。

微服務最適合嗎?

對于由業務原因而采用微服務的組織，可以滿懷信心地帶領團隊轉型。領導項目的團隊在組織中具有重要地位，并可以開始設置適合現有工作流的優秀實踐。團隊可以采用服務來推動應用程序體系結構的整體開發，并為組織使用更多資源運行微服務做好準備。

做準備時需要技巧和人員管理。適合開發團隊的服務將定義微服務。團隊的目標是使微服務成為一個建立在其價值基礎上的“底座”，并不斷優化開發人員的體驗。

評估應用程序的職責是定義微服務應用程序組件的第一步，Netlify首席技術官David Calavera曾表示，他是Docker和GitHub先前工作的微服務老手。確定應用程序職責的相互依賴關系，這關系到微服務的結構。Connascence是一個評估應用程序組件和互連的衡量標準。因為兩個或多個組件是并發的，所以如果改變其中一個組件，還必須更改另一個組件。

考慮到這種關系，可以更好地評估是否值得擁有不同的微服務，或者是否應該保留的單體架構。除了相互依賴之外，團隊必須牢記將這些組件分離到微服務中會引入它們之間的網絡連接——這不可避免地增加了系統的復雜性。

應用程序體系結構開發是個人和團隊如何就他們自己以及重疊的編排進行交互和通信的直接結果。很明顯在這一點上，像Kubernetes這樣的架構正變得越來越重要。隨著越來越多的開發人員添加進來，應用程序變得越來越復雜，體系結構的總體復雜性也隨之增加。但是正如所看到的，這些應用程序架構并不適合所有人。

Calavera警告說:“您不希望以犧牲理想架構為代價來增加不必要的復雜性。”