單體應用產生的痛苦,微服務並不能解決……

来源:https://www.cnblogs.com/88223100/archive/2023/01/23/Maybe-you-dont-need-microservices.html
-Advertisement-
Play Games

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


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

 

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

 

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

 

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

 

一、微服務的稻草人謬誤

 

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

 

在某種程度上,大多數好處(即使不是全部)都可以通過單體應用來實現。

 

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

 

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

 

關鍵詞是“購買”。

 

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

 

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

 

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

 

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

 

二、可擴展性

 

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

 

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

 

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

 

它們是否傾向於以不同的速度進行擴展?

 

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

 

1、擴大或者增加盒子

 

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

 

2、修複你的單體應用

 

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

 

3、將流量路由到可獨立擴展的集群

 

如果你有多個伺服器,你將在它前面運行某種負載均衡器。你可以使用此負載均衡器的配置將流量路由到你的應用程式實例的可獨立擴展的集群。

 

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

 

三、錯誤隔離

 

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

 

1、將流量路由到隔離集群

 

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

 

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

 

2、自動化測試

 

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

 

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

 

四、編程語言和技術的無關性

 

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

 

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

 

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

 

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

 

五、數據安全

 

你認為保護單體應用數據安全很難?微服務只會使這項工作變得更加複雜。通過增加技術棧的複雜性,你正在增加被攻擊的錶面積。

 

保護你的單體應用

 

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

 

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

 

你甚至對數據有不同的安全要求嗎?

 

六、團隊自治

 

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

 

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

 

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

 

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

 

1、模塊化你的單體

 

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

 

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

 

2、微服務並不能確保良好的模塊化

 

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

 

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

 

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

 

七、可獨立部署

 

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

 

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

 

分解複雜的變化

 

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

 

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

 

八、依賴管理

 

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

 

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

 

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

 

掌握依賴更新

 

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

 

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

 

九、更簡單、更容易理解代碼

 

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

 

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

 

模塊化你的單體

 

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

 

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

 

十、但是我們正在感受到單體應用帶來的痛苦

 

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

 

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

 

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

 

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

 

我不是來評判任何人的。

 

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

 

十一、我應該考慮微服務嗎?

 

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

 

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

 

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

 

你應該考慮微服務嗎?

 

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

 

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

 

十二、不相信我?問問周圍

 

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

 

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

 

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

 

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

 

十三、我的觀點

 

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

 

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

 

作者丨池劍鋒

本文來自博客園,作者:古道輕風,轉載請註明原文鏈接:https://www.cnblogs.com/88223100/p/Maybe-you-dont-need-microservices.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 這篇筆記咱日後應該還會進行補充。 關於sort的比較函數 STL的algorithm庫中的sort函數,可以接受一個cmp函數作為第三個參數,用來指定排序的規則。 自定義sort比較函數 cmp(a,b)函數的返回值是一個bool值,當返回值為true時不改變元素順序。 可以把其中的a看作序列中前一 ...
  • 2023-01-22 一、SpringMVC攔截器的兩種裝配方式 1、全局裝配(放置在springmvc.xml中) <!-- 裝配攔截器--> <!-- 全局裝配--> <mvc:interceptors> <ref bean="myInterceptor"></ref> </mvc:interc ...
  • 題目描述 牛牛從鍵盤上輸入三個整數,並嘗試在屏幕上顯示第二個整數。 輸入描述 一行輸入 3 個整數,用空格隔開。 輸出描述 請輸出第二個整數的值。 示例 1 輸入:1 2 3 輸出:2 解題思路 方案一 使用 3 個整形變數依次存儲輸入的 3 個整數,然後將第二個整形變數的數據輸出。 具體代碼如下: ...
  • 是否有小伙伴在使用tab的時候想進行滑動切換Tab? 並且有滑動左出左進,右出右進的效果 ,本文將講解怎麼在Blazor中去通過滑動切換Tab 本文中的UI組件使用的是MASA Blazor,您也可以是其他的UI框架,這個並不影響實際的運行效果,本文案例是相容PC和Android的,演示效果是and ...
  • eunomia-bpf 0.3.0 發佈:只需編寫內核態代碼,輕鬆構建、打包、發佈完整的 eBPF 應用 eunomia-bpf 簡介 eBPF 源於 BPF,本質上是處於內核中的一個高效與靈活的虛擬機組件,以一種安全的方式在許多內核 hook 點執行位元組碼,開發者可基於 eBPF 開發性能分析工具 ...
  • 寫在前面 在開發的過程中,大多數人都需要對代碼進行測試。目前對於c/c++項目,可以採用google的gtest框架,除此之外在github上搜索之後可以發現很多其他類似功能的項目。但把別人的輪子直接拿來用,終究比不過自己造一個同樣功能的輪子更有成就感。作為“linux環境編程”系列文章的第一篇,本 ...
  • ##視圖 ###什麼是視圖 視圖是一張虛表(建立在真實的table的基礎之上,即視圖的數據來源是對應的table). 首先需要創建一張表,在表的基礎上,指定的列映射成一個視圖. 就是一個SELECT查詢語句(過濾掉安全隱患列的數據),把它查到的數據作為視圖的數據進行映射 ###視圖的語法 ####視 ...
  • JavaScript 中的繼承可以通過多種方式來實現,如原型鏈繼承、借用構造函數繼承、組合繼承、ES6 Class繼承等。 ...
