微服務架構可謂是當前軟件開發領域的技術熱點，它在各種博客、知識媒體和業界知名會議演講上的出鏡率非常之高，無論是做基礎架構還是做業務系統的工程師，對微服務都相當關注，而這個現象與熱度已經持續了近 5 年之久，經久不衰。

然而，隨著云原生技術的推廣，以及大量的微服務落地，反微服務的聲音越發響亮。尤其是在今年 3 月初，服務網格的著名開源項目 Istio 發布了 1.5 版本，其控制面由原先的多個微服務組件，合并成了一個單體應用，大大簡化了其架構與部署運維的復雜性，贏得了滿堂喝彩。社區關于微服務模式質疑的聲音此起彼伏，也有文章大聲呼喊：“醒醒，你不是真的需要微服務！”

那么，在云原生時代，是否需要微服務？什么時候應該采用微服務？微服務究竟能給業務帶來哪些好處？如何在不同環境下正確合理地落地微服務？希望讀完本文后，每位讀者都能在心中有個答案。

微服務是什么

2014 年，Martin Fowler 與 James Lewis 共同提出微服務的概念，定義了微服務架構是以一組小型服務的方式來開發一個獨立的應用系統，每個服務都以一個獨立進程的方式運行，每個服務與其他服務使用輕量級(通常是 HTTP )通信機制。這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署，同時服務會使用最小規模的集中管理能力，也可以采用不同的編程語言和數據庫，實現去中心化的服務管理。

而早在 2005 年，Peter Rodgers 博士在云端運算博覽會上就提出了為 Web 服務，將程序設計成細粒度的服務(Granular Service)，以作為 Microsoft 下一階段的軟件架構。

由此可以看出，微服務并不是一個新的概念，在很早之前就有了充足的理論基礎。大系統終究會拆解成小系統，“合久必分，分而治之”；傳統行業的系統架構大多都是龐大的單體架構，微服務是架構發展的一個非常自然的演變狀態。

遺憾的是，微服務模式并非“銀彈”，微服務也有其弊端和痛點。Martin Fowler 也在他的博客中寫道：“除非你的系統太復雜，作為單體應用會很難管理，否則不要考慮微服務。絕大多數軟件系統都應該構建為單體應用。要注重在單體應用中實現良好的模塊化，但不要試圖將其拆分成單獨的服務。”

微服務架構的優點

通常來說，架構沒有好壞優劣之分，只有適合與不適合。但是當把微服務架構與單體架構進行比較，會發現微服務有如下一些優點：

微服務還有許多優點，如“反脆弱性(anti-fragility)”、架構抽象、技術隔離等。但并不是說采用了微服務就自然地具備了這些特性。

微服務的先決條件

準確地來講，要想享受微服務的福利，需要具備一些先決條件。

一、團隊調整

需要重新組建團隊，以服務為核心，按照業務領域劃分全功能團隊，改變原有的研發流程、決策機制。例如，倡導敏捷文化、快速迭代，做更多的自動化測試，加強 Code Review 等。

在新的團隊組織里面，一切以人為本，需要建立開放自由的環境。領導對下級高度信任，增強其自我驅動，充分發揮每一個人的力量，而不是讓工程師成為“螺絲釘”。

微服務框架可以封裝、抽象分布式場景下的一些常用能力，例如負載均衡、服務注冊發現、容錯、遠程通信等能力，可以讓開發人員快速地開發出高質量的服務。因此，在采用微服務架構之前，應該先進行微服務架構的選型、學習和試用。整個團隊要對微服務的基本概念、微服務框架的實現原理，微服務治理與監控等知識需要有一定的儲備。

二、基礎設施建設

基礎設施即代碼，可以通過編程的方式管理虛機或容器，免去了手動配置、更新各個硬件的環節，這就使得基礎設施極具彈性，能夠快速、高效、準確地進行重復性操作。開發人員使用同一套代碼或配置，就可以部署并管理成千上萬臺物理機。

當服務數量增多、交付頻繁的時候，故障次數可能會大幅度上升，我們需要通過全面地監控發現故障，及時處理并發出警報。當生產環境出現問題的時候，需要將故障進行分級，評估影響面，并分配給相應的負責人。

