微服務與kubernetes

概述

微服務架構是一種設計模式，將應用程序分解成小的、自主的服務，每個服務都負責特定的業務功能。K8s 與微服務的關係密切，因為 kubernetes 提供了一個理想的環境來運行和管理微服務。

容器化

微服務通常被打包成容器，這使得它們能夠在 kubernetes 平台上輕鬆部署和管理

自動化運維

kubernetes 自動化部署、滾動更新和自我修復功能，這些功能對於微服務架構的高可用性和穩定性至關重要

可擴展性

根據流量和負載動態調整微服務的實例數量，確保應用程序在高負載下依然能夠平穩運行

服務發現和負載均衡

kubernetes 自帶服務發現和負載均衡(load balance)功能，這使得微服務之間的通信更加可靠和高效

優缺點

優點	缺點
靈活性和敏捷性：獨立開發、測試和部署	複雜性增加：系統間通信和數據一致性問題
可擴展性：根據需求單獨擴展	部署和運維成本：需要完善的 CI/CD 流程
故障隔離：單個服務故障不影響整個系統	分佈式系統問題：網絡延遲和日志收集等
技術多樣性：根據需求選擇合適技術	數據管理困難：數據一致性和管理問題
易於維護和擴展：代碼基礎小，易於理解	溝通和協作成本：團隊間的協作和溝通

Event Bus

Event Bus 是一種架構模式，用於在不同的應用程序或服務之間傳遞事件消息。通常用於實現事件驅動的架構，支持異步通信和事件廣播。

Kafka 是一個流行的分佈式事件流平台， 提供高吞吐量、低延遲的消息傳遞，適合處理大型數據流和實時數據管道。

使用event bus

	優點	缺點
解耦合	生產者和消費者不需直接通信，解耦合	複雜性增加：需處理事件順序、重放和去重等問題
擴展性	可輕鬆添加新消費者	調試困難：異步通信使系統行為難以追踪和調試
異步通信	提高系統響應性和性能	延遲：事件傳遞和處理存在延遲
可靠性	事件持久化和重放，確保消息不丟失	運維成本：需要額外基礎設施來運行和維護事件總線
靈活性	支持廣播和單播消息	依賴管理：需小心管理事件依賴，避免過多耦合

不使用 Event Bus

	優點	缺點
簡單性	系統架構簡單，易於理解和實現	耦合度高：服務之間直接依賴增加耦合度
直接通信	服務之間可直接通信，簡化數據傳遞路徑	擴展困難：添加或修改服務需改動多個部分
低延遲	同步通信通常具有較低延遲	同步阻塞：同步通信可能導致服務阻塞
易於調試	系統行為易於追踪和調試	容錯性差：一個服務故障可能影響整個系統穩定性

案例：電子商務平台

一個大型的電子商務平台採用了微服務架構，使用 Kafka 作為 Event Bus 來管理訂單處理、支付、庫存管理和通知等功能。

優點：

• 解耦合：當用戶下訂單時，訂單服務會生成一個訂單創建事件，並將其發布到 Kafka。支付服務、庫存服務和通知服務分別訂閱這個事件並執行相應的操作，如扣減庫存、處理支付和發送確認郵件。這些服務之間沒有直接的依賴關係，易於獨立開發和部署。
• 擴展性：如果需要添加新的功能，如積分系統，只需創建一個新的服務來訂閱訂單創建事件，並處理相應的業務邏輯，而不需要改動現有系統。
• 異步通信：訂單創建後，不需要等待支付、庫存和通知操作完成即可返回響應，提高了系統的響應性和用戶體驗。

缺點：

• 複雜性增加：需要處理事件的順序和去重問題，例如確保重複接收到的訂單創建事件不會導致多次扣減庫存。
• 調試困難：異步通信使得追踪和調試系統行為變得更加複雜，需要使用分佈式追踪工具來監控和分析事件流。

案例：單體應用

一個中小型電子商務平台使用單體應用架構，所有功能如訂單處理、支付、庫存管理和通知都在同一個應用中實現，並使用同步通信。

優點：

• 簡單性：系統架構簡單，各個功能模塊之間通過方法調用進行通信，易於理解和實現。
• 直接通信：訂單處理完成後，直接調用支付模塊進行支付，支付完成後調用庫存模塊扣減庫存，最後調用通知模塊發送確認郵件，整個流程清晰明了。
• 低延遲：同步通信使得每個操作立即執行，適合需要即時響應的場景。

缺點：

• 同步阻塞：在高流量情況下，訂單處理模塊需要等待支付、庫存和通知操作完成才能返回響應，這可能導致系統響應變慢。例如，當支付系統出現性能瓶頸時，訂單處理會被阻塞，影響整個系統的性能。
• 耦合度高：功能模塊之間的直接依賴增加了耦合度，一個模塊的故障可能影響整個系統的穩定性。例如，如果通知模塊出現問題，會影響訂單處理的完成。