微服務架構從拆分邊界到保障數據安全的全方位策略

風清雲談 · 2024-03-13 · 更新 2026-10-23

在領域驅動設計中，提交訂單過程中，客戶透過前端界面與後端訂單上下文互動，發起服務請求。訂單上下文將提交訂單作為遠程服務，並使用命名慣例（如"Controller"或"Resource"結尾）以提高可讀性。此設計強調根據限界上下文建模，建立明確的系統邊界，提升可維護性和可理解性，促進團隊獨立開發與協作。

🔖標籤 #ddd #ddd思考

[!AI] 本文摘要
本文探討了微服務架構的設計與實施，重點在於如何有效拆分服務、確定服務邊界、選擇通信協議以及保障數據安全。透過領域驅動設計（DDD）的視角，提供了在多人團隊環境中實現高內聚低耦合的策略，包括領域劃分、界限上下文的定義及服務拆分原則。此外，文章還分析了不同通信協議（如REST、GraphQL、消息隊列）的選用原則及資安考量，並介紹了資料加密和傳輸安全的最佳實踐。總之，DDD不僅促進了微服務架構的靈活性和可維護性，還提供了保障敏感數據安全的實用指南。

在當今快速演進的軟件開發領域中，微服務架構已成為許多組織選擇的關鍵技術解決方案，旨在提升系統的靈活性、可維護性與擴展性。然而，隨著微服務的普及，如何有效地拆分服務、確定服務邊界、選擇適當的通信協議，以及保障敏感數據的安全，成為了開發團隊和架構師面臨的主要挑戰。在這樣的背景下，領域驅動設計（DDD）提供了一套理論框架和實踐方法，幫助團隊從業務需求出發，通過深入理解業務領域和建立有效的模型來指導微服務架構的設計和實施。

本文整理了一系列來自學員在課後提出的關於微服務拆分與邊界劃定、通信協議選擇，以及數據加密和保護策略的問題。我們將從領域驅動設計的視角出發，探討如何在多人團隊環境中應用DDD理念，以實現高內聚低耦合的系統設計，同時確保系統的資安需求得到有效滿足。透過這些探討，我們期望為面臨類似挑戰的開發者和架構師提供實用的指導和解決方案。

🙋Q1. 微服務拆分與邊界劃定：請問再多人團隊當中，假設工作範圍有部分同質性，應如何有效拆分系統功能，確定微服務的邊界，以實現高內聚低耦合的設計？

微服務拆分與邊界劃定

在多人團隊中，有效拆分系統功能並確定微服務的邊界以實現高內聚低耦合的設計首先需要明確系統的業務邏輯與需求。透過領域驅動設計(DDD)的方法，團隊可以專注於業務領域本身，從而識別出不同的子領域，這些子領域自然形成微服務的候選邊界。具體步驟包括：

  1. 領域劃分：根據業務邏輯和業務過程，將系統劃分為不同的領域和子領域。每個領域或子領域專注於特定的業務功能，這有助於團隊集中精力處理具體業務邏輯，並明確各自的責任範圍。
  2. 界限上下文(Bounded Context)：為每個領域或子領域定義清晰的界限，這些界限稱為界限上下文。界限上下文確定了模型的邊界，內部可以有自己的語言(限界上下文內的統一語言)和數據模型，這有助於減少不同微服務之間的依賴和耦合。
  3. 服務拆分原則：依據業務功能的獨立性、重用性、變更頻率等因素來決定服務拆分的粒度。過細的拆分可能導致管理複雜度提高，過粗可能導致服務職責過重，難以維護和擴展。
  4. 模型精煉：在明確界限上下文後，需要進行持續的模型精煉，以確保模型能夠準確地反映業務需求，並能夠有效地支持系統的開發和維護。

