你不需要微服務

本文作者透過分析微服務的常見優點能解決的問題，提出如何使用單體應用來緩解這些問題，最終指出採用微服務還是單體架構要根據團隊實際情況，而不是為了微服務而微服務。作者最後給出建議，中小團隊和新型團隊，建議採用單體架構，大中型團隊，可以採用微服務架構，但要充分權衡。

在 Web 軟體架構方面，微服務架構非常流行，它有大量高知名度的實踐者和支持者，如Facebook、Uber、Groupon、Klarna、Amazon、Netflix、eBay、Comcast等。

但是，你很可能不屬於這些公司。也就是說，你的團隊很可能與這些公司的團隊不一樣，你沒有面臨與他們相同的問題。

當然，如果你恰好就屬於這些公司（但極大可能你不是），請停止閱讀。你們可能就是需要微服務的。

微服務據說有許多好處，我們的關注點不在於微服務是否真能提供這些好處，而在於這些好處是否只能由微服務提供。

在某種程度上，大多數好處（即使不是全部）都可以透過單體應用來實現。

當有人列出微服務架構的優點時，潛臺詞是為了解決這些問題，你必須採用微服務模型。

現實情況是，微服務允許你“購買”間接層和靈活度來解決這些問題。

關鍵詞是“購買”。

微服務不是免費的，眾所周知，它們的構造和維護成本很高。

如果你確實需要那層額外的靈活性，那麼總的來說，額外的成本會得到回報，微服務比較適合，你應該認真考慮它們。

但是如果你不需要呢？你只是過度設計了你的技術棧，並嚴重阻礙了你的團隊為客戶提供價值的能力。

讓我們看看微服務最常被提到的一些好處，並考慮如何使用單體應用來緩解這些問題。

執行微服務意味著應用程式的每個功能都在自己的資源上執行，這些資源可以相互獨立地進行擴充套件，這將使你能夠對分配給這些功能的確切資源數量和型別進行高度控制。

但是你真的需要這種程度的控制嗎？

你的應用程式的不同功能是否真的會經歷不同級別的負載？

它們是否傾向於以不同的速度進行擴充套件？

它們在 CPU、記憶體、儲存和 GPU 方面是否有不同的要求？

擴大或者增加盒子

對於很多團隊來說，透過簡單地增加全面可用的盒子的大小或數量來彌補這些資源問題的差異會更便宜。也就是說，大多數情況下，不將基礎設施最佳化到其生命週期的一英寸以內會更具成本效益。

修復你的單體應用

解決單體架構中的效能問題和瓶頸可能比過渡到新的架構模式更容易。這方面的細節是和技術棧強相關的，但是你不必走得太遠就可以找到有關如何收緊應用程式的想法。

將流量路由到可獨立擴充套件的叢集

如果你有多個伺服器，你將在它前面執行某種負載均衡器。你可以使用此負載均衡器的配置將流量路由到你的應用程式例項的可獨立擴充套件的叢集。

你還可以將非同步任務拉入具有獨立可擴充套件佇列的後臺作業中。請確保你有足夠的佇列，以便你能對所需的盒子數進行細粒度控制，保持合理的基礎設施成本。

應用程式的單個功能下架，同時不影響其他功能，這是那些設計合理的微服務架構的一大好處。

將流量路由到隔離叢集

將不同型別的流量路由到叢集以進行擴充套件的想法也可以提供一種針對故障的保護措施。

想想你的大部分歷史錯誤來自哪裡，這將為你提供有關如何最好地路由你的流量的指示。如果你正和“吵鬧的鄰居（noisy neighbors）”作鬥爭，你可能希望根據帳戶 ID 進行路由。如果你有一個脆弱但次要的功能，它習慣於將所有內容都關閉，則可以將其端點路由到它自己的應用程式例項叢集。如果你有有問題的後臺作業，請將它們放在不影響其他作業的自己的佇列中。

自動化測試

預防勝於治療。如果你可以防止或至少可以減少故障數量，你可大幅減少隔離的計劃。

培養健康的測試文化以確保對所上線產品的質量充滿信心是關鍵，它不僅能可靠地提供所需的功能，也能在生產負載下這樣做。

如果沒有單獨的服務，引入新語言和技術的選擇並不多。

在大多數情況下，這更像是一個功能而不是一個錯誤。在選擇語言和技術時，給工程師太多選擇可能會導致技術棧支離破碎且過於複雜。

我更傾向於單體架構帶來的簡單性和一致性。

如果你確實對針對特定功能的專業語言有特定領域的要求，你可能需要考慮單獨的服務。你將需要權衡任何額外技術帶來的好處與維護它的額外成本。

你認為保護單體應用資料安全很難？微服務只會使這項工作變得更加複雜。透過增加技術棧的複雜性，你正在增加被攻擊的表面積。

保護你的單體應用

確實，將功能隔離到不同的服務中可以讓你對每個服務應用不同級別的安全性和盡職調查。但是，請考慮是否需要這種級別的控制。

將整個單體應用程式保護到必要的最高階別是否更容易？

你甚至對資料有不同的安全要求嗎？

我是自主跨職能團隊的忠實粉絲。我對必須引入網路邊界來實現這一點的想法從何而來感到有些困惑。

賦予每個團隊對特定隔離系統的所有權似乎是提高團隊自主性的一種方式，但實際上，它可能會與之背道而馳。