微服務架構的一個大優勢就是快速交付，快速交付不止體現在服務的力度更小，可以獨立交付，還體現在整個流程更快速。微服務架構基于自動化的工具鏈，以流水線交付的方式串聯整個 DevOps 流程。小團隊可以基于服務獨立開發、測試、部署、運維。

以上這兩點不是采用微服務模式的充分必要條件，但當團隊滿足了上述兩個條件后，微服務化的過程將事半功倍，后續維護和迭代也會順風順水，而不是叫苦連天。

微服務是逐步拆分出來的

其次，微服務是應該隨著業務的演進逐步拆分出來的。

避免在設計系統的時候直接劃分微服務。幾乎所有成功的微服務架構都是從一個巨大的單體架構拆分出來的；幾乎所有在一開始就構建微服務架構的案例，后續都遇到了巨大的困難。

面對一個新的業務和領域，很難在開始階段就對業務梳理得很清晰，往往是經過一段時間踩過一些坑，經過模塊調整后，業務內部架構才能逐漸清晰起來。并且從一個已有的模塊清晰的單體架構逐步劃分服務，要比一開始就構建微服務簡單的多。如果一開始就劃分了微服務，其一，第一版交付的時間會延后許多，因為有許多公共服務需要去構建起來；其二，服務很容易拆分得不合理，大大影響整個調用流程的性能，甚至可能需要花費很大的精力去處理分布式事務，最后不得不再將多個微服務整合成一個單體。

只有當業務復雜度達到一定的程度后，微服務架構消耗的成本才會體現其優勢，這個時候就可以開始設計微服務架構、進行微服務劃分了。微服務設計應該優先尊重垂直劃分優先原則，垂直劃分服務可以讓團隊自上而下地關注業務實現，端到端負責，避免跨服務多次調用引起的性能與溝通成本。微服務需要監控與治理

拆分之前，整個系統擁有的服務數一般只有個位數；拆分之后，服務可能變成了數十上百個，實例數可能會達到成千上萬個。這么多服務與實例，需要構建一套監控系統，能夠監控所有服務日常運行狀態，并且需要在服務出錯的時候給對應負責人發出報警信息；在出現故障時，能夠通過調用鏈查詢以及服務拓撲圖等功能進行分析查看，也可以進一步查看到全息日志等具體信息。

除了監控，服務治理也至關重要。可以通過 SDK/Sidecar 手段提供服務高可用的治理策略，這些策略往往對業務是非侵入或者弱侵入的，能夠讓絕大多數服務輕松實現服務高可用。

微服務之間一旦建立起路由，就意味著會有數據在服務之間流通。由于不同服務可以提供的資源和對數據流量的承載能力不盡相同，為了防止單個 Consumer 占用 Provider 過多的資源，或者突發的大流量沖擊導致 Provider 故障，需要服務限流來保證服務的高可用。

在服務治理中，雖然我們可以通過限流規則盡量避免服務承受過高的流量，但是在實際生產中服務故障依然難以完全避免。當整個系統中某些服務產生故障時，如果不及時采取措施，這種故障就有可能因為服務之間的互相訪問而被傳播開來，最終導致故障規模的擴大，甚至導致整個系統崩潰，這種現象我們稱之為“雪崩”。熔斷降級其實不只是服務治理中，在金融行業也有很廣泛的應用。比如當股指的波動幅度超過規定的熔斷點時，交易所為了控制風險采取的暫停交易措施。

負載均衡是高可用架構的一個關鍵組件，主要用來提高性能和可用性，通過負載均衡將流量分發到多個服務器，同時多服務器能夠消除這部分的單點故障。

如何在云原生時代落地微服務

一、選擇合適的時機

就像前面提到的，組織架構與團隊文化要適應云原生的節奏，需要足夠敏捷、足夠自主，構建全功能團隊，產品、UI、前后端研發、測試等角色要齊全；需要提前做好自動化的流水線，可以一鍵構建、發布、部署，可以快速擴縮容等；服務提前做好容器化部署改造，服務容器化更適合在云原生場景下集成其他功能與組件。等上述一切都 ready 了之后，并且業務也逐步發展到了一定規模急需拆分了，這個時候就應該果斷進行微服務拆分和架構設計了。

