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

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