雲端原生應用程式中的同步和非同步通訊解碼

設計雲端原生應用程式涉及管理由微服務和無伺服器元件組成的複雜系統，這些元件需要有效地相互通訊。同步通訊透過 HTTP 或 gRPC 調用，在指定的時間範圍內等待回應，提供即時回饋，適用於需要立即回應的場景。非同步通訊利用訊息代理程式（如 RabbitMQ 或 Kafka），交換訊息而不要求立即回應，增強了系統的可擴展性。透過理解每種通訊模式的優點和缺點，架構師可以設計出有效協調這些獨立元素的系統，從而提供高效能、可擴展且可靠的雲端原生應用程式。

想像建構一台具有許多獨立部件的複雜機器，每個部件都執行其功能，但所有部件都需要彼此有效地通信才能完成任務。這是我們在設計由互連的微服務和無伺服器元件組成的雲端原生應用程式時所面臨的挑戰。在本文中，我們探討了設計強大且有彈性的通訊系統的細節，該系統可以有效地協調應用程式邊界內外的這些獨立元素。

這些細粒度的服務採用各種同步或非同步通訊方法進行內部和外部互動。在同步通訊中，一個服務使用 HTTP 或 gRPC 呼叫另一個服務，在指定的時間範圍內等待回應，然後再繼續。相反，非同步通訊涉及交換訊息而不期望立即回應。 RabbitMQ 或 Kafka 等訊息代理充當中介，緩衝訊息以確保可靠傳遞。在雲端原生應用程式中，採用通訊模式的組合通常是實用的方法。我們先從同步通信開始。

什麼是同步通訊？

同步通訊就像對話。一項服務（我們稱之為服務 A）發起請求，然後等待另一項服務（服務 B）或外部 API 的回應。這類似於提出問題並等待答案。服務 A 透過 HTTP 發送請求並等待。它要麼等待服務 B 的回應，要麼等待最長等待時間到期。在此等待期間，服務 A 暫時被阻止，就像一個人暫停其活動以等待回應一樣。這種模式通常稱為請求-應答模式，實作起來相對簡單。然而，廣泛使用它可能會帶來需要仔細考慮的挑戰。

同步通訊的挑戰

雖然同步通訊是我們的雲端原生工具包中的強大工具，但它也面臨著一系列需要仔細考慮的挑戰。

時間耦合

在整個解決方案中過度依賴同步通訊可能會導致時間耦合問題。當大量同步呼叫連結在一起時，就會發生這種情況，導致客戶端應用程式接收回應的等待時間延長。

可用性依賴性

同步通訊需要所有通訊服務同時可用。如果後端服務出現意外負載，用戶端應用程式可能會因逾時錯誤而出現故障，從而影響整體效能。

網路品質影響

網路品質可以直接影響同步通訊的效能，包括可用頻寬和回應在服務後端服務之間遍歷所需的持續時間。

儘管有這些挑戰，同步通訊在特定場景中仍具有無價的價值。讓我們在下一節中探討一些用例，其中同步通訊可能是更好的選擇。

何時使用同步通訊

在某些情況下，使用同步通訊可能是更好的選擇。

即時資料存取或保證結果

當需要立即或即時回饋時，同步通訊可以提高效率。例如，當客戶在電子商務網站上下訂單時，電子商務前端需要檢查庫存系統以確保該商品有庫存。這是同步操作，因為應用程式需要等待庫存系統的回應才能繼續處理訂單。

編排相關任務的順序

在服務必須執行一系列任務（每個任務都依賴前一個任務）的情況下，同步通訊可以維持順序。它特別適合任務順序至關重要的工作流程。

維護交易完整性

當維護多個元件之間的資料一致性至關重要時，同步通訊可以幫助維護原子事務。它與數據完整性至關重要的金融交易等場景相關。

同步通訊是一個強大的工具，但也面臨挑戰。好消息是，我們還可以選擇非同步通訊——這是一種可以與同步方法一起工作的補充風格。讓我們在下一節中進一步探討這一點。

什麼是非同步通訊？

非同步通訊模式為服務間通訊提供了動態且有效率的方法。與同步通訊不同，非同步通訊允許服務發起請求而無需等待立即回應。在此模型中，響應可能不是立即的或非同步到達單獨的通道（例如回調佇列）。這種通訊模式依賴高級訊息佇列協定 (AMQP) 等協定和訊息中間件，包括訊息代理程式或事件代理程式。 

此訊息傳遞中間件充當具有最少業務邏輯的中介。它從來源或生產者服務接收訊息，然後將它們傳送到預期的消費服務。整合訊息中間件可以顯著提高這種解耦方法的彈性和容錯能力。非同步通訊包含各種實作。讓我們進一步探討這些。

一對一溝通

