醒醒！你不是真的需要微服務

2020 年，很多技術人可能都已經迷醉在了微服務的成功故事中，但現實很骨感，微服務也不是“靈丹妙藥”，本文想給現階段“狂熱”的微服務潑潑冷水、降降溫，也許你就會發現，你并不是真的需要微服務，

2020 年，如果再講什么是微服務，已經落伍了，畢竟微服務的成功故事已經開始在業界廣為流傳了，但是你真的需要微服務嗎？

“真的需要微服務嗎？”這個想法已經困擾我很長一段時間了，最近我與多位技術人進行了溝通，也許我們可以從解決一個有趣的問題，開始入手，“什么是微服務？我們的解決方案應該遵循這種架構嗎？”

問題的第一部分很容易回答，而第二部分則需要高屋建瓴、謹慎對待，在溝通之后，我發現有個事情是大家都達成共識的：

• 受益者會把微服務架構應用到他們即將推出的產品中，因為他們需要立刻出效果來背書，

• 參與討論的人里有大量的非技術人員，當談話越來越“技識訓”，與決策也就越不相關了，

• 長時間的中斷以及提不出問題，這也就意味著不熟悉 Web 服務，更不用說微服務了，

我不會因為他們不知道 Web 服務是做什么，或者微服務如何對他們有利或有害而譴責他們，畢竟，他們在我不擅長的作業上要出色得多，他們打算加入微服務的行列，雖然還不甚了解其影響!

我第一次聽到“微服務”這個詞是在 2013 年，當時是在 YouTube 上一個解釋 Netflix 服務架構的視頻中，當時我覺得這讓人無法理解，所以毫不猶豫地跳過了，畢竟，這對于當時想方設法要進入設計原理領域的人來說太難了，但是，當新的專案提案宣布采用微服務時，它很快就讓我著迷了，這個專案的設計很吸引人，它仍然是我接觸過的最好的代碼庫之一，

說實話，模塊化設計的廣泛可能性可以減少負擔，而我只是一個無知的開發人員，對 DevOps 避之唯恐不及，它帶來了額外的復雜性，如果快進 5 年，我可能正在和一群全新的人開發一個全新的產品，我的日子里充斥著由設計糟糕的微服務和業余的 DevOps 戰術所引發的問題，雖然問題很快就解決了，但我看到了微服務的脆弱性，這也讓我根據自己的經驗來審視整個架構，雖然已經太晚了，但晚做總比不做好！

看到了微服務的正反兩面影響，我開始告誡自己要多看看反面影響，在實踐微服務之前，先問自己以下幾個問題，

必須承認，并不是所有的應用程式都大到可以分解成更小的服務，顧名思義，微服務是一組更小的、具有特定用途的服務，在理想的情況下，我們希望每個服務本身都是一個完整的應用程式，

這是微服務和單體服務之間“每行代碼成本”的一個比較，由于微服務在人力和計算成本方面的最小資源限制，即使在比較輕量化的形式下，也會產生較高的成本，成本是每個人都關心的問題，如果不是，你可能根本就不該做決定，

當然，你的代碼庫將來會增長，它也可能會增加一個新的領域，但你應該永遠記住：一個設計良好的代碼庫隨時都可以切換到微服務，所以在接近閾值時實踐微服務，是性價比最高的，

假設你的產品負責人帶著一個 HRMS 應用程式的想法來找你，想要通過它管理一個上萬人規模的組織，你可能立馬就有了解決方案：微服務架構，

當然，這是一個極端的例子，但是你明白我的意思!!

使用微服務架構的一個主要優點是單個組件非常容易擴展，我們可能會發現大量的應用程式需要組件可以單獨擴展，但是你的應用程式真的需要這樣做嗎？

現在，這可能是最困難的戰略選擇之一，跨多個服務的事務是整個架構的負擔，解決跨服務的事務意味著，服務之間的互鎖、一系列難以跟蹤的死鎖以及可能破壞服務健康的競爭條件；有時甚至是工程師的健康，

根據定義，REST 服務是無狀態的，它們不應該參與超出單個服務的事務，在高性能的世界里，兩段提交 [2PC] 是一個不必要的麻煩，而 SAGA 模式只會增加另一層意料之外的復雜性，

微服務引入了最終一致性問題，因為它們堅持分布式的資料管理，在單體架構中，你可以在單個事務中一次更新一堆東西，微服務需要多個資源來更新，不贊成采用分布式事務（理由很充分），所以現在，開發人員需要注意一致性問題，并在寫任何代碼之前，弄清楚如何檢測不同步，

——Martin Fowler

有可能跨服務進行事務處理嗎？

是的，當然，

但是，是否值得在整個無狀態的服務中實作一系列操作呢？

恐怕不行！！！

在傳統的單體服務中，每個微服務實體表現為系統內的模塊，模塊之間的通信在記憶體中，延遲接近于零，微服務的引入意味著，通信已經從記憶體事務變成了網路指令，

