雲設計模式介紹

雲設計模式介紹

以及它們如何幫助應對分散式計算的謬誤

作為構建分散式系統的軟體工程師，我們經常遇到諸如不可靠的網路、延遲問題和安全問題等挑戰。"分散式計算的謬誤"描述瞭如果未解決，可能導致系統故障的常見誤解。但認識到這些陷阱只是開始。真正的問題是：我們如何有效地克服它們？這就是雲設計模式發揮作用的地方。這些模式為分散式計算固有的挑戰提供了實用的解決方案。本文將探討資料管理、設計、訊息傳遞、安全性和可靠性方面的重要雲設計模式。使用這些模式可以讓您在不陷入常見錯誤的情況下，應對分散式系統的複雜性。那麼，讓我們深入探討。

分散式計算的謬誤

作為軟體工程師，我們經常構建跨越多個伺服器、資料中心甚至大陸的系統。分散式計算已成為現代應用程式的支柱，實現了以前難以想象的可擴充套件性和彈性。然而，儘管它無處不在，但常見的誤解——被稱為“分散式計算的謬誤”。我們收集了“分散式計算的謬誤”的宣告，以說明不熟悉分散式應用程式的程式設計師經常做出的錯誤假設。我們在建立微服務架構時經常看到的是，應該解決這些謬誤。

以下是謬誤列表：

• 網路是可靠的。這是最關鍵的謬誤。網路本質上是不可靠的，容易出現中斷、延遲和惡意攻擊。分散式系統必須設計得能夠優雅地處理這些不可避免的小問題。

示例：如果微服務應用程式沒有優雅地處理網路超時，可能會導致服務故障。

• 延遲為零。每個動作都有反應，分散式系統也不例外。訊息需要時間傳播，計算需要時間完成。忽略延遲可能導致效能瓶頸和不可預測的行為。

示例：如果實時分析平臺沒有考慮資料傳輸延遲，可能會提供過時的見解。

• 頻寬是無限的。雖然頻寬不斷增加，但它並不是無限的。分散式系統經常生成大量資料，低估頻寬限制可能導致減速和擁堵。

示例：未經壓縮的高解析度影片流可能會壓倒網路資源，導致緩衝和延遲。

• 網路是安全的。您的資料並非因為分佈在多臺機器上就不可戰勝。分散式系統提供了更大的攻擊面，安全考慮必須融入設計的基本結構中。

示例：透過不安全的網路傳輸敏感資料可能會導致惡意行為者截獲資料。

• 拓撲不會改變。網路是動態實體，隨著節點的新增、刪除或重新配置而不斷演變。分散式系統需要適應這些變化而不失一步。

示例：配置檔案中的固定IP地址可能會導致伺服器移動或重新定址時服務中斷。

• 只有一個管理員。在現實世界中，分散式系統通常跨越許多管理域。理解和協調這些邊界對於順利執行至關重要。

示例：部門之間的不一致的防火牆規則可能會造成安全漏洞或連線問題。

• 傳輸成本為零。然而，透過網路傳送資料並不免費。每次跳轉都會產生成本，無論是在時間還是資源上。最佳化資料傳輸對於高效的分散式系統至關重要。

示例：雲服務中的過多API呼叫可能會因資料出站費用而增加成本。

• 網路是同質的，不同的網路具有不同的特性。在本地網路上有效的可能在全域性網際網路上表現不佳。分散式系統需要靈活且能夠適應多樣化的網路環境。

示例：為高速有線連線最佳化的應用程式可能在行動網路上表現不佳。

理解這些謬誤是構建可靠的分散式系統的第一步，但也要：

• 設計具有冗餘和容錯能力的系統。
• 建立監控和警報系統。
• 將安全最佳實踐和資料加密放在首位。
• 最佳化通訊協議以提高效率和效能。
• 選擇適合系統特定需求的技術和架構。

雲設計模式

這些設計原則可用於建立可靠、可擴充套件和安全的雲系統。大多數雲工作負載都容易受到分散式計算謬誤的影響，因此這些模式提高了認識並減輕了它們，包括權衡。我們可以將雲設計模式分為三個一般組。每個模式可以應用於任何分散式系統，無論是在本地託管還是在雲平臺上。

主要的雲設計模式是：

1.資料管理

雲應用的主要組成部分是資料管理，它影響著大多數質量標準。資料託管在許多伺服器和位置，以提高效能、可擴充套件性或可用性。這可能會帶來幾個困難。例如，通常需要在許多地方之間同步資料以確保資料一致性。

這組中最重要的模式是：

快取旁路Cache-Aside模式：透過快取頻繁訪問的資料來提高應用程式效能並減少對資料儲存的負載。

• 場景：從快取中讀取資料，如果快取未命中則從資料庫讀取並更新快取。
• 案例：透過Redis提升資料庫查詢效率。
• 工具鏈：Redis、Memcached。
• 架構評估：適合高頻查詢且資料更新較少的場景。

