住手！你不需要微服務！

作者：Ebin John是ThoughtFocus的技術架構師。

現在是2020年。如果你想要我介紹微服務是什麼東東，本文可能不適合你，你還是把寶貴的幾分鐘花在別處吧。但如果你沉醉於微服務的種種成功故事，想靠這味「靈丹妙藥」實踐一番，那就請讀下去。抱怨會讓你失望幾分鐘。

雖然微服務概念流行已有一段時日，但最近與幾個人進行一番交談後，我覺得有必要寫下來。我受邀參加了一個仲裁小組，為「微服務是什麼？我們應該採用這種架構作為解決方案嗎？」這個發人深省的問題給出答案。

雖然問題的第一個部分很容易回答，第二個部分回答起來頗為棘手。交談了幾分鐘後，有幾個事實很清楚。

受益者將微服務架構應用於他們即將推出的產品，他們尋求一番肯定。

仲裁小組中相當多的人不懂技術。而隨著交談的「技術性越來越強」，交談對於仲裁變得無關緊要了。

長時間的停頓和無人提問表明大家對Web服務不熟悉，對微服務不熟悉更不用說了。

我不會怪他們不知道Web服務是幹什麼的或者微服務如何給他們帶來好處或壞處。他們準備搭上微服務這趟彩車，卻不知道前方有什麼後果等著！

我頭一次聽到「微服務」這個詞還是在2013年，當時YouTube上的一段視頻解釋Netflix服務的架構。信息太多一時消化不了，我毫不猶豫地快進了視頻。對於當時想進入設計原則領域的人來說，這個概念太複雜了。但是新的項目方案宣布採用微服務後，它很快成了一股風潮。該項目的設計令人著迷，它仍是我曾經接觸過的最佳代碼庫之一。

老實說。模塊化設計的廣泛前景讓我無暇顧及其弊端。而我就是一名無知的開發人員，離devops躲得遠遠的，因此又隔了一層面紗。五年後，我在開發一款全新的產品，與一批新的人員共事。我見過設計糟糕的微服務以及業餘的devops戰術引起的種種問題。我很快認識到了微服務的弱點。這也讓我得以從整體上打量架構。為時太晚，但勝過根本沒有覺悟！

看到微服務同時扮演正派和反派的角色之後，我勸告自己要成為唱反調的人。如果你是傾向於將微服務作為默認架構的架構師或設計師，我勸你硬著頭皮向自己問幾個問題。

你的應用程序龐大得足以細分成微服務嗎？

讓我們承認吧。並非所有應用程序都龐大得以足分解成較小的服務。顧名思義，微服務是一大堆各司其職的小服務。在理想情況下，我們會要求每個服務本身都是一個完整的應用程序。

每行代碼的成本

下面假設對微服務與整體式服務「每行代碼的成本」作一番比較。由於微服務在人力和計算成本方面需要的最少資源，微服務需要的成本較高，哪怕是輕量級微服務。而成本是每個人都關心的問題；不然，你可能根本不會做出使用微服務的決定。

當然，你的代碼庫在將來會越來越大，代碼庫本身可能會添加一個新的領域。但你應該永遠記住：當你接近閾值時，設計良好的代碼庫始終可以切換到微服務。

你是否果真需要擴展應用程序的各個組件？

假設一下。產品負責人向你提出了使用人力資源管理系統（HRMS）應用程序的想法，以滿足員工上萬人的組織的需求。作為技術愛好者的你立馬有一個解決方案：微服務架構。

當然這是極端的例子，不過你明白了其中的道理 ！！

使用微服務架構的主要優點之一是易於擴展單個組件。我們可能會找到組件需要單獨擴展的大量應用程序，但你的應用程序果真需要這麼做嗎？

你的事務跨諸多服務嗎？

現在，這可能是最難做出的戰略性選擇之一。跨多個服務的事務是整個架構的一個負擔。解決跨服務的事務意味著：服務之間的互鎖、一系列難以追蹤的僵局，以及會危及服務健康狀況、有時甚至是工程師健康狀況的競態條件。

按照定義，REST服務是無狀態的。它們不應該參與邊界不僅限於一項服務的事務。在高性能環境下，兩階段提交[2PC]是不必要的麻煩。而SAGA模式只會增加你沒有準備好的另一層複雜性。

由於微服務堅持採用分散式數據管理——這個做法值得稱讚，微服務帶來了最終一致性問題。如果是整體式應用程序，你可以在單個事務中一起更新一堆東西。微服務需要多個資源才能更新，而分散式事務不受歡迎（這有充分的理由）。因此，開發人員需要意識到一致性問題，並在做代碼會後悔的任何事情之前，搞清楚如何發現何時不同步——Martin Fowler。

可能會有跨服務的事務嗎？

是的，絕對有可能。

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