DDD結合Scrum的作法

  1. 跨功能團隊與界限上下文：

    • 用Scrum的跨功能團隊結構，結合領域驅動設計（DDD）中的界限上下文概念，提供了一種高效確定和劃分微服務架構中服務邊界的策略。這種方法依賴於一個包含具有不同專業技能成員的團隊，使得團隊能從技術和業務兩個角度共同探討業務邏輯和需求。這種跨領域的合作促使團隊深入理解業務的複雜性，並有助於清晰界定每個微服務的業務職責和功能範圍。通過這樣的協作和策略，可以實現微服務架構的高內聚性和低耦合性，從而優化軟件開發過程和產品質量。

  2. 迭代計劃與回顧，聚焦業務價值：

    • 通過迭代計劃和回顧，團隊不斷評估微服務架構的業務價值和技術效益，並根據業務優先級和技術債務調整微服務的劃分。這種持續的適應過程幫助團隊聚焦於提供最大業務價值的功能。

  3. 用戶故事映射與領域模型：

    • 利用用戶故事映射來識別業務需求和用戶交互流程，結合DDD的領域模型來探索和定義微服務的邊界。這種方法幫助團隊從業務需求出發，以用戶價值為導向，有效地拆分和劃定微服務邊界。

  4. 持續反饋與領域知識共享：

    • 透過定期的Sprint審查會議，團隊不僅展示開發進度，也分享領域知識和業務洞察。這種持續的知識共享和反饋機制促進了團隊對業務理解的深化，並指導微服務邊界的適時調整。

沒有Scrum的DDD做法

  1. 業務驅動的功能區塊劃分：

    • 即使在非Scrum環境下，也可以通過業務驅動的分係來劃分系統功能，確定微服務的邊界。通過深入理解業務流程和領域模型，可以識別獨立的業務功能區塊，作為微服務的候選邊界。

  2. 深入的架構設計會議，聚焦業務複雜性：

    • 定期召開的架構設計會議應該聚焦於業務複雜性和技術挑戰，通過深入討論來決定微服務的最佳劃分方案。這需要參與者對業務領域有深入的理解，並能夠從業務價值的角度出發來指導技術決策。

  3. 基於領域模型的原型開發與評估：

    • 針對潛在的微服務劃分方案，開發基於領域模型的原型，並進行評估。這種原型開發過程允許團隊在早期階段就檢驗和評估微服務的業務邏輯和技術實現，確保微服務設計與業務需求保持一致。

  4. 領域導向的文檔與溝通：

    • 在沒有Scrum的環境下，強調文檔的作用尤為重要。應該為系統的每一個微服務編寫清晰的文檔，包括服務的責任、接口定義以及與其他服務的交互方式，並通過有效的溝通確保團隊成員對微服務架構有共同的理解。

總之，無論是採用Scrum還是非Scrum作法，結合領域驅動設計的原則和實踐，都可以幫助團隊更有效地拆分系統功能，明確微服務的邊界，並實現高內聚低耦合的設計目標。重點在於深入理解業務需求，促進團隊間的協作與知識共享，並根據業務優先級進行調整。

🙋Q2. 微服務間的通信協議與模式：請問關於資安的角度下，如何選用不同微服務間通信的協議（REST、GraphQL、消息佇列等），能否舉例不同情境的選用原則？

微服務間的通信協議與模式

資安的角度來看，選擇微服務間的通信協議和模式需要考慮數據的敏感性、系統的可擴展性、性能需求以及實施的複雜度等因素。以下是一些常見情境及其選用原則的舉例：

REST

適用情境：當微服務需要通過網際網路對外提供API時，尤其是面向公眾的服務，REST是一個流行的選擇。它使用標準HTTP方法，易於理解和實現。

資安考量：

  • 使用HTTPS來確保數據傳輸過程中的加密和完整性。
  • 利用OAuth2.0或JWT進行安全的用戶身份認證和授權。
  • 對敏感數據進行加密處理，防止數據在客戶端被截獲。

GraphQL

適用情境：當前端需要從多個資料源動態獲取數據，或需要高度定制化的數據返回時，GraphQL提供了一種更靈活的數據查詢語言。

資安考量：

  • 實施查詢深度和複雜度的限制，以防止惡意用戶消耗過多服務資源。
  • 通過API Gateway或其他中間件實現細粒度的訪問控制和數據篩選，以保護敏感數據不被未經授權的用戶訪問。
  • 同樣需要使用HTTPS進行加密傳輸，並使用適當的認證機制保障訪問安全。

消息隊列（如AMQP、Kafka）

適用情境：適合處理異步通信、事件驅動的架構和微服務間的解耦。當系統需要保證消息的可靠傳遞、順序或處理大量的背景任務時。

