作者 | Tomasz Nurkiewicz

譯者 | 李騰輝

策劃 | 信遠

微服務不能“包治百病”。

時下微服務是一個不錯的架構，它具備模塊化、可伸縮和高容錯這些優點。許多公司都采用微服務架構并取得了巨大的成功，自然而然地，如果你正開始一個新項目，微服務似乎是最佳選擇。

然而，大多數采用微服務取得成功的公司并不是一開始就選擇了這種架構。以Airbnb和Twitter為例，他們在單體應用過于龐大之后才選擇了微服務路線，現在也仍在解決由此帶來的復雜性。即使是大公司也仍在尋找使用微服務的最佳方法。所以說，微服務是一把雙刃劍，需要權衡利弊。

從單體應用遷移到微服務也絕不是一項簡單任務，未經過測驗，便采用微服務構建一個新產品則更加復雜。只有在充分評估了替代方案之后，才應該認真考慮是否使用微服務架構。

一、 微服務僅適用于成熟產品 

關于從頭開始使用微服務，馬丁·福勒（Martin Fowler）總結道：

1.幾乎所有成功的微服務都是從一個過于龐大而不得不拆分的單體應用開始的。

2.幾乎所有從頭開始以微服務構建的系統，最后都會因嚴重的問題而失敗。這種情況導致許多人認為，就算你確信你的應用將快速發展壯大，也不應該一開始便采用微服務。

初版設計很難優化得很好，新產品的前幾次迭代重點在于尋找用戶的真正痛點。因此，成功取決于保持敏捷并能快速優化和重構。在這方面，微服務就比單體應用差得多。如果你沒有把握設計好最初的方案，就采用了微服務，那么你的啟程之路將更加困難，因為重構微服務比重構單體應用要困難得多。

二、你是否在初創公司或者開發全新項目？ 

作為一家初創公司，你已經在爭分奪秒，在未知的噩耗來臨之前努力尋找突破口。此時你不太需要關注擴展性（可能幾年之內都不需要），那么為什么要使用復雜的架構而忽視客戶的需求呢？

在開發全新項目時也有類似的情況，這些項目不受前期工作的限制，更沒有任何決策包袱。《構建微服務：設計細粒度的系統》一書的作者山姆·紐曼（Sam Newman）表示，用微服務構建一個全新的項目非常困難：

我仍然堅信，對現有的舊系統進行劃分要比在全新的系統容易得多。你有更多可供幫助的資源，比如你有可供查閱的代碼，你可以與使用和維護系統的人員交流討論，你也知道一個“好”的系統是什么樣的——基于當前穩定運作的系統進行改變，讓你更容易知道你在哪里做錯了，你的決策是否過于激進。

三、微服務不是本地部署的最佳選擇

由于所有部件都是動態變化的，微服務部署需要搭配更強大的自動化機制。在常規環境下，我們可以依靠持續部署管道（continuous deployment pipelines）來完成工作——任務開發者部署微服務，消費端盡管使用線上服務就可以了。

然而這并不適用于本地環境，如果開發者發布一個包，需要消費端自行在其本地環境上部署和配置其他的服務，這使得部署變得更具挑戰性。

確切的說，開發本地微服務應用也是可行的，正如Semaphore（一個CI/CD平臺）也提供了本地化部署模式。然而，在這個過程中我們需要克服幾個挑戰：

1.本地微服務的版本控制規則需要更加嚴格，你必須跟蹤參與發布的每個單獨的微服務。

2.你必須進行完整的集成和端到端測試，因為你無法在生產環境中進行測試。

3.如果不能直接訪問生產環境，對微服務應用進行故障排查會困難得多。

四、你的單體應用也許還能用 

每個軟件都有自己的生命周期。你可能想廢棄一個單體應用，因為它很舊并且很復雜。但折騰一個系統也許費力不討好，如果稍加努力，你也許可以榨出當前系統的更多價值，讓他多用幾年。

只有在這兩種情況下，微服務重構才是不得不做的選擇：

1.代碼混亂：在不破壞其他功能的情況下，很難在原代碼基礎上進行更改和添加新功能

2.性能因素：你在擴展單體應用時遇到了瓶頸

五、模塊化單體 

開發人員想要避免采用單體架構的一個常見原因是，單體更容易變成一坨“代碼屎山”。那時很難再添加新功能，因為一切都是相互關聯的。

但是單體不一定是一團糟。以Shopify為例：他的代碼行數超過300萬行，是世界上最大的Rails單體應用之一。但有一點，系統過于龐大會給開發人員帶來許多痛苦：

應用非常脆弱，新的代碼會產生許多意想不到的影響。作出一些更改可能會引發一連串無關的測試用例失敗。例如，計算運費和計算稅率復用了一些代碼，那么更改計算稅率代碼的同時可能會影響運費計算的結果。這是高耦合和缺乏邊界的結果，也導致測試用例難以編寫，并且在CI上運行得非常緩慢。

