【51CTO.com原創稿件】在過去的四年中，使用微服務來構建應用程序似乎成了一種標準。大多數我所合作過的團隊也對此表現出了不同程度的興趣。

[[252215]]

微服務所承諾的彈性、高可用、低耦合、敏捷，以及能夠解決單體架構帶來的問題，這些都是它流行的主要原因。

但是近段時間來，對于微服務的一些保留意見和注意事項似乎引起了人們的注意。

在這篇文章中，我重點想討論的是微服務的應用，它的缺點是什么，以及在什么情況下應該慎重考慮使用微服務架構。

什么是微服務

在工業級別，關于微服務基本特征的定義比較一致。

這些特征可以總結如下：

• 微服務是一種應用于組件設計(服務如何分組)和部署架構(服務如何部署和通信)的模式。
• 微服務適用于創建具有“一定功能復雜性”的分布式應用程序。
• 各個服務必須小。
• 各個服務按功能劃分，實現關注點分離。
• 各個服務保持自治和相互解耦，可以獨立進行部署、版本控制和伸縮。
• 各個服務之間通過輕量級 API 和異步通道相結合的方式進行通信。
• 各個服務擁有獨立的狀態，并且只能通過服務本身來對其進行訪問。

一個典型的微服務實現模式如下圖：

圖 1：典型的微服務實現模式

從上圖中我們可以看到：

• 微服務中的每組服務有自己的前端(由一個 API 和一個可選的 UI 組件組成)、一個實現自身服務領域邏輯的域層以及獨立的數據存儲。
• 前端復合。將所有前端組件(UI 組件或 API)組合成一致前端(復合 UI 或 API 網關)。
• 一條事件總線，作為異步通信的骨干。

主要問題是，對于那些適用采用微服務架構的用例，人們對微服務的看法趨于一致。

這就是為什么我想采取相反的方法，并試圖說明在哪些情況下，微服務可能不是***選擇。

微服務的種種挑戰

程序員知道種種優勢，卻對代價一無所知。 —— Rich Hickey (Clojure設計者)

實現微服務需要權衡利弊。由于本文的重點不是抨擊微服務的缺陷，所以盡量簡明扼要。

1. 微服務很難被正確設計

這里有專門的一本書《Microservices AntiPatterns and Pitfalls》來記錄它的缺陷。它需要非常非常多的迭代來完成一個令人滿意的領域設計。

同時幾個基本的和結構化問題沒有直接的答案，往往需要調整和迭代，例如：如何水平切分關注點，如何共享數據以及以什么方式進行數據復制，如何管理報告，是否應該在服務中包括 UI 組件等。

2. 微服務引入復雜性

微服務引入了一定程度上的復雜性，這些復雜性已經被詳細地記錄下來，其中***的是“微服務——不是免費午餐”。

圖 2：成倍的增加了 API 的數量

微服務帶來的挑戰包括：

• 成倍的增加了 API 的數量。這使得變更代碼變得困難，并引入了版本控制的復雜性，增加了服務功能性分解的難度。
• 引入了網絡延遲。在組合服務時需要在可伸縮性和響應時間增加之間做出權衡。
• 鑒于 CAP 理論，處理橫跨多個服務的事務非常復雜。和擁有單一數據庫的單體架構不同，這些事務通常不是由基礎設施處理。
• 調試分布式系統是復雜的(參見“微服務—不是免費的午餐”)。異步系統、服務間鎖和競態條件中產生的錯誤很難進行定位和排除。

盡管這些復雜性通過技術手段都可以克服，但是這需要技術人員付出額外的精力，不能讓他們專注于實現那些更具價值的業務功能。

3. 微服務需要組織架構發生轉變

微服務需要組織轉向自治的、跨職能的團隊。根據康威定律，這是至關重要的一步。

這意味著前端和后端開發人員、數據平臺工程師、QA、產品經理和操作人員必須在一個團隊中互相合作。

圖 3：微服務需要組織架構發生轉變

這樣的組織運作起來非常平滑。這是因為大多數依賴關系都存在于團隊內部，而且由于優先級是相同的，因此都能夠快速解決。

4. 微服務需要過程和實踐的改變

微服務需要過程和實踐的改變。從偶爾發布幾個大版本，到經常發布許多小版本。

從手動的資源供給，到基礎設施即代碼等自動化形式的資源供給。微服務架構的成功依賴于組織和流程改變的能力，而這往往是最難的。

圖 4：微服務需要過程和實踐的改變

5. 微服務需要深入的技術棧

上面討論的這些技術挑戰意味著團隊的技術集需要更加全面的拓展。

團隊成員需要理解分布式系統、DevOps、基礎架構即代碼(IaC)、不同類型的數據庫、前端組件化和復合化、單元測試、全自動發布、迭代、小版本發布計劃、測試工具、多版本管理等等。

什么時候不應該使用微服務

1. 應用程序規模太小

應用程序規模太小不足以證明微服務的合理性。當然，這個應用在未來可能會出現增長，直到整個領域添加到其中。

在這種情況下，當接近 RoI 閾值時，使用微服務。同樣的道理也適用于那些小型團隊。

圖 5：代碼行數與維護成本

2. 領域不明確

領域不明確或不確定，使得領域模型不確定。比如，當產品被描述為“門戶”時、當你開始創業準備做一個應用時、當一個 CRM 系統要管理訂單甚至是有郵遞外送時，這種問題就會凸顯。

在這種情況下，單體結構要靈活得多。在晚上，當你獨自將 CRM 領域轉換成邏輯解決方案的時候，你可能會驚訝于利用 IDE 來進行重構所帶來的便利性以及單元測試套件帶來的安全感。

