王歡

Golang開發者、DockerOne社區譯者

讀完需要

8

分鐘

速讀僅需 3 分鐘

現在已經是2020年了。如果你想要從我這邊了解什么是微服務，那么這篇文章可能不適合你，你可以把寶貴的時間花在別的地方尋找相關信息。但是如果你正在經受各種微服務成功案例的洗禮并且被迫去使用微服務這款“靈丹妙藥”；那就繼續讀下去。不過開始時我們先說點讓人失望的地方。

盡管想寫這篇關于微服務的文章有一段時間了，但是直到最近我和一些朋友交流過后才真正的著手去把它寫下來的。最近我受邀參加了一個法定人數會議（quorum），并討論了一個有趣的問題?！笆裁词俏⒎找约拔覀儜撌褂眠@種架構作為解決方案嗎？”

問題的第一個部分比較好回答，第二部分就不好回答了。不過經過幾分鐘的討論，有幾點是比較清晰的。

• 受益人（beneficiaries）打算把微服務架構應用到他們以后的產品上；并且他們希望得到與會人員的肯定。

• 參加會議的人有很大一部分不是技術相關的。并且會議中對技術的討論越多，這些人就越顯得不相關。

• 會議中長時間的沉默以及對相關問題缺乏相應的提問表明許多人對Web服務都不了解，更別提微服務了。

我不是責備他們對Web服務的不了解，或者微服務能給他們帶來哪些好處和壞處。畢竟他們也有自己擅長的工作，而我不擅長的。他們只是跳上了不知道能給他們帶來哪些影響的微服務這趟車上。

我第一次聽到“微服務”這個詞是在2013年，一個YouTube視頻上，講的是關于Netflix服務架構的。視頻里面說了很多微服務相關的信息，但是我毫不猶豫的都跳過了。這對于一個當時想要進入設計領域的人來說，內容太多了。但是很快我就遇到了困擾，因為新項目計劃書要求使用微服務。這個項目的設計很優秀，并且現在仍然是我手上最優秀代碼庫中的一員。

誠實點說，最大化模塊設計讓我避免了很多坑。并且當時我還僅僅是一個初出茅廬的開發人員，跳過運維開發（DevOps），還額外加了一個密度（density）層。時間快速向前推進五年，這個時候我和一幫新的同事忙于一個新的產品。并且我每天要面對許多由于不好的微服務設計引起的問題，而且還要耦合業余的運維開發策略。不過這些問題很快就解決了，但是我又面臨微服務的脆弱性問題。最后我只能憑著自己的經驗去分析整個架構。亡羊補牢，為時未晚。

看到微服務既扮演正派角色又扮演反派角色，我勸解自己作為反派角色的擁護者。如果你是一個架構師或者設計者并且打算把微服務作為默認架構，我強烈建議你問自己幾個問題。

1

? ?

你的程序大到足夠分解為微服務嗎？

承認吧。不是所有的程序都足夠大到需要分解為更小的服務。正如微服務名字所暗示的，它是一個由更小的并且用于完成某個特定功能的獨立服務的集合。理想情況下，每個服務都是完全獨立的應用程序。

這是微服務與單體服務每行代碼成本（Cost per Line of Code）的比較圖。微服務會帶來更大的成本，即使這個微服務是個很輕量級的，原因是由于它在人力和計算成本方面需要一個最小的資源。每個人都要考慮成本，如果你不考慮，那么你可能就不應該做決策。

當然，你的代碼庫未來會不斷增長，并且它本身也可能會添加一個新域（domain）。但是你要永遠記住一條，當你需要的時候，一個設計良好的代碼庫總是能夠切換到微服務。

2

? ?

你真的需要伸縮（scale）應用中的不同組件嗎？

我們假設一下。你的產品負責人向你提出了一個HRMS應用程序的想法，這個程序需要處理一個擁有10k雇員的組織。作為一個技術愛好者的你立馬想出了一個解決方案：微服務架構。

當然，這是一個極端的例子，但是你能理解這個點！

使用微服務架構的另一個主要優點是伸縮單個組件很簡單。我們可以發現許多應用程序都需要對組件進行單獨的伸縮，但是你的應用程序真的需要這個功能嗎？

3

? ?

你是否有跨服務的事務？

現在，這是個即艱難又要講究策略的選擇?？缍鄠€服務的事務對整個架構來說是個不利因素。解決跨服務的事務意味著，服務之間的互斥鎖，一系列很難追蹤的死鎖以及競爭條件都會嚴重影響服務的健康運行；并且有時甚至會對工程師造成很大影響。

從定義上來看REST服務是無狀態的。并且它們也不應該參與到跨多個服務的事務中。在高性能世界中，兩階段提交（2PC）是不必要之惡。并且SAGA模式僅僅是加了一個你不了解的復雜層。

由于微服務使用了去中心化的數據管理，所以產生了最終一致性問題。單體應用中，你可以在一個事務中一次性更新許多東西。微服務需要更新多個資源的時候，使用分布式事務不是很好（有充分的理由）。所以現在，開發者需要意識到一致性問題，并且在代碼運行出現不可挽回的錯誤之前能夠及時的發現不一致的問題——Martin Fowler。

跨多服務的事務可行嗎？

是的，絕對可行的。

但是，是否有必要實現一個通過多個無狀態服務的鏈式操作？

可能沒必要！

4

? ?

服務之間是否需要頻繁的通信？

在傳統的單體服務中，每個模塊就是微服務實例的表現形式。模塊之間的通信都是使用內存并且延遲接近于0。微服務的引入意味著通信從使用內存轉移到了使用網絡。