恐怕不值得！！

服務之間是否需要經常聯繫？

在傳統的整體式服務上，每個微服務實例由系統內的模塊加以表示。模塊之間的聯繫在內存中進行，延遲接近零。微服務的引入意味著，聯繫由內存中事務完全變成了通過網路傳達指令。

有眾多久經實踐考驗的解決方案，但是它們都有代價：延遲。從內存中事務改為基於網路的聯繫會將延遲從納秒變為微秒。想像一下，三個不同的服務通過網路彼此聯繫。假設每個服務調用要花費100微秒（這在負載情況下並不少見），那麼到頭來單單在網路上就要花掉300微秒。

而一些應用程序本質上與組件和服務緊密集成。添加的通信層可能會給處理實時數據的應用程序造成災難性的後果。設想一下外科手術或航空公司交通管制方面的通信延遲！

另一些缺點

增加了複雜性——當然，複雜性無法量化，只能以相對的方式進行比較。雖然微服務原本旨在通過將應用程序分解成小組件來降低複雜性，但架構本身部署和維護起來卻很複雜。

我們要更清楚地認識到這點，即普通的IT部門並沒有像Netflix的工程團隊那樣的技能組合。

分布成本——微服務是具有模塊性的分散式系統。但是同樣的分布確實要付出代價。你的整體式服務會部署在大型虛擬機或首選容器上。但如果是微服務，除了多個虛擬機或容器外，服務需要獨立部署[在理想的環境上]。當然服務可能很小，但你可以計算一下總成本。記住，我甚至還沒有談到服務編排和維護涉及的成本。

改編Devops——這可能有益也可能有害，取決於你所站的角度。Devops是一種被廣泛接受且經過驗證的運維解決方案。但如果你是小型企業組織的成員，成立一支Devops團隊會是弊大於利。不過有一點倒可以肯定，要是沒有專門的devops團隊，你就無法維護和監控微服務。

集成緊密——一些應用程序天生就緊密耦合。將它們分開來以「適應」架構將會帶來災難。

缺乏經驗——缺乏經驗對任何問題來說都是重要因素，並不僅限於SOA。但是說到微服務，由於擁有抽象定義，造成的危害尤其大。如果你的微服務部署因部署順序而將你逼到被動的地步，或者某一個依賴項服務出故障後導致崩潰，那麼你為時已晚。

端到端測試——一個典型的整體式應用程序將使你可以幾乎立即啟動並運行測試。若沒有切實可行的編排，有多個相互依賴的服務會延誤測試。

混亂的數據合約——在團隊內部設計和訂有數據合約與團隊之間共享數據合約大不相同。你在接觸微服務時，你的團隊可能不在同一個地區，更不要說團隊成員都採用同一種編程語言了。為特定要求制定數據合約會耗費你的時間和空間。

遺留代碼庫——老實說吧。對於我們大多數人來說，處理遺留代碼庫是一項日常工作。它是大多數企業組織的立足之本。迅速變化的技術進步讓我們處於領先，而同時也使我們離遺留代碼庫漸行漸遠。

你確信剛開發的RabbitMQ框架可以與託管在IBM AIX伺服器上的遺留應用程序很好地兼容嗎？

調試令人痛苦——每個服務都會有自己的一組日誌文件要審查。更多服務意味著更多的日誌文件。

結束語

我在這裡是要告訴你「別使用微服務」嗎？

絕對不是！！

微服務的名聲一向不太好。沒錯，微服務解決了我們都認為無法解決的問題。Netflix改編微服務的故事啟發了好多人。而試水微服務的並不僅限於Netflix。優步、SoundCloud和亞馬遜就是幾個現成的例子。別以為成功案例僅限於消費者應用領域。我近距離過接觸過一家美國醫療保健界巨頭，每次打開源代碼，都著迷於設計方面的機會。

如果你在五年前緊跟微服務潮流，我不會譴責你的盲目輕信。今非昔比，我們現在能做的就是對微服務坦誠相見。而眼下是2020年，我們忙得不可開交。如果不必要地引入微服務架構，只會將你的不良代碼變成不良基礎架構。

我喜歡滿懷熱情的程序員。我曾經是這樣的程序員，現在依然是。他們崇拜所做的事情，不遺餘力地解決別人的問題。但是你不可能將同樣的精力傾注到決策中；決策不當，會害你和貴企業蒙受重大損失。很抱歉，要讓你失望了。微服務不應該是你的默認應用程序架構。微服務也不是你所尋找的靈丹妙藥。應遵循KISS（力求簡單）和YAGNI（你不會需要它）原則，保持有條不紊。

作為技術倡導者和發燒友，你有權喜歡自己青睞的技術。但是讓你脫穎而出的是能夠在 「正確的選擇」與「你青睞的選擇」之間作出切合實際的選擇。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！