微服務架構簡介與實務應用

– 16 分鐘閱讀

隨著應用程式規模和複雜度提升，傳統單體式架構逐漸顯露出瓶頸，微服務架構則提供更佳的解決方案。它將應用程式拆分成多個獨立微服務，各自負責特定功能，並透過 API 進行通訊。此架構提升了系統彈性、可擴充套件性和可維護性，更易於持續交付和 DevOps 文化的實踐。然而，微服務架構也帶來新的挑戰，例如程式間通訊的複雜度、分散式系統的監控與管理，以及服務發現的機制等。本文將探討這些議題，並提供實務上的解決方案。

微服務架構的簡介與優勢

在軟體開發領域中，隨著應用程式的規模和複雜度不斷增加，傳統的單體式架構（Monolithic Architecture）逐漸暴露出諸多問題，例如效能瓶頸、可擴充套件性不足、測試和佈署困難等。為瞭解決這些挑戰，微服務架構（Microservices Architecture）應運而生。

單體式架構的挑戰

在單體式架構中，所有功能模組都集中在一個應用程式中，這種架構在初期可能運作良好，但隨著應用程式的成長，會出現以下問題：

  • 效能問題
  • 可擴充套件性不足
  • 迴歸測試週期變長
  • 升級和重新佈署困難
  • 無法佈署小規模的修復和增強功能
  • 計劃外的停機時間
  • 升級期間的潛在停機時間
  • 被鎖定在現有的技術和程式語言中
  • 無法擴充套件特定的元件或功能

這些挑戰不僅影響了應用程式的效能，也對開發團隊造成了挫折感，進而導致人員流失率增加。

微服務架構的優勢

微服務架構透過將單體式應用程式分解為多個獨立的微服務，每個微服務負責一個特定的功能，從而解決了單體式架構的許多問題。這種架構具有以下優勢：

模組化架構

透過將應用程式分解為多個微服務，我們可以獲得模組化的架構，這種架構可以提高應用程式的可維護性和可擴充套件性。

簡潔性

每個微服務只負責一個特定的功能，因此程式碼量較少，內聚性和依賴性降低，錯誤的機率也降低了。

可擴充套件性

在微服務架構中，我們可以只擴充套件需要高負載的元件，而不需要擴充套件整個應用程式。

持續交付

由於微服務之間的依賴性降低，開發週期加快，微服務架構促進了持續交付和DevOps文化的發展。

微服務架構的實務應用

假設我們有一個電子商務系統，原本是一個單體式應用程式，現在我們將其分解為多個微服務，例如產品目錄、購物車、支付、使用者管理和訂單管理等。每個微服務都可以獨立開發、測試和佈署，這樣我們就可以更快速地回應市場變化和客戶需求。

此圖示展示了電子商務系統的微服務架構，各個微服務之間的關係清晰明瞭。

內容解密：

此圖表呈現了電子商務系統的微服務架構，每個方塊代表一個獨立的微服務，箭頭表示微服務之間的互動關係。這種架構使得我們可以獨立開發和佈署每個微服務，從而提高了整體系統的靈活性和可擴充套件性。

從單體架構轉向微服務架構的考量

在第一章「微服務導論」中，我們對比了微服務與單體架構的差異。現在你可能正在思考微服務是否適合你的團隊。如果你已經在處理單體架構帶來的成長痛，或是計畫建立一個單體系統，那麼值得考慮微服務。否則，沒有必要轉向這種架構，因為對於小型到中型的服務架構來說，微服務並不合適，考慮到所涉及的工作量。每個微服務都會帶來額外的工作負擔，例如API集合、流程監控、效能/高用性的負載平衡等，這些在單體架構中只需在應用程式層級進行一次。

微服務的優勢

微服務提供了多項優勢，包括：

  • 更大的自由度和更少的依賴：微服務旨在保持獨立，一個開發團隊可以專注於其微服務，並在保持介面合約不變或實作新的向後相容合約的前提下，自由地增強功能。
  • 故障隔離：微服務架構中的一個故障不會導致整個系統當機，因為每個微服務都在其自己的流程空間中執行。例如，在一個根據微服務架構的電子商務系統中，如果產品評論微服務當機，使用者仍然可以看到庫存、選擇商品、檢視購物車並下單。
  • 資料分割和去中心化：與所有資料通常儲存在中央資料函式庫的單體應用程式不同，微服務提供了分割資料的機會。每個微服務通常擁有自己的資料，並不直接與其他微服務分享資料。

