住手!!你不需要微服务!
作者: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)槲⒚搿O胂笠幌?#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)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 单列索引和联合索引,有什么区别?
- 下一篇: 面试官:线程顺序执行,这么多答案你都答不