二、選擇合適的微服務框架

現在主流的微服務框架主要分為兩類：侵入式與非侵入式。主流的開源侵入式框架包括 Spring Cloud、Dubbo、brpc 等，其功能特色各有千秋，在不同的場景均有應用，大部分架構師對其均有比較多的了解，社區和文檔的成熟度都比較高。雖然 Spring Cloud 這樣的傳統侵入式微服務框架大多具有版本碎片化嚴重、升級成本高等問題，但總的來說，已經可以滿足絕大部分服務治理的需求，并且借此快速推進微服務化改造。

現在大部分人更關心的是非侵入式框架的選型，即近幾年火起來的服務網格技術。2017 年，隨著 Linkerd 的傳入，Service Mesh 翻譯成服務網格，并開始進入國內社區的視野，部分大公司也同步自研了適配公司內部應用場景和依賴的服務網格框架，用以助力內部服務快速迭代與發展。

而 Istio 作為一個開源的 Service Mesh 開源框架，一經推出就備受矚目，成為了各大廠商和開發者爭相追捧的對象。很多人相信，Istio 會成為繼 Kubernetes 之后又一個明星級產品。有了 Istio，你幾乎可以不再需要其他的微服務框架，也不需要自己去實現服務治理等功能。只要把網絡層委托給 Istio，它就能幫你完成這一系列的功能。簡單來說，Istio 就是一個提供了服務治理能力的服務網格。此外，Istio 還提供完善的可觀察性方面的能力，包括對所有網格控制下的流量進行自動化度量、日志記錄和追蹤。換句話說，選擇了 Istio，單體應用無需做任何改造即可輕松接入微服務，享受云原生各項福利。

三、借助云廠商產品快速進行云原生與微服務落地

之所以提到云廠商，是因為大部分中小型公司或者傳統行業都面臨著單體應用和傳統微服務框架的各種弊端和詬病，急需進行云原生與微服務改造，但是缺乏足夠的人力與技術，去維護一套功能齊全的云原生底座與基礎架構服務。例如 Istio 框架，其版本迭代頻繁，控制面與數據面在提供了強大的功能的同時，代碼實現相當復雜，在遇到了異常的時候，很多工程師往往很難定位問題。

而云廠商則提供了一整套云原生應用編排與微服務管理解決方案，所有技術都得到產品化，方便使用與查看效果，并且避免或者快速解決運行期間可能遇到的各種問題。在一定程度上，這不僅提高的服務的效率，也大大降低了各種成本，可以快速充分地享受云原生福利，助力內部業務穩定對外服務，快速擴張。

總結

最后，我們再回到開篇的疑問，我們是否還需要微服務？

這個問題沒有唯一與正確的答案，每個人所處的場景不同，正如一千個人心中有一千個哈姆雷特。任何軟件或者架構都有其利弊，沒有十全十美的東西。大家需要思考和衡量的是，當前的軟件與系統是否滿足了微服務化改造的前提，微服務化改造后其帶來的收益是否大于損失、利是否大于弊，團隊各個方面是否做好了準備，如果還沒有，那么請你再等等，單體架構也挺好！

參考文獻

• 《持續演進的 Cloud Native 》 王啟軍 / 著
• 《Istio Handbook——Istio 服務網格進階實戰》ServiceMesher 社區聯合編著： https://www.servicemesher.com/istio-handbook/
• 《混合微服務高可用在企業級生產中的實踐》 羅廣明： https://cloudnative.to/blog/microservices-ha-practice/

關注我并轉發此篇文章，私信我“領取資料”，即可免費獲得InfoQ價值4999元迷你書，點擊文末「了解更多」，即可移步InfoQ官網，獲取最新資訊～

總結

以上是生活随笔為你收集整理的微服务的好处与弊端_在云原生时代，就一定要用微服务吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

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