命令和查詢責任分離（CQRS）模式：分離讀寫操作以最佳化效能、可擴充套件性和安全性。

• 場景：分離讀寫操作以提高效能。
• 案例：寫操作更新資料庫，讀操作從快取獲取資料。
• 工具鏈：EventStore、Axon。
• 架構評估：適合高併發的應用，提供更高的擴充套件性。

事件溯源Event Sourcing模式：維護應用程式資料的完整變更歷史。

• 場景：透過事件重放恢復系統狀態。
• 案例：交易系統中儲存每個交易事件以確保審計和一致性。
• 工具鏈：Kafka、EventStore。
• 架構評估：適合對歷史資料重現有需求的場景。

物化檢視Materialized View模式：透過預計算和儲存複雜查詢的結果來提高查詢效能。

• 場景：預先計算並儲存查詢結果以加速訪問。
• 案例：透過資料庫物化檢視提高複雜查詢的效能。
• 工具鏈：PostgreSQL、MongoDB。
• 架構評估：適用於複雜計算查詢場景，提升系統響應速度

分片Sharding模式：透過跨多個資料庫或伺服器分割槽資料來擴充套件資料儲存。

• 場景：將資料水平切分到多個資料庫例項。
• 案例：透過分片將大資料分佈在多個資料庫以提高效能。
• 工具鏈：Cassandra、MongoDB。
• 架構評估：適用於大規模資料儲存，確保資料查詢和儲存的高擴充套件性

Valet Key代客鑰匙模式：為客戶提供對特定資源的安全、臨時訪問，而不會暴露敏感憑據。

• 場景：為臨時使用者生成短期訪問憑證。
• 案例：使用者上傳檔案時，生成限時的S3上傳URL。
• 工具鏈：AWS S3 Pre-Signed URL、Azure SAS Token。
• 架構評估：適用於臨時授權的場景，確保安全性和便捷性。

Index Table（索引表）：

• 場景：建立索引表以提高查詢效率。
• 案例：為高頻查詢的資料庫建立專用索引表。
• 工具鏈：Elasticsearch、DynamoDB。
• 架構評估：適合需要快速查詢特定資料的場景。

2.設計和實現

良好的設計包括可維護性，以便於管理和開發，可重用性，允許元件和子系統在不同的應用程式和上下文中使用，以及元件設計和部署的一致性和連貫性。在設計和實現階段所做的決策影響雲託管應用程式和服務的質量和總擁有成本。

這組中最重要的模式是：

絞殺者Strangler Fig模式：透過用新應用程式或服務替換特定部分來逐步遷移遺留系統。

• 場景：逐步用新系統替換舊系統。
• 案例：在不影響現有功能的前提下替換舊的單體架構。
• 工具鏈：Kubernetes、Blue-Green Deployment。
• 架構評估：適合逐步遷移專案，避免大規模重構帶來的風險。

反腐敗層Anti-Corruption Layer模式：當整合具有不同模型或正規化的遺留或外部系統時，這種模式保護新系統的完整性。

• 場景：防止不同系統間的模型和資料汙染。
• 案例：舊系統與新系統整合時，確保資料一致性和隔離。
• 工具鏈：Apache Camel、Spring Integration。
• 架構評估：適合遷移專案，確保系統之間的邊界清晰。

艙壁Bulkhead模式：透過隔離一個元件中的故障，防止影響其他元件，從而增加系統的彈性。

• 場景：分離關鍵資源，防止故障蔓延。 系統的某些元件或服務出現故障時，希望其他元件能夠繼續正常工作，避免“雪崩效應”。需要將不同服務的資源隔離，以避免一個服務消耗過多資源導致整個系統崩潰。
  在一個微服務系統中，假設服務A和服務B都訪問同一個資料庫，可以為每個服務分配獨立的資料庫連線池。即使服務A耗盡了所有連線，服務B仍然可以繼續訪問資料庫。
• 案例：微服務架構中為不同服務設定獨立的資源池。 在高併發場景下，防止某個模組消耗過多執行緒或記憶體資源，影響整個系統的執行。
• 工具鏈：Hystrix、Resilience4j，Kubernetes可以為不同服務定義資源限制（如CPU、記憶體），實現隔離艙的概念。
• 架構評估：適用於分散式系統中容災場景，可提升系統的隔離性與彈性。

邊車Sidecar模式：部署一個並行元件來擴充套件或增強服務的功能，而無需修改其程式碼。

• 場景：在微服務旁邊執行的輔助服務，提供額外功能。
• 案例：在Kubernetes中為每個服務執行一個Sidecar容器。
• 工具鏈：Envoy、Istio。
• 架構評估：提高微服務的可觀察性和管理能力。

服務端對前端（Backends for Frontends）模式:涉及建立針對不同客戶端應用程式（例如，Web和移動）需求量身定製的單獨後端服務。