資安考量：

  • 使用基於角色的訪問控制（Role-Based Access Control,RBAC）來限制對消息隊列的訪問，確保只有授權的服務能夠發布或消費消息。
  • 對於敏感數據，消息應在發送前進行加密，並在接收後解密，以確保數據的保密性。
  • 監控和記錄異常行為，以及時發現和應對潛在的安全威脅。

綜合考慮

選擇通信協議和模式時，除了考慮資安需求外，還應評估實現的複雜度、開發和維護成本以及系統架構的長期演進。例如，REST和GraphQL更適合輕量級和快速開發的場景，而消息隊列則更適合需要高度可靠性和擴展性的複雜系統。無論選擇哪種協議，都需要實施強大的安全策略，包括數據加密、訪問控制、認證和監控，以保護系統和數據的安全。

🙋Q3. 微服務環境下的加密和數據保護：請問關於資安的角度下，業界所使用的微服務架構中實現資料加密、傳輸安全的方法？以及如何保護敏感數據避免外部攻擊？

微服務環境下的加密和數據保護

在微服務架構中，資料加密和傳輸安全是保護敏感數據和防範外部攻擊的重要手段。業界採用多種方法來確保數據安全，以下是一些關鍵的實踐：

資料加密

  1. 靜態數據加密（At Rest）：

    • 數據在存儲時應進行加密，無論是在資料庫、文件系統還是雲存儲服務中。常用的加密算法包括AES（高級加密標準）和RSA等。
    • 加密鑰匙的管理也非常關鍵，應使用安全的鑰匙管理系統來保護和輪換加密鑰匙，避免鑰匙泄露。

  2. 動態數據加密（In Transit）：

    • 數據在傳輸過程中應使用TLS（傳輸層安全）加密，以保障數據在客戶端與服務端之間傳輸的安全性。
    • 對於敏感信息，如密碼或個人識別信息（Personal Identifiable Information，PII），應在客戶端加密後再進行傳輸。

傳輸安全

  1. HTTPS：

    • 通過實施HTTPS（安全超文本傳輸協議），為用戶與服務間的所有通信加密，防止數據被中間人攻擊者截獲。
    • 使用強制HTTPS策略（如HSTS頭），以防止SSL剝離攻擊。

  2. API安全：

    • 使用API閘道來提供統一的入口點，實施對微服務的訪問控制和流量管理。
    • 採用OAuth2.0、JWT等標準進行用戶身份認證和授權，確保只有授權用戶才能訪問敏感數據。
    • 對API請求進行節流和限流，以抵禦洪水攻擊和服務拒絕攻擊（DoS/DDoS）。

敏感數據保護

  1. 數據脫敏：

    • 在處理、存儲或展示敏感數據時，應用數據脫敏技術，如將個人識別信息替換為無法識別個人的信息。
    • 對於不需要完整數據進行業務處理的場景，只保存脫敏後的數據。

  2. 最小權限原則：

    • 確保系統內的用戶和服務僅擁有完成其工作所需的最小數據訪問權限，減少數據泄露風險。
    • 定期審計訪問權限，移除不再需要的權限。

  3. 防禦SQL注入和XSS攻擊：

    • 對所有用戶輸入進行驗證和清理，避免SQL注入、跨站腳本（XSS）等攻擊。
    • 使用準備好的語句和參數化查詢來訪問資料庫，並對用戶輸入進行適當的編碼。

縱合上述方法，業界在實現微服務架構中的資料加密和傳輸安全時，注重多層防禦策略，旨在從不同維度保護敏感數據免受外部攻擊。這些措施需要結合實際業務需求和安全要求靈活應用，以達到最優的安全效果。

重點

領域驅動設計（DDD）以業務需求為核心，提供了一套全面的策略來指導微服務架構的設計和實施，包括服務的拆分與邊界劃定、通信協議的選擇，以及數據加密與保護措施。通過界限上下文的概念，DDD強調微服務之間的獨立性，有助於降低系統耦合度並增強數據安全性。它鼓勵從深入理解業務出發來選擇技術方案，確保技術選型服務於業務目標，並保障敏感數據在存儲和傳輸過程中的安全。因此，DDD不僅促進了微服務架構的高內聚性和低耦合性，同時也提供了確保資料安全傳輸和保護的堅實理論基礎和實踐指南。

風清的筆記dddddd思考