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

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

[[378266]]

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

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

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

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

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

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

用戶們其實也并不關心底層技術究竟是什么——他們不關心如何實現，只關心能不能解決問題。

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

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

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

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

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

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