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

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

[[378266]]

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

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

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

那么，我們該如何避免這種誤區?

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

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

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

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

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

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

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

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

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