• 場景：為不同前端提供專用的後端服務。
• 案例：移動端與桌面端分別有各自的後端服務。
• 工具鏈：GraphQL、Apollo Server。
• 架構評估：提升前端效能和後端靈活性，適合多端系統。

Ambassador（大使模式）：

• 場景：在微服務和外部系統之間建立代理。
• 案例：在微服務和外部資料庫間使用代理處理通訊。
• 工具鏈：Envoy、HAProxy。
• 架構評估：增強外部依賴的可擴充套件性和安全性。

Compute Resource Consolidation（計算資源整合）：

• 場景：將多個計算任務整合到一個資源池中。
• 案例：在Kubernetes中整合不同的工作負載以節省成本。
• 工具鏈：Kubernetes、Nomad。
• 架構評估：適合多工整合的場景，最大化計算資源利用率。

External Configuration Store（外部配置儲存）：

• 場景：將配置儲存在外部系統中以支援動態更新。
• 案例：透過Consul或Etcd實現配置的集中管理。
• 工具鏈：Consul、Etcd、Spring Cloud Config。
• 架構評估：適合配置頻繁變動或需要動態更新的場景。

Gateway Aggregation（閘道器聚合）：

• 場景：透過閘道器聚合多個請求以減少客戶端請求次數。
• 案例：API Gateway聚合多個微服務的響應。
• 工具鏈：Nginx、Kong。
• 架構評估：適用於減少客戶端對多個服務的請求次數，提高效能。

Gateway Offloading（閘道器解除安裝）：

• 場景：將一些功能（如SSL處理）解除安裝到閘道器層。
• 案例：Nginx閘道器負責SSL終止，減少後端服務壓力。
• 工具鏈：Nginx、AWS API Gateway。
• 架構評估：提高後端效能，減少不必要的處理負載。

Gateway Routing（閘道器路由）：

• 場景：透過閘道器對不同的服務進行路由。
• 案例：API Gateway根據請求路徑將請求路由到不同服務。
• 工具鏈：Kong、AWS API Gateway。
• 架構評估：適合微服務架構中的請求管理，提升系統靈活性。

Leader Election（領導選舉）：

• 場景：在叢集中透過選舉選擇一個領導者。
• 案例：Kafka叢集中的領導者選舉。
• 工具鏈：Zookeeper、Etcd。
• 架構評估：適用於分散式系統中的高可用性和容錯性。

Static Content Hosting（靜態內容託管）：

• 場景：將靜態內容託管在外部服務上，減少後端負載。
• 案例：透過CDN託管靜態網頁內容。
• 工具鏈：AWS S3、Cloudflare。
• 架構評估：提升靜態內容載入速度，減少後端服務壓力。

3.訊息傳遞

由於雲應用程式是分散式的，因此需要訊息傳遞基礎設施來連線各個部分和服務。這種基礎設施應該是松耦合的，以允許最大的可擴充套件性。非同步訊息傳遞很受歡迎，有許多優點，但也有缺點，如排序訊息、管理毒藥訊息、冪等性等。

這組中最重要的模式是：

基於佇列的負載均衡Queue-Based Load Leveling模式：透過緩衝傳入請求並確保系統能夠平滑處理負載波動來管理變化的工作負載。

• 場景：透過佇列平衡請求的突發負載。
• 案例：訊息佇列處理非同步請求。
• 工具鏈：RabbitMQ、AWS SQS。
• 架構評估：用於緩解高峰負載壓力，提升系統響應能力。

釋出-訂閱模式：使應用程式能夠向多個消費者廣播訊息，而不必與它們緊密耦合。

• 場景：透過事件釋出通知多個訂閱者。
• 案例：電商系統中使用者下單後通知多個服務。
• 工具鏈：Kafka、Redis Pub/Sub。
• 架構評估：適合事件驅動的系統，提升系統的擴充套件性和解耦能力。

競爭消費者模式：透過讓多個消費者併發處理訊息來增強可擴充套件性和吞吐量。

• 場景：多個消費者同時處理訊息佇列中的訊息，增加吞吐量。
• 案例：多個消費者從同一個Kafka Topic中讀取訊息。
• 工具鏈：Kafka、RabbitMQ。
• 架構評估：適合高吞吐的任務處理，確保任務負載在多個例項間分配。

訊息代理模式：透過引入處理訊息路由、轉換和傳遞的中介軟體來解耦應用程式。

1）場景：

• 當應用程式中的元件或服務需要通訊，但不希望直接相互依賴時。可以透過訊息代理作為中間層來傳遞訊息。
• 系統需要處理大量非同步任務，或將任務分發給多個消費者時（例如，處理日誌、事件、任務佇列等）。
• 服務間需要透過非同步通訊來應對高併發或高吞吐量的場景，避免服務直接呼叫帶來的效能瓶頸或故障蔓延。
• 系統中可能有多個訊息生產者和消費者，需要靈活控制訊息流、優先順序、負載均衡等功能。