圖示：可擴充套件性比較

此圖示展示了單體架構與微服務架構在可擴充套件性方面的比較。

微服務的劣勢

儘管微服務帶來了許多好處，但也伴隨著一些挑戰：

  • 除錯複雜度增加：由於微服務之間的通訊增加了潛在的故障點，因此像「我的系統在任何給定的例項中是否健康？」或「如果終端使用者報告問題，如效能緩慢或超時，我該從哪裡開始除錯？」這樣的問題變得更加難以回答。
  • 延遲增加：程式間通訊（像微服務使用的那樣）比程式內通訊（像單體應用程式使用的那樣）慢。
  • 維運複雜度：在現實世界的應用程式中，維運團隊必須處理複雜的基礎設施、佈署、監控、可用性、備份和管理。
  • 版本控制：由於根據微服務的應用程式可能有成千上萬個微服務，版本控制和管理變得更加複雜。

是否應該轉向微服務？

本章將闡述適用（和不適用）於根據微服務架構的各種應用程式的標準。通常，高階主管和經理會尋找潛在的商業案例或投資回報率。我們將透過簡單的成本效益建模和組織投資來簡要討論這些考慮因素。

內容解密：

此段落主要閔述了企業在決定是否採用微服務架構時需要考慮的因素，包括技術優勢、業務需求和成本效益分析等。企業需要評估其目前的系統架構、業務規模和未來發展計畫，以決定是否採用微服務架構。

從單體架構轉向微服務架構

在考慮將現有的單體式應用架構轉換為微服務架構時，瞭解現有系統的疲勞徵象和微服務的潛在優勢至關重要。

現有單體式應用架構的疲勞徵象

許多單體式應用架構可能表現出以下疲勞徵象，表明它們可能適合轉換為微服務架構：

  • 佈署過程困難且耗時
  • 龐大且複雜的程式碼函式庫使開發者的IDE不勝負荷
  • 非均勻的擴充套件需求（例如，某些功能需要更多的擴充套件）
  • 開發、測試和佈署的高成本
  • 由於過多的相互依賴性，程式碼品質隨著時間的推移而下降
  • 單一元件故障導致整個應用程式故障

進行徹底的盡職調查以瞭解這些疲勞徵象並清楚地記錄它們是非常重要的。

微服務架構的潛在優勢

在決定是否轉換到微服務架構之前，瞭解微服務的以下特性是否能為現有的應用程式帶來價值也是非常重要的：

  • 圍繞業務功能組織服務
  • 獨立或部分佈署服務
  • 非同步通訊
  • 為不同的應用程式服務部分替換不同的平台元件、程式語言和/或資料函式庫，以提高效能
  • 持續佈署和持續整合
  • 每個工程團隊擁有和了解特定的業務領域，例如訂單管理和購物車

思考這些方面將讓你對自己的狀況有很好的瞭解，並判斷是否轉換到微服務正規化是有意義的。

組織變革的需求

一旦決定採用微服務架構，就必須意識到這種轉變對組織提出的獨特需求：

  • 文化變革：組織思維必須接受工程團隊角色的轉變，從功能性角色轉變為以業務為中心的角色，具有共同的目標和責任。這需要投資於新人才和培訓現有員工，以及新的系統、工具和軟體。此外，在整個軟體生命週期中需要大量的自動化來確保成功。
  • 營運流程：採用微服務正規化需要改變組織的營運流程和結構。它需要一個更具跨功能性的結構來負責微服務的佈署、支援、升級和營運。現有的測試和佈署單體式應用程式的營運流程必須被分解成多個支援數百或數千個自給自足的微服務的流程，並支援它們之間的通訊。

組織的學習曲線

現有的工程和營運團隊在適應微服務架構時面臨著全新的學習曲線。這條學習曲線可以透過以下新實踐來定義：

  • 獨立微服務：單體式應用程式作為一個大型單元存在，透過在多台機器上佈署來實作可擴充套件性。微服務則是數百到數千個自包含的服務，都需要同等的關注。
  • 微服務發現：微服務數量越多，複雜度就越高。例如，我們需要思考如何發現這些微服務，即如何以及在哪裡建立微服務的清單。其他挑戰包括按需擴充套件和版本控制，包括淘汰不再需要的服務。有許多應用程式，如Consul和Apache ZooKeeper，可以用來解決這些挑戰。

內容解密：