在一對一訊息通訊中，生產者使用訊息代理將訊息專門分派給接收者。通常，訊息代理依靠佇列來確保可靠的通訊並提供傳送保證，例如至少一次。此實作類似於命令模式，其中傳遞的訊息充當訂閱者服務使用的命令來觸發操作。 

讓我們考慮一個線上零售店的例子來說明它的用途。線上業務很大程度上取決於其網站的可靠性。此模式提供容錯和訊息保證，確保一旦客戶在網站上下訂單，後端履行系統就會收到要處理的訂單。即使後端系統關閉，訊息代理程式也會保留訊息，並在可以處理這些訊息時傳送訊息。例如，在電子商務應用程式中，當客戶下訂單時，可以使用訊息代理將訂單詳細資訊作為訊息從訂單服務（生產者）發送到履行服務（消費者）。這是一對一通信的範例。

雲端非同步一對一通訊

一對一訊息模式的擴充是非同步請求-回應模式。在這種情況下，調度程序發送訊息而不期望得到回應。但在一些特定場景中，使用者必須利用同一訊息代理基礎設施佇列中的佇列來回應生產服務。來自消費者的回應可能包含附加元數據，例如與初始請求或回應位址相關的 ID。由於生產者不期望立即回應，因此獨立的生產者工作流程管理這些回應。訂單發出後，履行服務（消費者）會回應前端訂單服務（生產者），以便客戶可以在網站上更新。

雲端非同步一對一要求回覆通訊

當兩個服務點對點通訊時，單一消費者通訊會派上用場。但是，在某些情況下，發布者必須向多個訂閱者發送特定事件，這導致我們出現以下模式。

一對多通訊

當單一元件（發布者）需要將事件廣播到多個元件和服務（訂閱者）時，這種通訊方式非常有價值。一對多通信使用主題的概念，類似於線上論壇。 

它就像一個線上論壇，多個用戶可以在其中發布文章，他們的追蹤者可以在自己的時間閱讀這些文章，並根據需要做出回應。同樣，應用程式可以具有主題，生產者服務可以寫入這些主題，而消費服務可以從該主題中讀取。它是現實應用中最受歡迎的模式之一。 

再次考慮電子商務平台有一個更新產品價格的服務，並且多個服務需要此資訊（如訂閱服務、推薦服務等），價格更新可以作為訊息發送到訊息代理程式中的主題。所有有興趣的服務（訂閱者）都可以收聽該主題並接收價格更新。這是一對多通信的範例。有多種工具可用於實現此模式，其中 Apache Kafka、Redis Pub/Sub、Amazon SNS 和 Azure Event Grid 是最受歡迎的選擇之一。

雲端非同步一對多通訊

非同步通訊的挑戰

雖然非同步通訊提供了許多好處，但它也帶來了自己的一系列挑戰。

彈性和容錯能力

由於有大量的微服務和無伺服器元件，每個元件都有多個實例，因此故障是不可避免的。實例可能會崩潰、不堪負荷或出現暫時性故障。此外，發送方不會等待訊息被處理，因此如果發生錯誤，它可能無法立即意識到。我們必須採取以下策略：

重試機制：針對暫時性故障重試失敗的網路呼叫

#斷路器模式：防止重複呼叫失敗的服務以避免資源瓶頸

分散式追蹤

非同步通訊可以跨越多個服務，這使得監控整體系統效能變得具有挑戰性。實施分散式追蹤有助於將日誌和指標連結在一起以了解事務流。

複雜的偵錯和監控

非同步通訊可能更難以偵錯和監控，因為操作不遵循線性流程。通常需要專門的工具和技術來有效地調試和監控這些系統。

資源管理

非同步系統通常涉及長期連線和背景處理，這可能會導致資源管理挑戰。必須注意有效管理資源，以防止記憶體洩漏或 CPU 過度使用。

了解這些挑戰有助於在雲端原生應用程式中設計更強大、更有彈性的非同步通訊系統。

最後的話

同步和非同步通訊模式之間的選擇不是二元的，而是基於應用程式的特定要求的策略決策。

同步通訊易於實現並提供即時回饋，使其適合即時資料存取、編排相關任務以及維護事務完整性。然而，它也面臨時間耦合、可用性依賴性和網路品質影響等挑戰。

另一方面，非同步通訊允許服務發起請求而無需等待立即回應，從而增強了系統的回應能力和可擴展性。它提供了靈活性，非常適合不需要立即回饋的場景。然而，它帶來了彈性、容錯、分散式追蹤、調試、監控和資源管理方面的複雜性。

總之，為雲端原生應用程式設計強大且有彈性的通訊系統需要深入了解同步和非同步通訊模式。透過仔細考慮每種模式的優點和缺點並使它們與需求保持一致，架構師可以設計出有效協調應用程式邊界內外的獨立元素的系統，以交付高效能、可擴展且可靠的雲端原生應用程式。

以上是雲端原生應用程式中的同步和非同步通訊解碼的詳細內容。更多資訊請關注PHP中文網其他相關文章！