一周排行
    -Advertisement-
    Play Games
  • 一:背景 1. 講故事 年前遇到了好幾例托管堆被損壞的案例,有些運氣好一些,從被破壞的托管堆記憶體現場能觀測出大概是什麼問題,但更多的情況下是無法做出準確判斷的,原因就在於生成的dump是第二現場,借用之前文章的一張圖,大家可以理解一下。 為了幫助更多受此問題困擾的朋友,這篇來整理一下如何 快狠準 的 ...
  • 前言 .NET6 開始,.NET Croe API 項目取消了 Startup.cs 文件,在 Program.cs 文件的 Main 函數中完成服務的註冊和中間件管道的管理。但當我們項目引入更多包的時候,Program.cs 文件也會看起來很臃腫。 而且,我們不只會有一個後端項目,為了方便快速創建 ...
  • 目錄 背景 get 與 post 的區別 所有介面都用 post 請求? 背景 最近在逛知乎的時候發現一個有趣的問題:公司規定所有介面都用 post 請求,這是為什麼? 看到這個問題的時候其實我也挺有感觸的,因為我也曾經這樣問過我自己。在上上一家公司的時候接到一個項目是從零開始搭建一個微服務,當時就 ...
  • *以下內容為本人的學習筆記,如需要轉載,請聲明原文鏈接 微信公眾號「englyf」https://mp.weixin.qq.com/s/2GFLTstDC7w6u3fTJxflNA 本文大概 1685 個字,閱讀需花 6 分鐘內容不多, 但也花了一些精力如要交流, 歡迎關註我然後評論區留言 謝謝你的 ...
  • 在新版本的pandas中,上述代碼會引起警告,建議改成SQLAlchemy connectable(engine/connection),後續代碼將引入這種升級的連接方式。 ...
  • 幾乎所有的高級編程語言都有自己的垃圾回收機制,開發者不需要關註記憶體的申請與釋放,Python 也不例外。Python 官方團隊的文章 https://devguide.python.org/internals/garbage-collector 詳細介紹了 Python 中的垃圾回收演算法,本文是這篇 ...
  • 如果您想查找高於或低於平均值的數字,可以不必計算該平均值,就能查看更高或更低的值。通過Java應用程式,可以自動突出顯示這些數字。除了快速突出顯示高於或低於平均值的值外,您還可以查看高於或低於的值的個數。現在讓我們看看如何在 Java應用程式中實現此操作。 引入jar包 導入方法1: 手動引入。將  ...
  • 第一種方式:使用{} firstDict = {"name": "wang yuan wai ", "age" : 25} 說明:{}為創建一個空的字典對象 第二種方式:使用fromkeys()方法 second_dict = dict.fromkeys(("name", "age")) #valu ...
  • 在golang中可以使用a := b這種方式將b賦值給a,只有當b能進行深拷貝時a與b才不會互相影響,否則就需要進行更為複雜的深拷貝。 下麵就是Go賦值操作的一個說明: Go語言中所有賦值操作都是值傳遞,如果結構中不含指針,則直接賦值就是深度拷貝;如果結構中含有指針(包括自定義指針,以及切片,map ...
  • 本文結合京東監控埋點場景,對解決樣板代碼的技術選型方案進行分析,給出最終解決方案後,結合理論和實踐進一步展開。通過關註文中的技術分析過程和技術場景,讀者可收穫一種樣板代碼思想過程和解決思路,並對Java編譯器底層有初步瞭解。 ...