此段落說明瞭在微服務架構中，服務發現的重要性。Consul和Apache ZooKeeper是用於解決服務發現問題的工具，它們可以幫助建立和管理微服務的清單，並提供按需擴充套件和版本控制等功能。

  • 微服務之間的通訊：決定所有服務之間以及與外部世界之間的通訊方式，包括考慮客戶對回應時間、延遲、重試次數等的期望，以及當這些服務水平協定（SLA）或期望未被滿足時會發生什麼。可能需要建立一個標準化的介面來進行通訊。

內容解密：

此段落討論了微服務之間通訊的重要性。需要考慮客戶期望和SLA，以確保通訊的有效性和可靠性。標準化的介面可以簡化通訊過程。

此圖示展示了一個簡單的微服務架構，其中客戶端的請求透過負載平衡器分配給不同的微服務，微服務處理請求後將回應傳回給負載平衡器，最終傳回給客戶端。

微服務測試、擴充套件、升級和安全管理

  • 微服務測試：測試實踐和原則與單體式應用程式不同。每個自給自足的微服務都很容易測試，但測試由數百或數千個微服務組成的完整應用程式卻很具挑戰性。這需要處理許多移動部件，而整合測試成為整體測試中最重要的方面。

內容解密：

此段落強調了微服務測試的挑戰。雖然每個微服務都可以獨立測試，但整體應用程式的測試需要考慮多個微服務之間的互動和整合。

  • 微服務擴充套件：透過微服務，可以更輕鬆、更有效地進行擴充套件。可以根據需求擴充套件或縮減所需的服務。但這需要設計時考慮擴充套件需求，並自動化擴充套件過程。

內容解密：

此段落討論了微服務擴充套件的優勢和挑戰。需要設計可擴充套件的微服務，並使用自動化工具來實作按需擴充套件。

import autoscaling

def scale_service(service_name, instance_count):
    # 呼叫自動擴充套件API
    autoscaling.scale(service_name, instance_count)

# 示例：擴充套件訂單管理服務到5個例項
scale_service("order_management", 5)

內容解密：

此程式碼範例展示瞭如何使用自動擴充套件API來擴充套件特定的微服務。在這個例子中，scale_service函式接受服務名稱和例項數量作為引數，並呼叫自動擴充套件API來實作擴充套件。

總之，從單體式架構轉向微服務架構需要仔細評估現有系統的疲勞徵象和微服務的潛在優勢，同時也需要考慮組織變革的需求和學習曲線。透過瞭解這些因素，可以更好地做出是否轉換到微服務架構的決定。

微服務架構的商業案例分析

在討論微服務架構時，我們必須考慮其對企業的長期影響。相較於傳統的單體式架構，微服務架構雖然在初期建設和維護上更為複雜，但其長期效益卻能遠遠超過初始投資。

微服務的挑戰

在匯入微服務架構時，企業可能會面臨以下挑戰：

  • 監控與管理：由於微服務數量眾多且分散，企業需要建立完善的監控機制，包括基礎設施和應用程式層級的監控，以確保系統的穩定執行。
  • 組態管理：隨著微服務數量的增加，組態管理變得更加複雜。企業需要選擇合適的工具來簡化組態管理流程。
  • 故障處理：在微服務架構中，故障處理至關重要。企業需要設計出能夠自我修復的系統，以確保系統的穩定性。

微服務的商業案例

那麼，為什麼企業應該投資於微服務架構？首先，我們需要了解傳統單體式架構的生命週期通常只有4到5年，這主要是由於以下因素：

  • 不斷變化的客戶需求：客戶需求的不斷變化使得現有的功能過時。
  • 新的業務需求：新的業務需求需要新的技術和架構。
  • 缺乏彈性：傳統單體式架構難以調整或變更。
  • 擴充套件性不足：傳統單體式架構難以擴充套件。
  • 技術過時：技術的不斷進步使得傳統單體式架構過時。
  • 系統緩慢：系統緩慢會影響使用者經驗。

當企業面臨這些挑戰時，通常會考慮投資於新的技術平台。微服務架構可以幫助企業解決這些問題。

成本分析

讓我們透過一個假設性的例子來分析單體式平台和微服務架構的成本組成：

  • 建造成本：包括分析、設計、開發、測試和發布等階段的成本。
  • 維護成本：包括應用程式的正常維護和基礎設施的維護成本。
  • 變更/更新成本：包括新增功能、修復錯誤、重新測試和重新發布等成本。
  • 擴充套件成本：包括擴充套件平台以維持系統回應時間和效能的成本。
  • 上市時間：包括從分析到發布的時間。