假設我的團隊需要更改另一個團隊擁有的功能。對於微服務架構，我可能不得不利用他們對該服務的知識和經驗來對其進行更改。我甚至可能不得不等待他們來改。如果該功能在單體應用中，我很有可能已經熟悉程式碼或至少熟悉它的約定。

團隊的自主程度取決於模組化程度和系統的一致性。無論是單體應用還是微服務都不會在這些方面保證或毀滅你。然而，微服務將迫使你的系統模組化，而單體應用往往會鼓勵更高的一致性。

模組化你的單體

就其本質而言，微服務將迫使你對系統進行模組化。單體應用在這裡並沒有真正提供太多幫助（儘管你選擇的單體應用框架可能會），但它們當然也不會妨礙你自己做這件事。

具有有限關注點的松耦合模組化程式碼是一個好主意，無論你是否碰巧在這些關注點之間增加了網路邊界的複雜性。

微服務並不能確保良好的模組化

儘管微服務強制執行模組化，但不能保證它是良好的模組化。如果沒有充分考慮設計，微服務很容易成為緊密耦合的“分散式單體”。

如果你不能成功地模組化一個單體，你將很難構建一個成功的微服務架構。

微服務強制模組化，但使得做好模組化變得更難。

在能夠獨立部署服務的情況下，你可能會進行許多更改。但是為了你的麵包和黃油，你的日常更改，可能會成為一個棘手的瓶頸。

跨不同服務編排大量部署的要求將使快速釋出功能變得更加困難和複雜。

分解複雜的變化

使用單體架構，仍然可以將複雜的、有風險的更改分解為單獨的部署。一個常見的例子是讓他們自己的 PR 和他們自己的部署向前和向後相容。

這種方式和微服務一樣，增加了交付功能的複雜性。你不會想輕率地使用它。但它確實提供了微服務的一些好處，而不必被迫在每次更改時都使用它。

微服務允許你為每個服務配置單獨的依賴項，但你真的需要它們嗎？

在大型單體應用中管理依賴關係已經夠難的了。將其拆分為幾個較小的列表可以簡化管理每個單獨的列表，但會使整個系統的操作變得複雜。

對於單體應用，遲早你會陷入“依賴地獄”，並在兩個依賴項之間產生衝突。微服務不會確保你避免這種情況，但它們應該會降低出現問題的可能性。

掌握依賴更新

使你的依賴關係保持最新顯然是可取的。但在現實世界中，是否變成最新要由我們來控制。

保持在可用版本的最前沿實際上可能會使這個問題複雜化，因為一個依賴項比其他相關依賴項更快地向前發展。但“保持領先”並不一定意味著在所有可能的情況下都更新到最新版本。

這種好處往好了說是虛偽，往差了說，這是一個赤裸裸的謊言。

確實，每個服務都更簡單，也更容易理解。但是，整個系統變得更復雜，也更難理解。你還沒有消除複雜性；你增加了它，然後將它移植到其他地方。

模組化你的單體

我們不需要引入網路邊界和隔離程式來使我們的程式碼更容易被工程師理解。

將單體分解為具有明確定義和有限關注點的模組，與分解為單獨服務的系統一樣容易，甚至更容易理解。

如果你遇到單體應用問題，可能是因為你的單體應用存在問題，而不是因為它是單體應用。

你的單體應用可能是程式碼質量、工具和模組化的閃亮燈塔。如果這就是你並且你仍然在經歷痛苦，那麼可能是時候開始考慮微服務了。但這可能不是你。你可能只需要改進你的單體。

構建軟體很難。組織具有大量隨時間演變的移動部件的大型複雜系統非常困難。

我自己就已經構建了一個糟糕的單體應用。

我不是來評判任何人的。

但是，如果你假設你面臨的單體應用問題將透過微服務神奇地解決，甚至簡化，那麼你將進入一個痛苦的世界。

單體和微服務之間的選擇通常表現為兩種相互排斥的思維模式。老學校與新學校，對或者錯，非此即彼。

事實上，它們都是具有不同權衡的有效方法。正確的選擇是高度特定於上下文的，並且必須包括廣泛的考慮因素。

選擇本身就是一種錯誤的二分法，在某些情況下，應該逐個功能地做出選擇，而不是針對整個組織的工程團隊採用單一方法。

你應該考慮微服務嗎？

通常這得看實際情況。你可能會真正受益於微服務架構，在某些情況下收益是大於支出的，但如果你是中小型團隊或早期專案：

不，你可能不需要微服務。

詢問整個行業，你會發現無數關於微服務及其給團隊帶來問題的警示故事。

Segment 是一個有據可查且備受矚目的團隊示例，該示例已完全啟用微服務。

這同樣適用於作為單體的微服務。僅僅因為它們在執行中存在問題並不意味著核心前提存在根本缺陷。

但是，如果你打算採用微服務方法，則需要睜大眼睛進入。接受權衡，併為成功完成所需的額外資源做好準備。

對於新的、小型和中型的工程團隊來說，單體應用應該仍然是預設選擇。微服務仍然是一種選擇，但你應該有令人信服的特定於上下文的理由來證明它們的使用是合理的。

對於大中型團隊，應該考慮它，但要對你的權衡有充分的考慮和理解。