2023年最佳建議：不要建立微服務，追求低耦合

隨著2023年邁向尾聲,DevOps.com團隊特此精選年度最受歡迎的文章。以下是該系列的最新內容。

鑑於對可靠應用程式性能的需求與日俱增,因此許多公司在建置系統時便將未來擴展納入考量。許多業界專家指出,微服務是未來確保系統的最佳方式。但或許我們應該使用「適度服務」一詞,因為並非單一策略就能適用於每家公司的每個階段。團隊不應思考要採用哪種最新趨勢作為策略,而應該認知並專注於耦合度這個根本因素。如果系統內最容易發生變化的組件之間的耦合度較低,則系統就會更加靈活和動態。

在系統環境中,耦合是指系統組件之間的連接方式。鬆散耦合需要介面。對於電氣系統而言,這些介面是以實體連接器、銷和插座等形式實作,並以電壓等級描述協定。軟體系統對應的電氣連接器類比就是應用程式介面(API),可能是一組函數或基於HTTP的資源等。但僅有介面還不足以達到鬆散耦合,該介面也必須相當穩定,亦即使用者可以指望該介面長期存在,或至少其輸入會有可預期的變化。

為何鬆散耦合如此重要

當系統組件之間的耦合度較低時,這些組件內部的變更就不會對系統的其他部分造成重大影響。以日常生活中的燈泡為例:燈泡插座有標準尺寸、標準螺紋和標準電壓。燈泡本身經歷了從各種燈絲材料到LED的演進,但卻不需要改變燈具和燈座。再以軟體系統中的HTTP伺服器和資料儲存體(如快取、佇列或資料庫)為例,在大多數情況下,在伺服器和資料儲存體之間設置一個介面,可以輕鬆更改資料儲存體的實作。一旦這兩個組件只是鬆散耦合,未來最有可能發生變化的部分就可以改變,而不需要對其他部分進行重大修改。

如果系統的組件過於緊密交織,即使最小的變更也可能對系統的其他部分造成嚴重影響。您可以將這種結構比作一組在鄰近環境中生長的植物。由於所有莖都纏繞在一起,因此嘗試將其中一株植物換成新的將是一項挑戰,因為一個失誤就可能連根拔起許多其他植物。

相反地,在一個鬆散耦合的系統中,可以放心地進行變更,當一個組件出現問題時,系統的其他部分將保持彈性。這種信心帶來了更大的靈活性來進行變更、縮短新功能和產品的上市時間,並可能帶來競爭優勢。

鬆散耦合的附帶好處是可進化性:當介面位於最有可能發生變化的位置時,系統就更容易進化。介面的設計目的是要保持穩定和不透明,因此介面背後發生的任何事情對介面的使用者來說通常是未知且無關緊要的。因此,只要介面保持穩定,介面背後的系統就可以自由變更和進化。

對於小型專案而言,微服務可能會抵銷鬆散耦合的好處

雖然微服務策略確實支持鬆散耦合,但這並非唯一的方式。較簡單的架構策略可以讓較小或新興的專案以更可持續的方式獲得鬆散耦合的好處,而不會產生構建微服務導向基礎架構的額外開銷。

架構選擇不僅關乎技術考量(如可擴展性和效能),同時也與構建和操作軟體系統的人力組成有關。而在人力組成方面,微服務可能會略顯不足。

在設計系統時,應區分有意識的複雜性(即複雜的問題理應有複雜的解決方案)和無意識的複雜性(即過於複雜的解決方案帶來不必要的挑戰)。Netflix等公司確實從基於微服務的架構中獲益良多,但一家新興的初創公司並非Netflix,試圖追隨這家串流媒體巨頭的腳步可能會帶來大量無意識的複雜性。

微服務方法是一種管理系統複雜度的方式,一旦系統變得太大而難以安全處理。但在複雜度和開銷之間存在權衡取捨。管理多個服務需要大量開銷。如果過早採用微服務方法,員工可能會花費所有時間來支援支持服務的工具,而忽視了實際產品。

保持敏捷和快速前進的兩種方式

對於任何希望通過促進鬆散耦合來保持敏捷性,並且避免維護基於微服務的基礎架構的開銷來取得進展的團隊,至少有以下兩種選擇值得考慮。

第一種選擇是採用單體架構。雖然單體常被詬病為缺乏靈活性和過時,但經過適當規劃的單體可以支持鬆散耦合,並且所需的支援開銷遠低於微服務。關鍵在於構建一個基於代碼的介面,該介面可以將一個組件的輸入轉發給另一個組件。即使單體的一個組件發生變更,這種介面也可以將對其他組件的影響降至最低,系統就可以在存在介面的地方更容易進化。

第二種選擇是採用主要雲端供應商提供的無伺服器平台。這種方法在精神上更接近微服務,但開銷則由雲端供應商承擔。因此,無伺服器架構可以在最小化無意識複雜性的情況下獲得鬆散耦合的好處。

選擇最佳的鬆散耦合策略

即使您決定追求這兩種鬆散耦合策略之一,可能也不清楚應選擇哪一種。以下是一些可能幫助您確定是選擇單體或無伺服器雲端架構的因素:

• 成本。如果您沒有優化像AWS這樣提供者的資源利用率的經驗,或者低估了資源利用率,無伺服器架構可能會變得非常昂貴。
• 先前知識。單體將需要稍微多一點維護,因此更適合曾經使用過單體的公司。否則,無伺服器架構可能更有吸引力,因為提供者會處理大部分的維護工作。
• 流量模式。如果您系統的流量往往是突發性的,您可能會受益於使用無伺服器平台,它只會在需要時啟動。對於持續流量的使用案例,一直運行的單體可能更合適。
• 產品階段。如果您正在測試技術或市場可行性的假設,那麼無伺服器解決方案可以幫助您更快速、更少開銷地測試它們。無伺服器解決方案通常構建和配置快速,拆卸快速,而且它們避免了考慮基礎設施的需要,甚至比託管計算解決方案更進一步。

專注於”適當大小的服務”,而非”微服務”

目標不是到處去耦合,也不是讓一切都鬆散耦合。相反,它是通過策略性地選擇在哪裡以及多大程度上鬆散耦合組件,來使系統可演化。這是一場有教育意義的猜測和權衡的遊戲。沒有最佳方式,只有次佳方式。

當分析師和行業領導者談論”微服務”時,就好像它是軟體系統的萬靈丹一樣,這只適用於構建最成熟的系統並且有能力支援相關的開銷的團隊。”適當大小的服務”這個詞更好地傳達了,即使在一家公司內部,每個團隊也有不同的限制,因此實現鬆散耦合的方式也不盡相同。這可能需要使用微服務、單體、無伺服器平台或這些事物的混合;但無論如何,擁護鬆散耦合的團隊都更有能力應對挑戰、獲得競爭優勢並適應不斷變化的科技環境。