透過比較單體式平台和微服務架構的成本組成，我們可以發現：

  • 建造成本：MCTB < SCTB。雖然微服務架構的建造成本可能更高，但如果企業已經具備相關的能力，那麼建造成本的差異可能不大。
  • 維護成本：MCTM > SCTM。微服務架構可以透過自動化和容器化等技術降低維護成本。

內容解密：

此段落中，我們比較了單體式平台和微服務架構的建造成本和維護成本。我們使用了 MCTB 和 SCTB 來代表單體式平台和微服務架構的建造成本，使用了 MCTM 和 SCTM 來代表單體式平台和微服務架構的維護成本。結果表明，雖然微服務架構的建造成本可能更高，但其維護成本卻更低。

此圖示展示了單體式平台和微服務架構的成本組成比較。

綜上所述，雖然微服務架構在初期建設和維護上更為複雜，但其長期效益卻能遠遠超過初始投資。企業應該根據自身的需求和情況，權衡微服務架構的利弊，做出合理的決策。

切換至微服務架構的商業案例分析

在探討微服務架構的優勢時，我們必須考慮多個關鍵因素，包括更新現有功能的成本、擴充套件系統的成本以及上市時間。相較於單體式應用程式，微服務架構在這些方面展現出顯著的優勢。

更新與擴充套件的成本優勢

  1. 變更/更新成本： 微服務架構的一大優點是更新現有功能或新增功能相對簡單。相比之下，單體式專案由於其複雜性，往往需要重建整個應用程式。微服務的更新、建置、測試和佈署過程更為迅速和靈活，大大降低了人為錯誤的風險。

  2. 擴充套件成本： 微服務允許按需擴充套件，並且只針對需要擴充套件的元件。這與單體式應用程式不同，後者需要啟動整個應用程式的另一個例項。透過自動啟動服務容器並在需求下降時銷毀它們，微服務架構節省了努力和硬體/軟體資源，如圖2.1所示。

上市時間的優勢

  1. 上市時間： 微服務架構提供了更快的上市時間。首先，新增服務並上線生產通常比更新單體式應用程式更快。其次，微服務的模組化架構與容器技術相結合，支援了DevOps的軟體交付方法。DevOps提供了執行成功軟體平台所需的四個關鍵要素：速度、穩定性、效能和協作，從而實作了敏捷性和更快的上市時間。

成本組成分析

圖2.1展示了單體式應用程式與微服務架構在擴充套件性方面的比較。微服務架構透過只擴充套件需要的元件來提高資源利用率。

圖2.1 擴充套件性比較

透過分析商業案例，我們可以得出結論：雖然微服務架構需要初始投資和組織層面的支援，但從長遠來看，它在成本文約方面具有淨效益。對於大多陣列織來說，更快的上市時間可能是轉向微服務正規化的最大回報。

微服務架構的未來優勢

  1. 未來的更新週期： 單體式架構的軟體應用程式具有有限的平均壽命。一旦壽命結束，組織通常會開始新的週期，這又需要初始的建置成本。微服務則打破了這個概念，因為它們提供了根據業務需求新增或移除微服務的靈活性，能夠按需擴大或縮小系統，並根據需要替換過時的技術，從而最小化成本。

綜上所述，考慮到所有相關成本，微服務架構的淨成本將遠低於單體式架構。圖2.2簡化了這種成本比較的圖形表示。

圖2.2 成本比較圖形表示

微服務中的程式間通訊

在單體式架構中，元件之間的通訊透過函式、方法或模組呼叫進行，通常非常直接。然而，在建立微服務架構時，設計和實作程式間通訊則更為複雜。本章將回顧一些最佳實踐。

互動型別

微服務通常透過API或Web服務公開其功能。有兩種基本的通訊/互動模式：

  1. 同步通訊： 客戶端期望立即回應，同時阻塞其他操作（例如，HTTP請求/回應）。

  2. 非同步通訊： 不期望立即得到服務回應。客戶端發出服務呼叫後繼續其工作。例子包括發布/訂閱和HTTP請求/非同步回應。

正如第1章「微服務簡介」中所討論的，非同步通訊是微服務之間互動的首選方法。使用同步通訊可能會導致系統在等待回應時變得不夠靈活和高效。

通訊模式的選擇

選擇適當的通訊模式對於微服務架構的成功至關重要。非同步通訊模式能夠提高系統的回應性和可擴充套件性，使其更適合現代分散式系統的需求。

