微服務(wù)的這些坑不能碰
如今，微服務(wù)可謂是風(fēng)靡一時。Forrester發(fā)布的一項研究發(fā)現(xiàn)，76%的企業(yè)正以微服務(wù)架構(gòu)為指導(dǎo)進行應(yīng)用程序重構(gòu)。
但需要強調(diào)的是，微服務(wù)絕不是什么萬靈丹藥。在一項面向生產(chǎn)環(huán)境內(nèi)微服務(wù)應(yīng)用的研究中，我們看到59%的受訪者表示每種微服務(wù)都會給數(shù)據(jù)管理等運營事務(wù)帶來新的挑戰(zhàn)。更令人擔(dān)憂的是，這份報告還提到在對不同環(huán)境內(nèi)的故障排查難度進行比較時，73%的受訪者表示微服務(wù)環(huán)境難度更大，只有21%的受訪者認為單體式架構(gòu)難度較大。
但為什么會出現(xiàn)這樣的狀況？根據(jù)BCG Digital Ventures公司工程技術(shù)培訓(xùn)副總裁Matthew Sinclair的解釋，這是因為技術(shù)專家們總是想用最現(xiàn)代的技術(shù)解決問題，即使他們對很多新興技術(shù)還沒有足夠的經(jīng)驗。“但作為工程師，我很理解其中的選擇思路。這么做不是因為更安全，而是因為能讓從業(yè)者學(xué)到更多新東西。”他說。
客戶們在聽說微服務(wù)這項新技術(shù)的消息之后，總覺得應(yīng)該用新方法解決自身的整體問題。于是，他們熱衷于向軟件工程師介紹微服務(wù)架構(gòu)，調(diào)動起工程師們的積極性，之后就是在軟件工程項目中迅速添加大量微服務(wù)元素。
但問題在于，整個開發(fā)流程不可能一夜之間完成由單體式架構(gòu)到微服務(wù)架構(gòu)的轉(zhuǎn)換。換言之，企業(yè)在微服務(wù)遷移方面往往操之過急——一聽說其中的優(yōu)點、了解到部分收益，就想把它全面推向各個角落。正因為如此，一些企業(yè)開始不可避免地陷入微服務(wù)誤區(qū)。
那么，我們該如何避免這種誤區(qū)？
我們必須意識到，微服務(wù)架構(gòu)代表的是一種分布式系統(tǒng)，因此不妨以部分員工已經(jīng)具備經(jīng)驗的分布式思維進行設(shè)計。此外，千萬別忘了這樣一條黃金準(zhǔn)則：如非必要，勿增實體。
換句話說，大家必須明確自己為什么要構(gòu)建某種事物、想要借此達成怎樣的目的。這是個最基本的問題，適用于任何規(guī)模的企業(yè)。打算解決什么問題、解決之后能夠給用戶帶來怎樣的收益，才是決定是否使用某種技術(shù)的根本前提。
用戶們其實也并不關(guān)心底層技術(shù)究竟是什么——他們不關(guān)心如何實現(xiàn)，只關(guān)心能不能解決問題。
如果唯一的實現(xiàn)方法就是微服務(wù)，那我們毫無疑問應(yīng)該著手使用。但如果還有其他替代方法，請優(yōu)先考慮這些替代方法。千萬不要陷入“為了微服務(wù)而微服務(wù)”的怪圈。
總而言之，微服務(wù)是一種旨在降低復(fù)雜性的架構(gòu)模式。而一旦使用，它又會在其它層面增加復(fù)雜水平。如果孤立使用微服務(wù)，那么某一維度中得以解決的復(fù)雜性，必然會在某種形式擴散到其他領(lǐng)域。因此，最重要的是使用多種其他工具將組織的整體復(fù)雜性控制在最低程度。
這又回到了之前的拷問：我們要解決什么問題？如果大多數(shù)企業(yè)完全可以通過傳統(tǒng)且常規(guī)的技術(shù)搞定當(dāng)前需求，那么無需選擇微服務(wù)。不要看到Amazon和谷歌等科技巨頭全面推行微服務(wù)，就躍躍欲試。請先問問自己，微服務(wù)對我們來說是不是正確的選擇。
也有不少企業(yè)掌握著重要的舊代碼庫，而且與業(yè)務(wù)體系嚴密集成。同樣的，微服務(wù)也許并不適合這種狀況。因此，盡量只在云原生項目中使用微服務(wù)，同時繼續(xù)沿用舊有技術(shù)處理傳統(tǒng)IT領(lǐng)域的挑戰(zhàn)。
一次又一次，我們總會回到最基本的考量：我們要用產(chǎn)品或技術(shù)解決什么問題？注意，不是如何解決，是解決什么。如果用戶與你的產(chǎn)品進行交互，可以獲得哪些收益？只有為這個問題找到明確的答案，大家才能判斷微服務(wù)架構(gòu)是否適合自己。
不過在多數(shù)情況下，各位得到的答案或許會是“可以，但沒必要。”
