微服務架構最近作為一種用于創建復雜且可擴展的軟件系統的技術而受到歡迎。微服務是可擴展的、可獨立部署的服務，它們通過網絡相互通信。

讓這些服務更容易相互通信是微服務設計的主要問題之一。HTTP 和消息傳遞是微服務通信的兩種流行方法。

用于 Web 服務器和客戶端之間通信的通用協議稱為 HTTP（超文本傳輸協議）。HTTP 經常用作微服務架構中服務之間的通信方式。

另一方面，消息傳遞涉及使用 RabbitMQ、Apache Kafka 或 Amazon SQS 等消息傳遞系統在服務之間交換消息。

HTTP 和消息傳遞之間的決定取決于許多變量，包括特定用例、可伸縮性要求和系統復雜性。兩種協議都有優點和缺點。在這種情況下，了解每種策略的優缺點對于選擇最佳行動方案至關重要。

對于微服務通信，本文將研究HTTP和消息傳遞之間的區別，并概述每種策略所涉及的權衡。

使用 HTTP 進行通信

HTTP 是萬維網的基礎，廣泛用于網絡瀏覽器和服務器之間的通信。近年來，它也被用作微服務之間的通信手段。在此技術中，RESTful API 用于跨微服務交換數據。

讓我們看一些代碼來觀察微服務中基于 HTTP 的通信與基于消息傳遞的通信有何不同：

public class OrderService {

private RestTemplate restTemplate;

public OrderService(RestTemplate restTemplate) {
this.restTemplate = restTemplate;
}

public void processOrder(Order order) {
Customer customer = restTemplate.getForObject("http://customer-service/customers/" + order.getCustomerId(), Customer.class);
// process order logic...
}
}

在此示例中，訂單微服務向客戶微服務發出 HTTP 請求，以使用RestTemplate. 使用該函數檢索客戶數據getForObject，并將響應反序列化為 Customer 對象。

我們有兩個微服務，一個客戶微服務和一個訂單微服務。由于客戶微服務的 RESTful API，訂單微服務可以獲取客戶信息。

基于 HTTP 的通信的好處

• 使用簡單：HTTP 是眾所周知的簡單協議。開發人員可以輕松創建RESTful API來公開微服務并實現它們之間的通信。
• 無狀態性：由于其無狀態性，HTTP 具有天然的可擴展性。每個請求都是單獨處理的，不需要客戶端和服務器之間的連接。
• 緩存：HTTP 允許緩存，這在處理大量數據時很重要。微服務可以通過緩存頻繁請求的數據來降低系統負載并提高速度。

基于 HTTP 的通信的缺點

• 延遲：交換大量數據時，基于 HTTP 的連接可能會造成延遲。這可能會導致反應時間變慢和性能下降。
• 復雜性：隨著端點和方法數量的增加，RESTful API 可能會變得復雜。這會使系統維護和更新變得困難。
• 缺乏可靠性：基于 HTTP 的通信依賴于網絡，可能會受到網絡緩慢和錯誤的影響。

通過消息通信

消息代理用于在基于消息的通信中促進微服務之間的通信。消息在微服務之間的隊列中路由，將發送者和接收者解耦。

在這個例子中我們有兩個相同的微服務：

1. 客戶微服務
2. 訂單微服務

一旦客戶微服務將其發布到消息代理，訂單微服務就會訂閱此信息。

客戶微服務標識符

public class CustomerService {

private MessageBroker messageBroker;

public CustomerService(MessageBroker messageBroker)
{
this.messageBroker = messageBroker;
}

public void createCustomer(Customer customer) {
// create customer logic...
messageBroker.publish("customer.created", customer);
}
}

訂購微服務代碼

public class OrderService {

private MessageBroker messageBroker;

public OrderService(MessageBroker messageBroker) {
this.messageBroker = messageBroker;
this.messageBroker.subscribe("customer.created", this::processOrder);
}

private void processOrder(Customer customer) {
// process order logic...
}
}

當建立新客戶時，客戶微服務將客戶信息發布到消息代理。訂單微服務使用 subscribe 方法訂閱此信息，processOrder每當收到新的客戶端信息時都會調用該方法。

基于消息的通信的好處

• 可擴展性：基于消息的通信具有極高的可擴展性，能夠以極短的延遲處理大量數據。這使其非常適合高通量應用。
• 可靠性：由于使用消息代理，基于消息的通信非常可靠。通信在被正確處理之前會排隊，從而減少數據丟失的機會。
• 適應性：基于消息的通信具有適應性，可以處理范圍廣泛的數據形式，包括二進制數據。因此，它適用于處理復雜數據結構的應用程序。

基于消息的通信的缺點

• 復雜性：基于消息的通信可能難以設置和管理，尤其是當涉及大量消息代理時。
• 協議支持有限：基于消息的通信通常僅限于少數協議，例如AMQP或 MQTT。這可能會導致與使用其他協議的其他系統的集成出現問題。
• 缺乏標準化：目前沒有用于微服務通信的通用消息協議，使得各種系統之間的互操作性存在問題。

如示例中所示，微服務中基于 HTTP 和基于消息傳遞的通信之間存在很大差異。基于 HTTP 的通信簡單易用，但隨著端點和方法數量的增加，它會產生延遲和復雜性。

雖然基于消息的通信具有令人難以置信的可擴展性和可靠性，但設置和操作起來更加復雜。最終，這兩種方法之間的選擇取決于應用程序的特定要求。

結論

HTTP 和消息傳遞對于微服務通信各有優缺點。HTTP 是一種更直接和完善的協議，使其更易于實施和與現有基礎設施集成。它還提供了與負載平衡器和代理更好的兼容性，使其成為需要高可用性和可擴展性的系統的不錯選擇。

另一方面，消息傳遞為微服務提供了更健壯和靈活的通信機制。它允許異步和解耦通信，這對于需要松散耦合和事件驅動架構的系統可能是有益的。

消息傳遞還支持不同的模式，例如發布/訂閱，這有助于降低復雜性和提高可擴展性。

最終，HTTP 和消息傳遞之間的選擇將取決于微服務架構的具體要求。在決定通信協議時，團隊應仔細考慮可擴展性、靈活性和兼容性等因素。

在許多情況下，結合 HTTP 和消息傳遞優勢的混合方法可能是最有效的解決方案。