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

[[252215]]

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

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

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

什么是微服務

在工業(yè)級別，關(guān)于微服務基本特征的定義比較一致。

這些特征可以總結(jié)如下：

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

一個典型的微服務實現(xiàn)模式如下圖：

圖 1：典型的微服務實現(xiàn)模式

從上圖中我們可以看到：

• 微服務中的每組服務有自己的前端(由一個 API 和一個可選的 UI 組件組成)、一個實現(xiàn)自身服務領(lǐng)域邏輯的域?qū)右约蔼毩⒌臄?shù)據(jù)存儲。
• 前端復合。將所有前端組件(UI 組件或 API)組合成一致前端(復合 UI 或 API 網(wǎng)關(guān))。
• 一條事件總線，作為異步通信的骨干。

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

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

微服務的種種挑戰(zhàn)

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

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

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

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

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

2. 微服務引入復雜性

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

圖 2：成倍的增加了 API 的數(shù)量

微服務帶來的挑戰(zhàn)包括：

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

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

3. 微服務需要組織架構(gòu)發(fā)生轉(zhuǎn)變

微服務需要組織轉(zhuǎn)向自治的、跨職能的團隊。根據(jù)康威定律，這是至關(guān)重要的一步。

這意味著前端和后端開發(fā)人員、數(shù)據(jù)平臺工程師、QA、產(chǎn)品經(jīng)理和操作人員必須在一個團隊中互相合作。

圖 3：微服務需要組織架構(gòu)發(fā)生轉(zhuǎn)變

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

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

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

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

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

5. 微服務需要深入的技術(shù)棧

上面討論的這些技術(shù)挑戰(zhàn)意味著團隊的技術(shù)集需要更加全面的拓展。

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

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

1. 應用程序規(guī)模太小

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

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

圖 5：代碼行數(shù)與維護成本

2. 領(lǐng)域不明確

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

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

3. 組織不能做出改變

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

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

圖 6：傳統(tǒng)的組織形式來做微服務

由于不同的團隊有不同的優(yōu)先級，導致跨團隊的依賴關(guān)系環(huán)環(huán)相扣，造成延遲和沖突。

4. 缺乏理解

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

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

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

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

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

經(jīng)常失敗。早點失敗?？焖偈?。擁抱失敗是走向成功的一種方式。不要害怕失敗，要學會接受失敗。 ——Gary Burnison, CEO of Korn Ferry

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

5. 其他

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

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

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

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

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

圖 7：組件依賴

運行和調(diào)試的復雜性可能會降低開發(fā)的整體效率?？绶盏?Bug 調(diào)查和日志分析是非常復雜的。

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

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

應該如何抉擇?

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

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

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

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

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

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

容器和基礎(chǔ)結(jié)構(gòu)即代碼(IaS)可以與微服務架構(gòu)一起配合使用。事實上，它們往往更容易實現(xiàn)，因為網(wǎng)絡是直接的，配置的數(shù)量不那么重要。同時容器也能讓搭建和銷毀環(huán)境變得更加容易，并可以加速開發(fā)環(huán)境的部署。

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

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

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

關(guān)于作者，邱仁博，多年運營商商業(yè)分析、數(shù)據(jù)中心數(shù)據(jù)庫方向工作經(jīng)驗，現(xiàn)任職于某地市圖書館信息技術(shù)部。日常關(guān)注國內(nèi)外極客新聞、前后端技術(shù)。海外知識搬運工。

【51CTO原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為51CTO.com】