2）案例：

• 電商訂單系統：當使用者下單後，系統會觸發多種非同步任務（如通知庫存系統減少庫存、通知物流系統發貨、通知使用者服務系統傳送確認郵件等）。訊息代理可以確保訂單服務透過訊息佇列分發任務，而不需要與各服務直接通訊。
• 日誌處理系統：應用程式將大量日誌資訊非同步傳送到訊息代理，由多個消費者（如日誌分析服務、監控服務等）來處理和分析日誌資訊。
• 銀行支付系統：使用者發起支付請求時，支付服務透過訊息代理通知其他系統（如風控、賬戶管理、通知服務等）處理相關事務。訊息代理可確保系統間通訊的可靠性與非同步處理能力，提升整體系統的可擴充套件性。

3）工具鏈：

• Apache Kafka：一個分散式的流處理平臺，廣泛用於高吞吐量的實時資料管道、日誌處理、事件驅動架構等場景。它支援持久化和回放訊息。
• RabbitMQ：一種輕量級的訊息佇列系統，支援多種訊息模式（如釋出/訂閱、工作佇列、路由等），適合中小型非同步任務的處理。
• ActiveMQ：Apache基金會的訊息代理系統，支援多種協議（如AMQP、MQTT等），常用於傳統企業訊息通訊系統。
• AWS SQS（Simple Queue Service）：Amazon提供的完全託管的訊息佇列服務，具有高可用性和可靠性，適合雲環境中的分散式系統。
• Google Pub/Sub：Google雲提供的分散式訊息佇列服務，支援大規模實時訊息傳遞，適合微服務架構或事件驅動系統。

4）架構評估：

• 松耦合：透過訊息代理解耦各個服務，生產者和消費者不直接依賴。它們透過訊息代理非同步通訊，這提高了系統的靈活性和可擴充套件性。
• 可靠性增強：訊息代理通常支援持久化訊息和重試機制，確保訊息不會丟失，特別是在網路中斷或服務故障時。
• 可擴充套件性：訊息代理可以支援多個消費者同時處理訊息，能夠靈活分配負載，並實現訊息的廣播、路由、優先順序等高階功能，適合處理高併發任務。
• 非同步處理能力：Message Broker Pattern允許任務非同步處理，不必等到消費者處理完成，生產者可以繼續執行後續任務。這減少了服務間的等待時間和延遲。
• 效能瓶頸：訊息代理的引入會增加額外的延遲和效能開銷，尤其是在高併發的情況下，如果沒有適當的容量規劃，訊息代理本身可能成為系統的瓶頸。
• 複雜性增加：引入訊息代理需要額外的基礎設施、配置和管理，尤其是在使用分散式的訊息代理（如Kafka）時，需要考慮分割槽、複製、恢復等機制。

管道和過濾器模式：透過一系列處理元件（過濾器）處理資料，這些元件透過通道（管道）連線。

1）場景：

• 系統需要處理複雜的、多步驟的資料流操作時，如資料轉換、清洗、增強、過濾等。
• 系統中存在需要重複使用的處理步驟，可以透過過濾器來模組化，提升可維護性和靈活性。
• 資料處理需要可擴充套件，可以在不影響其他步驟的情況下增加或修改某一階段的處理邏輯。
• 需要並行處理資料流，提高效能和處理效率。

2）案例：

• 資料處理管道：在ETL（Extract, Transform, Load）流程中，資料從多個源提取後，需要經過一系列的轉換（過濾、清洗、轉換格式、聚合等）才能載入到目標資料庫。每個資料轉換步驟可以作為一個過濾器，資料透過管道在過濾器之間流動。
• 日誌處理系統：當日志從應用程式生成後，可以透過管道傳遞給多個過濾器來進行處理：格式化、篩選特定日誌級別、新增時間戳等，最後輸出到儲存系統或監控平臺。
• 媒體檔案處理：在處理媒體檔案（如影像或影片）時，可以透過多個過濾器依次執行各種操作：調整大小、格式轉換、水印新增、壓縮等，每個操作都是一個獨立的過濾器，管道將檔案從一個處理步驟傳輸到下一個。
• 微服務鏈式處理：多個微服務依次處理同一條請求或任務時，每個微服務執行一個處理步驟，並將處理結果傳遞給下一個微服務。這種方式也可被視為一種管道與過濾器的實現。

3）工具鏈：