此圖示展示了同步與非同步通訊模式之間的差異

透過瞭解和實施適當的程式間通訊策略，組織可以充分發揮微服務架構的潛力，提高系統的整體效能和可維護性。

微服務間的通訊

在微服務架構中，服務之間的通訊是至關重要的。同步通訊和非同步通訊是兩種主要的通訊方式。同步通訊是指客戶端發出請求後，必須等待伺服器端的回應才能繼續工作。如果伺服器端出現故障或錯誤，客戶端將被阻塞，導致系統無法擴充套件。相反，非同步通訊允許客戶端發出請求後繼續工作，而伺服器端的回應則透過監聽器執行緒處理，從而提高了系統的可擴充套件性和服務之間的鬆散耦合。

非同步通訊與發布/訂閱模式

非同步通訊可以透過發布/訂閱模式來實作。在這種模式下，發布者將訊息釋出到訊息匯流排（如Kafka），而訂閱者則註冊接收感興趣的訊息並進行處理。這種模式使得服務之間的耦合度降低，並且可以提高系統的可靠性和可擴充套件性。

準備編寫Web服務

在準備編寫Web服務時，開發者需要決定三件事情：

  1. 協定：HTTP是Web服務中最常用的協定，它根據簡單的請求/回應模型，並且具有很高的輕量級和廣泛的支援。
  2. Web服務標準：主要的選擇包括RESTful、SOAP和Data。RESTful是目前最為廣泛接受和推薦的標準，因為它根據HTTP請求和回應，並且具有較小的負擔和較高的效率。
  3. 訊息格式：常見的訊息格式包括XML、RSS和JSON。JSON因其易讀性和高效性而成為許多開發者的首選。

JSON的優勢

JSON是一種根據文字的資料交換格式，具有以下優勢：

  • 易於閱讀和編寫
  • 可以輕易地轉換為物件和文字表示
  • 相比XML，JSON的資料量更小，從而提高了處理速度

微服務維護

一旦建立了微服務之間的通訊，就需要對其進行維護。微服務的維護包括以下幾個方面：

  • 支援現有的客戶端實作：在更新微服務的核心功能時，需要確保向後相容，以避免影響到依賴該服務的其他微服務。
  • 故障安全設計：透過新增逾時機制和錯誤處理，可以提高系統的可靠性和容錯能力。
  • 監控：定期監控微服務的狀態，可以及時發現並處理問題。
  • 佇列：使用發布/訂閱模式可以提高系統的非同步處理能力，並且可以在服務暫時不可用時暫存請求。

發現服務

在微服務架構中，當服務數量龐大時，如何有效地管理和發現這些服務成為了一個挑戰。發現服務（Discovery Service）可以用來解決這個問題，它允許客戶端動態地發現和呼叫微服務，而無需知道服務的具體位置和例項數量。

發現服務的重要性

在微服務架構中，客戶端需要呼叫多個服務來完成一個業務功能。如果沒有發現服務，客戶端就需要知道每個服務的位置和例項數量，這將導致系統變得僵化和難以維護。透過使用發現服務，可以實作服務的動態發現和負載平衡，從而提高系統的可擴充套件性和可靠性。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 微服務架構簡介與實務應用

package "微服務架構" {
    component [API Gateway] as gateway

    package "核心服務" {
        component [用戶服務] as user
        component [訂單服務] as order
        component [商品服務] as product
        component [支付服務] as payment
    }

    package "基礎設施" {
        component [服務發現] as discovery
        component [配置中心] as config
        component [鏈路追蹤] as trace
    }

    queue "訊息佇列" as mq
    database "各服務資料庫" as db
}

gateway --> user
gateway --> order
gateway --> product
gateway --> payment

user --> mq : 事件發布
order --> mq : 事件發布
product --> mq : 事件發布
payment --> mq : 事件發布

user --> discovery : 註冊/發現
order --> discovery
product --> discovery
payment --> discovery

user --> db
order --> db
product --> db
payment --> db

@enduml

此圖示展示了客戶端透過發現服務來呼叫微服務例項的過程。

內容解密：

此圖示使用了Plantuml語法來表示客戶端、發現服務和微服務例項之間的互動關係。其中，客戶端首先呼叫發現服務以取得可用的微服務例項，然後直接呼叫這些例項來完成業務功能。這種機制使得系統具有更高的可擴充套件性和靈活性。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。