有許多可靠的解決方案可供我們選擇，但它們都以延遲為代價，從記憶體事務轉變為基于網路的通信將把延遲單位從納秒變為微秒，假設有三個不同的服務通過網路相互通信，假設每個服務呼叫需要 100 毫秒 [在有負載的情況下這不可能]，那么僅在網路上就需要花費 300 毫秒，

有些應用程式生來就與組件和服務緊密集成，在處理實時資料的應用程式中，增加的通信層可能會導致災難性的結果，想象一下，當你穿著外科手術服或者在控制航空交通時，通訊出現了延遲！

增加復雜性——當然，復雜性無法量化，只能相對地進行比較，雖然微服務最初的設計目的是通過將應用程式拆分成更小的塊來降低復雜性，但是架構本身在部署和維護方面很復雜，

分布式的成本——微服務是具有分子特性的分布式系統，但分布式也有代價，單體服務將部署在大型 VM 或首選容器上，但是，對于微服務，需要使用多個 VM 或容器（在理想情況下）單獨部署每個服務，當然，它們可能很小，你可以自己算算，請記住，我甚至還沒有討論過服務編排和維護所涉及的成本，

Devops 的采用——取決于你從哪個角度看，這可能有益，也可能有害，DevOps 是一種被廣泛接受的、經過驗證的運營解決方案，但是，如果你屬于一個較小的組織，那么構建一個 DevOps 團隊所造成的傷害可能會多于帶來的進步，但是，有一件事是肯定的，那就是如果沒有專門的 DevOps 團隊，你就無法維護和監控微服務，

緊密集成——有些應用程式天生就是緊耦合的，將它們解耦以“適應”架構將是災難性的，

缺乏經驗——缺乏經驗對于任何問題都至關重要，不僅僅局限于 SOA，但當涉及到微服務時，由于它所持有的抽象定義，它可能會加劇損害，如果你的微服務部署通過部署規則將你推到了次要位置，或者當某個依賴項服務宕機時崩潰，那就太晚了，

端到端測驗——一個典型的單體應用程式讓你可以幾乎同時啟動和運行測驗，而如果沒有可行的編排，那么具有相互依賴關系的多個服務將使測驗延期，

混亂的資料契約——在團隊中制定和使用資料契約與在團隊之間共享資料契約有很大的不同，當你使用微服務時，你的團隊可能不在同一個區域；更不用說他們都使用相同的編程語言，為了特殊需要而制定資料契約需要你付出時間和空間成本，

遺留代碼庫——老實說，對于我們大多數人來說，處理遺留代碼庫是一項日常作業，它是大多陣列織的主要收入來源，日新月異的技術進步讓我們保持領先，與此同時，它也將我們與遺留代碼庫隔離開來，“你確定你剛剛開發的 RabbitMQ 框架適合于托管在 IBM AIX 服務器上的遺留應用程式嗎？”

除錯缺陷——每個服務都有自己的一組日志檔案要查看，更多的服務等于更多的日志檔案，

我是來告訴你“不要使用微服務”的嗎？

絕對不是！！！

事實上，微服務一直以來都有不太好的名聲，但它們解決了我們都認為無法解決的問題，Netflix 公司采用微服務的故事啟發了許多人，而且，這個名單并不僅僅局限于 Netflix，Uber、SoundCloud 和巨頭亞馬遜都是我們可以立馬找到的微服務實踐案例，而且，成功的故事不僅限于消費者應用程式，我曾與美國醫療保健巨頭合作過，我每次看到他們的原始碼，都會被其設計深深吸引，

如果你 5 年前就跟風了微服務，我不會譴責你的輕信，時代不同了，我們現在所能做的就是誠實地面對它，現在是 2020 年了，我們受的傷已經夠多了，周圍有太多粗暴的處理了，無端地引入微服務架構，只會將糟糕的代碼變成糟糕的基礎設施，

我喜歡充滿熱情的程式員，我曾經是，現在仍然是，他們熱愛自己的作業，超越期望地解決問題，但在做決定時不能這樣，這可能會讓你和公司都損失一大筆錢，很抱歉讓你失望了，微服務不應該是默認的應用程式架構，它們不是你要找的銀彈，遵循 KISS 和 YAGNI 原則，讓自己保持穩定，

作為一名技術倡導者和愛好者，你有權擁有自己的偏好，然而，讓你脫穎而出的是，當選項是“正確的選擇”和“你最喜歡的選擇”時，你要有做出切合實際選擇的能力，

https://www.linkedin.com/pulse/stop-you-dont-need-microservices-ebin-joh

作者丨Ebin John

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/stop-you-dont-need-microservices-ebin-joh.html

標籤：架構設計

上一篇：SpringBootRestAPI問題

下一篇：錯誤碼如何設計才合理？