• Apache Camel：一個基於EIP（Enterprise Integration Patterns）的整合框架，允許定義靈活的資料處理和傳輸管道，可以將多個步驟透過過濾器模式進行串聯。
• Spring Integration：Spring框架的擴充套件模組，提供訊息處理、檔案處理、資料轉換等功能，可以輕鬆實現管道與過濾器模式。
• Apache NiFi：一個資料流自動化和管理工具，專注於資料的捕獲、轉換、路由等操作，可以將多個過濾器進行管道化處理。
• Logstash：ELK（Elasticsearch、Logstash、Kibana）棧中的資料處理工具，允許透過多個過濾器對日誌進行處理，並透過管道將日誌傳遞到不同的儲存或分析系統。
• Kubernetes Sidecar Containers：在微服務架構中，Sidecar容器可以用於在資料流經過不同服務時對其進行處理、過濾或增強，作為管道與過濾器模式的實現之一。

4）架構評估：

• 模組化與可重用性：每個過濾器執行一個獨立的功能，且可以被其他管道重複使用，提高了程式碼和邏輯的可重用性和可維護性。
• 靈活性：可以在不影響整體管道的情況下，隨時增加、刪除或修改某個過濾器，提升了系統的靈活性。例如，處理資料流時，可以輕鬆加入新的步驟，而無需改變整個系統架構。
• 可擴充套件性：透過將資料流分解為多個獨立的步驟，可以透過並行處理提升系統效能，尤其是在處理大規模資料或高併發場景中。
• 效能考量：雖然模式可以並行處理和模組化，但是如果某個過濾器處理速度慢，可能成為瓶頸，阻礙資料流的效率。需確保管道的每個階段都高效執行，避免系統效能瓶頸。
• 除錯與監控：管道化的資料處理在除錯時可能較為複雜，需要額外的日誌、監控和視覺化工具來追蹤資料在不同過濾器之間的流動情況。

Scheduler Agent Supervisor（排程代理監控）：

• 場景：協調多個作業的排程和執行。
• 案例：定時作業和批處理任務的監控和管理。
• 工具鏈：Celery、Kubernetes Cron Jobs。
• 架構評估：用於批處理和排程密集型應用的管理。

Choreography（編排）：

• 場景：透過事件觸發機制處理複雜的業務邏輯。
• 案例：電商系統中訂單、庫存和支付服務的協作。
• 工具鏈：Apache Kafka、EventBridge。
• 架構評估：複雜的微服務體系結構，適合無中心控制器的分散式工作流。

Claim Check（認領檢查）：

• 場景：在訊息中只傳遞指向大型資料的引用，減少訊息體積。
• 案例：訊息傳遞時將大資料儲存到外部儲存服務中。
• 工具鏈：S3、Kafka。
• 架構評估：適合需要傳輸大資料但又希望控制訊息大小的場景。

Priority Queue（優先順序佇列）：

• 場景：根據優先順序處理訊息，確保關鍵任務優先執行。
• 案例：支付系統中高優先順序交易優先處理。
• 工具鏈：RabbitMQ、ActiveMQ。
• 架構評估：適用於對訊息處理順序有明確優先順序需求的業務場景。

Async Request-Reply（非同步請求-回覆）：

• 場景：透過非同步訊息處理請求與回覆。
• 案例：使用訊息佇列進行任務分發。
• 工具鏈：Kafka、RabbitMQ。
• 架構評估：用於松耦合的微服務通訊，減輕服務壓力。

Choreography（編排）：

• 場景：透過事件觸發機制處理複雜的業務邏輯。
• 案例：電商系統中訂單、庫存和支付服務的協作。
• 工具鏈：Apache Kafka、EventBridge。
• 架構評估：複雜的微服務體系結構，適合無中心控制器的分散式工作流。

4.安全性

安全性保護資訊系統免受敵對攻擊，確保資料的機密性、完整性和可用性。失去這些保證可能會損害公司的運營、收入和市場聲譽。遵循公認的程式並保持警惕以發現和解決漏洞和活躍威脅對於維護安全至關重要。

這組中最重要的模式是：

門禁模式：透過驗證和清理請求，透過充當門衛的專用主機來保護後端服務。

• 場景：對資源訪問進行細粒度的控制和驗證。
• 案例：API Gateway中的訪問控制。
• 工具鏈：Kong Gateway、AWS API Gateway。
• 架構評估：對公共和敏感資源的訪問管理非常重要，適合分散式系統中的訪問控制策略。

聯合身份模式：透過允許使用者使用來自受信任身份提供商的現有憑據登入來簡化使用者認證。

• 場景：使用者透過單點登入（SSO）在多個系統中進行身份驗證。
• 案例：OAuth 2.0、OpenID Connect。
• 工具鏈：AWS Cognito、Okta、Auth0。
• 架構評估：適合需要跨多個服務共享認證的架構，能夠減少重複登入。

金鑰儲存模式：安全地管理敏感配置資料，如密碼、API金鑰和連線字串。

1）場景：