目前市面上有許多成熟的解決方案，但是他們都有一個共同的代價——延遲。從使用內存轉移到基于網絡的通信會讓你的延遲從以納秒為單位變為以微妙為單位。想象一下，有三個不同的服務通過網絡互相通信。假設每個服務調用需要100毫秒（在負載很高的情況下這個是很正常的事情），那么僅僅在網絡上就要花費300毫秒。

另外有些應用程序天然的就與組件和服務緊密的集成在一起。比如在需要實時處理數據的應用中，額外的通信層可能會導致一個嚴重的后果。想象一下，在外科手術服中或者航空交通管制中出現通信延遲會出現什么后果。

5

? ?

其他補充

• 復雜度的增加——當然，復雜度不好量化，并且在相對情況下才有可比性。盡管微服務最初的目的就是通過把單個應用分解為更小的多個模塊來降低復雜度，但是在部署和維護方面微服務架構本身就很復雜。

• 部署（distribution）成本——微服務都是獨立的分布式系統。相同部分的部署都會有成本。比如你的單體應用之前都是部署在一個大的虛擬機上或者首選的容器上，但是微服務都是獨立部署（理想情況下）在不同的虛擬機或者容器上。雖然它們相對比較小，但是做個數學計算就知道了。并且我們還沒有把微服務的編排和維護算在里面。

• 運維開發的適配——這個要根據自身的情況來看，可能有利也可能有害。運維開發是一個已經被廣泛接受的并且也是一個被證實可操作的解決方案。但是如果你所在的團隊很小，那么組建一個運維開發團隊帶來的問題要比好處大。但是有一件事是可以確定的，如果你不投入一個運維開發團隊，那么你就沒法對微服務進行有效的維護和監控。

• 緊密集成——有些應用程序本身就需要緊密的耦合。為了適應微服務架構而去解耦他們可能會產生嚴重問題。

• 經驗不足——經驗不足是個很嚴重的問題并且它們不僅僅局限在SOA這塊。對于持有抽象定義的微服務來說，可能會產生更嚴重的問題。如果你的微服務是按照順序部署的，并且你的服務依賴其他服務，那么如果你依賴的一個服務掛掉了，你自己的服務此時崩潰了，這個時候再去處理就會顯得很晚了。

• 端到端測試——典型的單體應用可以讓你啟動并且幾乎立馬運行測試。對于互相依賴的多個服務，如果沒有可靠的編排，那么測試就會被延遲。

• 混亂的數據合約（contracts）——在同一個團隊中制定和保持數據合約和在不同團隊之間共享有著極大的不同。并且當你使用微服務時，你的團隊有可能都沒在用；更不必說讓他們都使用相同的編程語言。為特殊需要制定相應的數據合約也會消耗你的時間和精力。

• 遺留代碼庫——對于我們中的大部分人來說，處理遺留的代碼庫就是每天的日?；顒?。大部分公司都是這種情況。快速變化的新技術不斷的推動著我們向前走，同時，它也把我們與遺留代碼庫隔離的越來越遠。

  你確信你剛剛開發的RabbitMQ框架能夠和你之前部署在IBM AIX服務器上的應用程序工作很好嗎？

• 調試的痛苦——每個服務都有自己的日志文件。更多的服務=更多的日志文件。

6

? ?

總結

我有告訴過你“不要使用微服務”嗎？

絕對沒有！

我們經常會聽到微服務一個比較好的優點是，它們解決了之前我們都認為解決不了的問題。Netflix使用微服務構建系統已經成為了一個好的典范。當然成功的案例不僅僅只有Netflix。Uber， SoundCloud，以及偉大的亞馬遜都是成功的一員。另外也不要認為成功的案例僅僅局限于消費應用程序。我曾在美國一家醫療保健巨頭工作過，每一次打開源代碼看到他們在設計上的創新（possibilities），都會讓我很著迷。

如果五年前你就入了微服務的坑，那么我不會譴責你的盲從。畢竟時間不一樣了，我們現在能做的就是誠實的看待它。但是現在是2020年了，我們已經踩過太多的坑并且我們身邊也有很多這樣的案例。不必要的引入微服務架構，將會導致不良的代碼變成不良的基礎架構。

我喜歡一個充滿熱情的程序員。我曾經是并且現成依然是其中的一員。他們堅持自己所做的事并且能夠超預期的解決別人的問題。但是在做決策方面就很難保持這樣的熱情，畢竟那是需要一點運氣成分在里面的。很抱歉讓你失望了。微服務不應該作為你的默認選擇。它們不是你尋找的銀彈。堅持使用KISS和YAGNI原則。

作為一個技術擁護者和愛好者，你有權利有自己的喜好。但是當面對“正確的選擇”和“喜歡的選擇”的時候，讓你變得更卓越的是實用的選擇能力。

祝好運。

原文鏈接：https://medium.com/swlh/stop-you-dont-need-microservices-dc732d70b3e0

想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信

申請備注（姓名+公司+技術方向）才能通過哦！

? ?END ? ?? #接力技術，鏈接價值#精彩推薦1.?從0到1設計一個秒殺系統2.?蘇寧金服技術大揭秘：支付決策機器人 3.?阿里P9專家右軍：以終為始的架構設計 4.?手哥架構寶典系列：支付系統2.0架構演進5.?阿里高級技術專家王夕寧：Istio網關之南北向流量管理漫畫推薦1.?漫畫：程序員和產品經理撕得真是太太太太厲害了 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經30歲了，更扎心的是…7. 圖解：這才是程序員加班的真正原因！8.?漫畫：中國互聯網往事(2000-2020)

總結

以上是生活随笔為你收集整理的停！你不需要微服务的全部內容，希望文章能夠幫你解決所遇到的問題。

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