3. 組織不能做出改變

組織不能改變以適應微服務。它仍然包含一個數據組、一個前端組、一個后端組等等。

康韋定律有利于將服務組成一個分層的微服務體系結構。你可以將圖 1 與圖 6 進行比較。

圖 6：傳統的組織形式來做微服務

由于不同的團隊有不同的優先級，導致跨團隊的依賴關系環環相扣，造成延遲和沖突。

4. 缺乏理解

團隊缺乏對微服務概念、DDD 或概念設計的經驗和理解。雖然這可能算不上關鍵，但你應該仔細閱讀相關文檔并向有經驗的人尋求建議。

一個體系結構設計不良的的產物往往是一個高耦合的分布式“單體架構”系統，以及隨之而來的一切問題：網絡的通信性和延遲、復雜性、隱藏的依賴、部署時產生耦合等等。

我們大多數人都喜歡學習新事物，但并非所有人都喜歡，況且學習需要時間和精力。

有時候甚至要不斷地犯錯誤，包括大錯誤，然后才可能學到一些東西。甚至在某些情況下需要廢棄初始的版本，然后從頭開始。這些都是潛在的成本，必須要在做出決定之前考慮清楚。

管理層也需要盡早適應重構，在某些極端情況下甚至要接受從頭開始一個項目。

經常失敗。早點失敗。快速失敗。擁抱失敗是走向成功的一種方式。不要害怕失敗，要學會接受失敗。 ——Gary Burnison, CEO of Korn Ferry

接受失敗不是一件容易的事情，因為沉沒成本往往會錯誤指導你的下一步決策。

5. 其他

團隊不成熟，技術棧不適應微服務或者人員流動率高。因為系統的無序性(熵)會隨著時間的推移而不斷增大，代碼的維護性也會隨著時間的推移而下降。

而且由于一個更復雜的系統更難維護，這可能會加劇第 3.4 帶來的問題。

困惑和壓力往往會讓人們退回到他們所熟悉的圈子。他們會“抄近路”把東西弄出來，或者走捷徑來規避復雜性。

很快，這樣產生的軟件架構可能會被污染到技術組件、“核心”庫、服務與服務之間的引用、編排器甚至“CSV 導入服務”，然后這些服務開始進入彼此的數據庫。

接下來，有人會問“我們應該如何編排部署以管理服務之間的依賴關系?”這無異于是軟件版本的地獄，這種系統也被稱為分布式“單體架構”。

圖 7：組件依賴

運行和調試的復雜性可能會降低開發的整體效率。跨服務的 Bug 調查和日志分析是非常復雜的。

這會帶來一個問題，那就是這些工作只能交給那些團隊中技術經驗更加豐富的成員。

但是這些成員的關注點應該是如何保持系統長期穩定運行，而不是救火。簡而言之，在這種情況下，微服務不但沒有帶來優勢，反而會讓整個團隊為消極結果買單。

應該如何抉擇?

所有軟件系統都可以分解為兩個主要元素：策略和細節。策略元素包含所有業務規則和過程。策略是系統的真正價值所在。 而細節是使人類、其他系統和程序員能夠與策略進行通信的必備基礎，但是這些細節都不會影響策略的行為。細節包括 IO 設備、數據庫、Web 系統、服務器、框架、通信協議等等。 架構師的目標是為系統創建一個外形。這個外形將策略看做是系統中最重要的元素，同時做到細節與策略無關。這使得有關細節的決策可以延遲和推后。 —— Robert C. Martin, Clean Architecture

如果您正在構建的應用程序有一個相當清晰的領域，未來會演進到一個相當的規模，在項目開始就會配置大型的團隊，并且你對團隊的技術有信心，你在分布式設計方面有一些經驗或者至少有一些素養，同時又能獲得管理層方面對于失敗和學習的支持和容忍，那么微服務會是一個很好的選擇。

但是要注意有時布局候微服務可能會適得其反。如果你所處的場景與前面的描述相類似，那么使用一些更簡單的架構作為開始可能更加明智。

比如一個單體架構或者一個分層架構(本身可能包含一些專門的服務)。大部分微服務架構能夠解決的問題，其他方案也能解決。

低耦合、可伸縮性和前瞻性的系統來自于精心設計的應用程序架構。這種架構往往具有明確定義的邊界和專門的數據存儲。

微服務只能通過提供物理限制來滿足這種場景。另一種創建物理限制的方法是通過組件(DLL、JAR)。組件架構和部署架構的選擇應該盡可能的慎重。

容器和基礎結構即代碼(IaS)可以與微服務架構一起配合使用。事實上，它們往往更容易實現，因為網絡是直接的，配置的數量不那么重要。同時容器也能讓搭建和銷毀環境變得更加容易，并可以加速開發環境的部署。

構建自動化和頻繁發布可以通過增加關注點和減少在制品(Reduced WIP)、小批量(Small Batches)、原子化更改流(Atomic Change Flow)和減少協作來實現。

對于復雜的分布式系統，微服務無疑是一個很好的選擇。但微服務并不是唯一的選擇，對于微服務的訴求往往會促使人們做出采用它們的決定，而忽略了它帶來的種種問題。

一個人應該考慮各種選擇，進而做出一個有意識的、有素養的、理性的選擇。

關于作者，邱仁博，多年運營商商業分析、數據中心數據庫方向工作經驗，現任職于某地市圖書館信息技術部。日常關注國內外極客新聞、前后端技術。海外知識搬運工。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】