• 當應用程式需要儲存和使用敏感資訊，如資料庫憑據、API金鑰、SSH金鑰等時。
• 應用程式或服務之間共享機密資料時，確保這些資料在網路傳輸或儲存過程中不被洩露。
• 應用部署在多雲或多環境（如開發、測試、生產）中，需要中央管理的機密資訊。
• 需要在不修改程式碼的情況下更新或輪換這些敏感資料。

2）案例：

• CI/CD流水線中的機密管理：在持續整合/持續部署流水線中，工具需要訪問敏感資訊（如雲提供商的訪問金鑰），但不應將這些資訊硬編碼到指令碼或配置檔案中。
• 微服務架構中的機密管理：多個微服務需要訪問資料庫或外部API，每個服務應透過安全機制訪問這些敏感資訊，而不是將憑據儲存在配置檔案中。
• 伺服器上證書的安全輪換：Web伺服器需要週期性地輪換SSL/TLS證書，以避免證書過期或遭到濫用。

3）工具鏈：

• HashiCorp Vault：一個廣泛使用的機密管理工具，支援動態憑據、加密儲存以及訪問控制。
• AWS Secrets Manager：專為AWS環境設計的機密管理服務，自動輪換、加密儲存金鑰並控制訪問許可權。
• Azure Key Vault：Azure雲平臺中的機密儲存服務，專注於管理金鑰、機密、證書和硬體安全模組（HSM）保護的金鑰。
• Kubernetes Secrets：Kubernetes原生的機密管理機制，用於儲存敏感資料，並將其作為環境變數或卷注入到容器中。
• Google Cloud Secret Manager：Google雲平臺的機密管理服務，允許應用程式集中儲存和訪問敏感資訊。
• CyberArk Conjur：面向企業環境的機密管理平臺，支援動態憑據生成和細粒度的訪問控制。

4）架構評估：

• 安全性提升：透過集中化儲存和加密管理，極大提高了敏感資訊的安全性，防止洩漏或濫用。特別是工具支援審計和訪問控制，可以追蹤誰訪問了哪些機密資訊。
• 易於管理和輪換：Secret Store Pattern支援動態金鑰生成和自動金鑰輪換，減少了手動管理的複雜度和潛在的安全風險。
• 減少程式碼暴露風險：敏感資訊不再需要硬編碼到配置檔案或程式碼中，降低了程式碼洩漏時的風險，特別是在開源專案中。
• 擴充套件性和靈活性：這種模式在多環境、多服務之間具有良好的擴充套件性和靈活性，可以透過API訪問、CLI工具、自動化工具進行管理，支援高可用的分散式應用場景。
• 可操作性挑戰：如果配置不當，可能導致金鑰無法正常輪換或過期金鑰影響生產環境執行。因此，需要設定監控和告警機制。

驗證模式：透過確保所有輸入資料在處理之前都經過驗證和清理來保護應用程式。

1）場景：

• 當使用者輸入的資料需要嚴格符合業務規則和格式要求時，如表單輸入、API請求引數等。
• 在系統中不同層次（前端、後端、資料庫）對資料的有效性進行驗證，避免錯誤資料進入核心邏輯或儲存。
• 防止惡意輸入，如SQL隱碼攻擊、XSS攻擊等，透過驗證模式保證輸入的安全性。
• 在微服務之間的通訊或系統整合時，確保資料交換的有效性。

2）案例：

• 表單資料驗證：使用者在前端提交表單時，驗證模式可以確保使用者輸入的郵箱、電話、密碼等符合特定格式，並在前端或後端給出即時反饋。
• API請求資料驗證：在接收第三方系統的API請求時，驗證模式可以檢查傳入的JSON、XML等資料結構是否合法，並拒絕不符合要求的資料。
• 資料庫層驗證：透過資料庫的約束（如唯一性、非空、外來鍵等）進一步確儲存儲資料的有效性，防止無效資料進入資料庫。
• 服務間通訊驗證：微服務之間的訊息傳遞需要驗證訊息的格式、資料型別和欄位值，以避免資料傳輸中的錯誤導致系統故障。

3）工具鏈：

• 前端驗證庫：
  • React Hook Form：React的輕量級表單驗證庫，支援表單狀態管理與校驗。
  • Formik：另一個流行的React表單管理和驗證庫。
  • VeeValidate：Vue.js應用中使用的表單驗證庫。
• 後端驗證庫：
  • Spring Validation：Spring框架內建的驗證功能，基於註解方式，可以對Java物件進行自動驗證。
  • Hibernate Validator：Java中廣泛使用的驗證框架，支援Bean Validation規範。
  • Express-validator：Node.js中用於Express框架的驗證庫。
• API閘道器：
  • Kong：可以在API請求進入系統前，對請求的資料結構和引數進行驗證。
  • AWS API Gateway：支援對請求引數進行格式和內容驗證，減少無效請求的處理。

4）架構評估：

