作者：Ebin John是ThoughtFocus的技術(shù)架構(gòu)師。

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

雖然微服務(wù)概念流行已有一段時日，但最近與幾個人進行一番交談后，我覺得有必要寫下來。我受邀參加了一個仲裁小組，為“微服務(wù)是什么？我們應(yīng)該采用這種架構(gòu)作為解決方案嗎？”這個發(fā)人深省的問題給出答案。

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

• 受益者將微服務(wù)架構(gòu)應(yīng)用于他們即將推出的產(chǎn)品，他們尋求一番肯定。

• 仲裁小組中相當(dāng)多的人不懂技術(shù)。而隨著交談的“技術(shù)性越來越強”，交談對于仲裁變得無關(guān)緊要了。

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

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

我頭一次聽到“微服務(wù)”這個詞還是在2013年，當(dāng)時YouTube上的一段視頻解釋Netflix服務(wù)的架構(gòu)。信息太多一時消化不了，我毫不猶豫地快進了視頻。對于當(dāng)時想進入設(shè)計原則領(lǐng)域的人來說，這個概念太復(fù)雜了。但是新的項目方案宣布采用微服務(wù)后，它很快成了一股風(fēng)潮。該項目的設(shè)計令人著迷，它仍是我曾經(jīng)接觸過的最佳代碼庫之一。

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

看到微服務(wù)同時扮演正派和反派的角色之后，我勸告自己要成為唱反調(diào)的人。如果你是傾向于將微服務(wù)作為默認架構(gòu)的架構(gòu)師或設(shè)計師，我勸你硬著頭皮向自己問幾個問題。

你的應(yīng)用程序龐大得足以細分成微服務(wù)嗎？

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

每行代碼的成本

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

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

你是否果真需要擴展應(yīng)用程序的各個組件？

假設(shè)一下。產(chǎn)品負責(zé)人向你提出了使用人力資源管理系統(tǒng)（HRMS）應(yīng)用程序的想法，以滿足員工上萬人的組織的需求。作為技術(shù)愛好者的你立馬有一個解決方案：微服務(wù)架構(gòu)。

當(dāng)然這是極端的例子，不過你明白了其中的道理?！！

使用微服務(wù)架構(gòu)的主要優(yōu)點之一是易于擴展單個組件。我們可能會找到組件需要單獨擴展的大量應(yīng)用程序，但你的應(yīng)用程序果真需要這么做嗎？

你的事務(wù)跨諸多服務(wù)嗎？

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

按照定義，REST服務(wù)是無狀態(tài)的。它們不應(yīng)該參與邊界不僅限于一項服務(wù)的事務(wù)。在高性能環(huán)境下，兩階段提交[2PC]是不必要的麻煩。而SAGA模式只會增加你沒有準備好的另一層復(fù)雜性。

由于微服務(wù)堅持采用分散式數(shù)據(jù)管理——這個做法值得稱贊，微服務(wù)帶來了最終一致性問題。如果是整體式應(yīng)用程序，你可以在單個事務(wù)中一起更新一堆東西。微服務(wù)需要多個資源才能更新，而分布式事務(wù)不受歡迎（這有充分的理由）。因此，開發(fā)人員需要意識到一致性問題，并在做代碼會后悔的任何事情之前，搞清楚如何發(fā)現(xiàn)何時不同步——Martin Fowler。

可能會有跨服務(wù)的事務(wù)嗎？

是的，絕對有可能。

但是，是否值得在無狀態(tài)服務(wù)中實施一系列操作？

恐怕不值得！！

服務(wù)之間是否需要經(jīng)常聯(lián)系？

在傳統(tǒng)的整體式服務(wù)上，每個微服務(wù)實例由系統(tǒng)內(nèi)的模塊加以表示。模塊之間的聯(lián)系在內(nèi)存中進行，延遲接近零。微服務(wù)的引入意味著，聯(lián)系由內(nèi)存中事務(wù)完全變成了通過網(wǎng)絡(luò)傳達指令。

有眾多久經(jīng)實踐考驗的解決方案，但是它們都有代價：延遲。從內(nèi)存中事務(wù)改為基于網(wǎng)絡(luò)的聯(lián)系會將延遲從納秒變?yōu)槲⒚搿Ｏ胂笠幌?#xff0c;三個不同的服務(wù)通過網(wǎng)絡(luò)彼此聯(lián)系。假設(shè)每個服務(wù)調(diào)用要花費100微秒（這在負載情況下并不少見），那么到頭來單單在網(wǎng)絡(luò)上就要花掉300微秒。

而一些應(yīng)用程序本質(zhì)上與組件和服務(wù)緊密集成。添加的通信層可能會給處理實時數(shù)據(jù)的應(yīng)用程序造成災(zāi)難性的后果。設(shè)想一下外科手術(shù)或航空公司交通管制方面的通信延遲！

另一些缺點

• 增加了復(fù)雜性——當(dāng)然，復(fù)雜性無法量化，只能以相對的方式進行比較。雖然微服務(wù)原本旨在通過將應(yīng)用程序分解成小組件來降低復(fù)雜性，但架構(gòu)本身部署和維護起來卻很復(fù)雜。

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

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

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

• 集成緊密——一些應(yīng)用程序天生就緊密耦合。將它們分開來以“適應(yīng)”架構(gòu)將會帶來災(zāi)難。

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

• 端到端測試——一個典型的整體式應(yīng)用程序?qū)⑹鼓憧梢詭缀趿⒓磫硬⑦\行測試。若沒有切實可行的編排，有多個相互依賴的服務(wù)會延誤測試。

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

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

  你確信剛開發(fā)的RabbitMQ框架可以與托管在IBM AIX服務(wù)器上的遺留應(yīng)用程序很好地兼容嗎？

• 調(diào)試令人痛苦——每個服務(wù)都會有自己的一組日志文件要審查。更多服務(wù)意味著更多的日志文件。

結(jié)束語

我在這里是要告訴你“別使用微服務(wù)”嗎？

絕對不是！！

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

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

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

作為技術(shù)倡導(dǎo)者和發(fā)燒友，你有權(quán)喜歡自己青睞的技術(shù)。但是讓你脫穎而出的是能夠在?“正確的選擇”與“你青睞的選擇”之間作出切合實際的選擇。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。