如今，微服務可謂是風靡一時。Forrester發(fā)布的一項研究發(fā)現(xiàn)，76%的企業(yè)正以微服務架構(gòu)為指導進行應用程序重構(gòu)。

但需要強調(diào)的是，微服務絕不是什么萬靈丹藥。在一項面向生產(chǎn)環(huán)境內(nèi)微服務應用的研究中，我們看到59%的受訪者表示每種微服務都會給數(shù)據(jù)管理等運營事務帶來新的挑戰(zhàn)。更令人擔憂的是，這份報告還提到在對不同環(huán)境內(nèi)的故障排查難度進行比較時，73%的受訪者表示微服務環(huán)境難度更大，只有21%的受訪者認為單體式架構(gòu)難度較大。

[[378266]]

但為什么會出現(xiàn)這樣的狀況?根據(jù)BCG Digital Ventures公司工程技術(shù)培訓副總裁Matthew Sinclair的解釋，這是因為技術(shù)專家們總是想用最現(xiàn)代的技術(shù)解決問題，即使他們對很多新興技術(shù)還沒有足夠的經(jīng)驗。“但作為工程師，我很理解其中的選擇思路。這么做不是因為更安全，而是因為能讓從業(yè)者學到更多新東西。”他說。

客戶們在聽說微服務這項新技術(shù)的消息之后，總覺得應該用新方法解決自身的整體問題。于是，他們熱衷于向軟件工程師介紹微服務架構(gòu)，調(diào)動起工程師們的積極性，之后就是在軟件工程項目中迅速添加大量微服務元素。

但問題在于，整個開發(fā)流程不可能一夜之間完成由單體式架構(gòu)到微服務架構(gòu)的轉(zhuǎn)換。換言之，企業(yè)在微服務遷移方面往往操之過急——一聽說其中的優(yōu)點、了解到部分收益，就想把它全面推向各個角落。正因為如此，一些企業(yè)開始不可避免地陷入微服務誤區(qū)。

那么，我們該如何避免這種誤區(qū)?

我們必須意識到，微服務架構(gòu)代表的是一種分布式系統(tǒng)，因此不妨以部分員工已經(jīng)具備經(jīng)驗的分布式思維進行設計。此外，千萬別忘了這樣一條黃金準則：如非必要，勿增實體。

換句話說，大家必須明確自己為什么要構(gòu)建某種事物、想要借此達成怎樣的目的。這是個最基本的問題，適用于任何規(guī)模的企業(yè)。打算解決什么問題、解決之后能夠給用戶帶來怎樣的收益，才是決定是否使用某種技術(shù)的根本前提。

用戶們其實也并不關(guān)心底層技術(shù)究竟是什么——他們不關(guān)心如何實現(xiàn)，只關(guān)心能不能解決問題。

如果唯一的實現(xiàn)方法就是微服務，那我們毫無疑問應該著手使用。但如果還有其他替代方法，請優(yōu)先考慮這些替代方法。千萬不要陷入“為了微服務而微服務”的怪圈。

總而言之，微服務是一種旨在降低復雜性的架構(gòu)模式。而一旦使用，它又會在其它層面增加復雜水平。如果孤立使用微服務，那么某一維度中得以解決的復雜性，必然會在某種形式擴散到其他領(lǐng)域。因此，最重要的是使用多種其他工具將組織的整體復雜性控制在最低程度。

這又回到了之前的拷問：我們要解決什么問題?如果大多數(shù)企業(yè)完全可以通過傳統(tǒng)且常規(guī)的技術(shù)搞定當前需求，那么無需選擇微服務。不要看到Amazon和谷歌等科技巨頭全面推行微服務，就躍躍欲試。請先問問自己，微服務對我們來說是不是正確的選擇。

也有不少企業(yè)掌握著重要的舊代碼庫，而且與業(yè)務體系嚴密集成。同樣的，微服務也許并不適合這種狀況。因此，盡量只在云原生項目中使用微服務，同時繼續(xù)沿用舊有技術(shù)處理傳統(tǒng)IT領(lǐng)域的挑戰(zhàn)。

一次又一次，我們總會回到最基本的考量：我們要用產(chǎn)品或技術(shù)解決什么問題?注意，不是如何解決，是解決什么。如果用戶與你的產(chǎn)品進行交互，可以獲得哪些收益?只有為這個問題找到明確的答案，大家才能判斷微服務架構(gòu)是否適合自己。

不過在多數(shù)情況下，各位得到的答案或許會是“可以，但沒必要。”