• 安全性提升：透過驗證模式，系統能夠在早期階段過濾掉惡意或無效資料，減少SQL隱碼攻擊、跨站指令碼攻擊等安全風險。
• 資料完整性保證：在系統的不同層級實現驗證（如前端、後端、資料庫等），能保證進入系統的資料符合業務規則，避免錯誤資料帶來的業務問題。
• 效能考量：儘量在前端或閘道器層執行初步驗證，可以減少系統後端的負載。後端和資料庫層的驗證應作為防禦的最後一道關卡。
• 使用者體驗：在前端提供即時的驗證反饋能提升使用者體驗，減少因為提交無效資料而產生的困惑或重複操作。
• 維護成本：如果不同層級（前端、後端、資料庫）都實現了資料驗證，確保驗證規則的一致性和維護難度可能較大，尤其在驗證邏輯複雜時需要確保驗證規則不重複、不衝突。

5.可靠性

當我們談論可靠性時，我們通常指的是系統的可用性和彈性。系統執行和操作的時間百分比稱為可用性，以正常執行時間的百分比表示。相比之下，系統的彈性是其處理和從故意和非故意故障中恢復的能力。

這組中最重要的模式是：

重試Retry模式：透過自動重試失敗的操作來處理瞬時故障，以增加成功的機會。

• 場景：針對失敗的操作進行自動重試。
• 案例：請求超時時重新嘗試通訊。
• 工具鏈：Resilience4j、Exponential Backoff演算法。
• 架構評估：可用於短暫故障的恢復，提高系統的健壯性。

斷路器Circuit Breaker模式：這種模式防止應用程式重複嘗試可能失敗的操作，保護系統資源並提高穩定性。

• 場景：保護服務免於過載，透過熔斷防止級聯故障。
• 案例：請求失敗過多時中斷通訊。 某個微服務依賴一個第三方API，API偶爾會當機或變慢。在API不可用時，Circuit Breaker開啟，拒絕進一步呼叫，防止系統執行緒被掛起。

工作原理：

• 熔斷器三種狀態：
  • Closed（關閉狀態）：正常工作，所有請求正常透過。
  • Open（開啟狀態）：當外部服務故障或響應時間超過設定閾值時，熔斷器會進入開啟狀態，直接拒絕請求，防止資源耗盡。
  • Half-Open（半開狀態）：在等待一段時間後，熔斷器進入半開狀態，允許少量請求透過。如果這些請求成功，熔斷器恢復到關閉狀態；否則，熔斷器重新開啟。
• 當依賴服務恢復正常後，系統將逐漸允許更多請求，直至恢復正常狀態。
• 工具鏈：Hystrix、Resilience4j。
• 架構評估：適用於高併發服務，減少系統級故障的風險。

節流Throttling模式：透過限制應用程式處理請求的速率來控制資源消耗。

• 場景：限制請求速率，防止系統過載。
• 案例：API Gateway中的速率限制。
• 工具鏈：Nginx、Kong、AWS API Gateway。
• 架構評估：適合防止DDoS攻擊和惡意請求高峰。

健康端點監控Health Endpoint Monitoring模式：透過公開監控工具可以訪問的健康檢查端點來主動檢測系統故障。

• 場景：監控系統健康狀況，自動恢復故障。
• 案例：透過API健康檢查自動檢測服務狀態。
• 工具鏈：Prometheus、Grafana。
• 架構評估：為自動化監控和故障恢復提供關鍵支援。

Compensating Transaction（補償事務）：

• 場景：用於長事務或分散式事務的補償機制。
• 案例：訂單取消時，補償回滾之前的相關操作。
• 工具鏈：Saga、Apache Camel。
• 架構評估：適用於跨多個微服務的事務一致性管理。

Deployment Stamps（部署標記）：

• 場景：分離部署環境以提高系統可靠性。
• 案例：同一服務在不同區域部署以確保可用性。
• 工具鏈：Kubernetes、Terraform。
• 架構評估：對於全球分佈的服務，確保多區域故障的容錯性。

Geodes（地質模式）是一種分散式快取模式：

用於解決大規模分散式系統中資料存取效能和一致性問題。該模式的核心思想是透過在多個地理位置部署快取層，減少對遠端資料來源的訪問，從而提升效能並降低網路延遲。

1）場景：

• 全球分佈的使用者訪問：當應用程式的使用者遍佈全球，不同地區的使用者訪問資料來源時可能會受到網路延遲的影響。Geodes模式透過在每個地理位置部署快取，使得使用者可以訪問距離最近的資料副本，從而減少訪問延遲。
• 高可用性需求：當系統需要在不同地理位置實現高可用性和災難恢復時，可以在多個位置保持資料的快取副本，確保某個地區的快取失效時，使用者還能從其他地區獲取資料。
• 高併發場景：在需要處理大量併發請求的系統中，透過分散式快取減少對原始資料來源（如資料庫）的直接訪問，從而減輕後端資料來源的負載，提升系統的吞吐量。
• 讀多寫少的系統：如果系統的讀操作遠多於寫操作，Geodes模式可以透過快取加速讀操作，而不頻繁訪問原始資料來源。

