在過去的四年中，使用微服務來構建應用程序似乎成了一種標準。大多數我所合作過的團隊也對此表現出了不同程度的興趣。
微服務所承諾的彈性、高可用、低耦合、敏捷，以及能夠解決單體架構帶來的問題，這些都是它流行的主要原因。
但是近段時間來，對於微服務的一些保留意見和注意事項似乎引起了人們的注意。
在這篇文章中，我重點想討論的是微服務的應用，它的缺點是什麼，以及在什麼情況下應該慎重考慮使用微服務架構。
什麼是微服務
在工業級別，關於微服務基本特徵的定義比較一致。
這些特徵可以總結如下：
微服務是一種應用於組件設計(服務如何分組)和部署架構(服務如何部署和通信)的模式。 微服務適用於創建具有“一定功能複雜性”的分佈式應用程序。 各個服務必須小。 各個服務按功能劃分，實現關注點分離。 各個服務保持自治和相互解耦，可以獨立進行部署、版本控制和伸縮。 各個服務之間通過輕量級 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)和減少協作來實現。
對於複雜的分佈式系統，微服務無疑是一個很好的選擇。但微服務並不是唯一的選擇，對於微服務的訴求往往會促使人們做出採用它們的決定，而忽略了它帶來的種種問題。
一個人應該考慮各種選擇，進而做出一個有意識的、有素養的、理性的選擇。
轉自 https://zhuanlan.zhihu.com/p/59046813