Shopify沒有選擇將整個單體應用重寫為微服務，而是選擇了模塊化作為解決方案。

模塊化有助于設計更好的單體或者微服務。如果沒有認真地定義好模塊，我們要么陷入傳統的分層式單體（大泥球），或者更差的結果，成了分布式單體應用，它同時具備單體和微服務兩者的缺點。

模塊化的工作量很大，但它也帶來了巨大的價值，使開發可以更加直接。新開發人員在開始變更代碼之前不必了解整個應用，一次只需要熟悉一個模塊。良好的模塊化可以使一個大單體更好上手。

模塊化是切換到微服務之前的必要步驟，并且有可能是更好的解決方案。與微服務類似，模塊化單體應用通過將代碼拆分為一些獨立的模塊來解決代碼耦合的問題。與微服務通過網絡進行通信不同，單體應用中的模塊通過內部API調用進行通信。

分層式單體對比模塊化單體，模塊化單體具有微服務的許多特征，卻沒有微服務面臨的諸多挑戰。

六、單體應用也能擴展 

另一個關于單體應用的誤解是它們無法擴展。如果你遇到性能問題并認為微服務是唯一的出路，可以參考Shopify的案例，在音頻領域Shopify已經在超大規模上構建了一個可靠的單體應用。

架構和技術棧將決定如何優化單體應用，在做好模塊化劃分之后，可以利用云原生技術進行擴展：

1.部署單體應用的多個實例，并使用負載均衡器來分配流量

2.使用CDN分發靜態資源和前端代碼

3.使用緩存來減少數據庫負載

4.使用邊緣計算（edge computing）或者無服務調用（serverless function）來實現高需求功能

七、如果系統可高效工作，不要輕易嘗試改變

如果我們將生產力衡量標準定義為每時間單位實現了多少個有價值的功能，那么在生產力值很高時，切換架構幾乎沒有意義。

由于維護開銷較大，微服務最初是生產力較低的架構，隨著單體的增長，系統變得更加復雜，并且更難添加新功能。微服務只有在交叉點之后才會獲得更高的生產力。

誠然，有些事情最終還是要做，但那可能是幾年后才考慮的事。到那時，需求可能已經發生改變——誰知道那時候是否還會出現新的架構模型呢？

八、布魯克斯定律和開發人員生產力 

在《人月神話（The Mythical Man Month)》一書中，弗雷德里克·布魯克斯（Frederick P. Brooks, Jr.）曾說：“在軟件項目后期增加人力，會讓交付時間更晚”。發生這種事是因為必須先對新人員進行指導，然后才能在復雜的代碼上進行開發。此外，隨著團隊的壯大，溝通成本也會增加，使得組織決策更加困難。

在大型軟件開發時，布魯克斯定律指出，在軟件項目后期增加人力只會讓花費的時間更長。微服務是減少定律影響的一種方法。然而，這種效果只能在復雜而龐大的代碼庫中才能體現，因為在這種情況下，我們無法將開發劃分為各自獨立的任務。

在使用微服務之前，你必須考慮布你的單體應用是否正在被魯克斯定律所影響。過早地切換到微服務不會增加更多的價值。

九、你準備好進行切換了嗎？ 

在開始切換微服務之前，除了準備好你的單體之外，你還必須滿足以下條件：

1.為自動化部署設置好持續集成和持續部署（CI/CD)

2.實現快速配置以便按需構建基礎架構

3.了解云原生技術棧，包括容器化、K8S、無服務

4.熟悉領域驅動設計（DDD, Domain-Driven Design)，測試驅動開發（Test-Driven Development)，行為驅動開發（Behavior-Driven Development)

5.團隊重組，以便跨職能溝通消除信息孤島，采用扁平化管理以激發創新

6.培養DevOps文化，使開發人員和運維工作得更加契合

改變組織的文化可能需要數年時間，學習所有的必備知識也許需要數月時間，如果沒有做好準備，切換到微服務是注定無法成功的。

十、總結 

我們可以用一句話總結上面關于切換到微服務的討論：除非你有充分的理由，否則不要輕易去做。那些毫無準備、沒有可靠設計就使用微服務的公司，都將經歷一段非常艱難的時期。你需要建設好技術文化氛圍，做好技術儲備，再去考慮微服務。

同時，如果你的系統運行良好并且仍在以預期的速度進行開發，那么為什么要急于改變呢？

最后感謝你閱讀本文，祝你編碼愉快！

原文鏈接：

https://dzone.com/articles/when-microservices-are-a-bad-idea

譯者介紹

李騰輝，51CTO社區編輯，目前在一家東南亞互聯網金融獨角獸擔任資深Java工程師，負責金融借貸平臺架構設計及核心建設工作，對互聯網金融架構、微服務體系有較深入的研究，期望在互金領域持續深耕。