2）案例：

• 全球電商平臺：使用者在全球各地購物時，為了提升使用者體驗，需要減少使用者請求到後端資料庫的時間。在全球多個資料中心部署快取，使用者可以就近訪問商品、庫存、價格等資料，減少對主資料庫的訪問，提升響應速度。
• 內容分發網路（CDN）：內容分發網路的快取機制本質上就是Geodes模式的一個應用案例。CDN將靜態資源（如影像、影片等）快取到全球各地的伺服器節點，使用者請求時可以從最近的節點獲取資源，降低延遲和頻寬消耗。
• 金融交易系統：對於需要跨多個地區進行金融交易的系統來說，延遲是一個關鍵因素。透過在每個地區部署快取，Geodes模式可以確保交易資料、使用者資訊等快速訪問，提升交易的實時性和準確性。
• 社交媒體平臺：全球使用者同時訪問平臺上的熱門內容（如影片、圖片、帖子等），透過地理位置快取來減少對主伺服器的負載，提升使用者的訪問速度和系統的穩定性。

3） 工具鏈：

• Redis：一個高效能的分散式記憶體快取系統，支援主從架構以及跨地域複製，常用於實現分散式快取和加速讀操作。
• Memcached：另一個分散式快取系統，適合高頻讀寫場景，雖然不支援持久化和複製，但在全球分散式快取場景中也有應用。
• Amazon ElastiCache：AWS的託管快取服務，支援Redis和Memcached，能夠部署在多個AWS區域，用於地理分散式快取和高可用場景。
• Azure Cache for Redis：Microsoft Azure的託管快取服務，支援跨區域分佈，適合在多地域的應用場景中使用。
• Google Cloud Memorystore：Google雲平臺提供的快取服務，支援Redis和Memcached，可以結合全球分佈的Google Cloud區域實現地理分佈的快取。

4）架構評估：

• 效能提升：透過將資料快取到離使用者最近的地理位置，顯著減少請求延遲，提升系統的整體效能。特別是對於全球使用者分佈的系統，能夠有效提升使用者體驗。
• 高可用性：多個地理位置的快取副本可以確保系統在某個區域故障時仍能從其他區域獲取資料，提高了系統的容錯能力和可用性。
• 一致性問題：快取中的資料可能會與主資料來源不同步，因此需要採取措施確保資料的一致性（如設定TTL（時間到期）或使用快取更新策略）。
• 複雜性增加：分散式快取引入了資料複製、同步、快取失效等複雜問題，尤其是涉及多個地理區域時，需要設計合理的資料一致性和更新策略。
• 成本評估：快取的儲存和跨地域複製會增加運營成本，尤其是在使用託管快取服務時，需要評估成本和效能的權衡。

Azure中的負載均衡

確保應用程式能夠處理高流量並始終保持可用是至關重要的。負載均衡是實現這一目標的重要策略，Azure提供了針對不同需求量身定製的幾個健壯的負載均衡解決方案。瞭解Azure的負載均衡選項可以幫助您設計可擴充套件和彈性架構，無論您是在開發簡單的雲應用程式還是複雜的系統。 用於負載均衡的主要Azure服務有:

Azure Front Door:一個全域性負載均衡器，在第7層(HTTP/HTTPS)提供應用程式加速和全域性負載均衡。它基於效能最佳化路由，並可以處理SSL解除安裝。

Azure Traffic Manager:基於dns的流量負載均衡器，可跨多個區域分配流量。它支援各種路由方法，如基於地理、效能和優先順序的路由，確保將使用者定向到最合適的區域端點。

Azure Load Balancer:第4層負載均衡器在一個區域的虛擬機器(vm)之間分配流量。它支援入站和出站場景，為區域部署提供高可用性和低延遲。

Azure Application Gateway:是一個第7層負載均衡器，具有高階路由功能、SSL終端和Web應用防火牆(WAF)。它是為需要區域負載平衡的web應用程式量身定製的。

總結

學習雲設計模式對於開發者、架構師以及任何在雲端計算環境中工作的專業人員來說，具有深遠的意義。隨著雲端計算技術的不斷髮展和普及，傳統的軟體開發和部署方式已經發生了翻天覆地的變化。雲設計模式作為在雲端計算背景下產生的一系列最佳實踐和設計原則，旨在幫助開發者更高效地構建、部署和管理雲原生應用。

---

今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理，資訊保安，團隊建設 有參考作用 , 您可能感興趣的文章:
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
影片直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續整合/CD
網際網路電商購物車架構演變案例
網際網路業務場景下訊息佇列架構
網際網路高效研發團隊管理演進之一
訊息系統架構設計演進
網際網路電商搜尋架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之效能實時度量系統演變

如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。 該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。