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

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

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

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

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

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

使用 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...
}
}

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

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

基于 HTTP 的通信的好處

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

基于 HTTP 的通信的缺點

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

通過消息通信

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

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

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

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

客戶微服務標識符

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...
}
}

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

基于消息的通信的好處

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

基于消息的通信的缺點

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

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

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

結論

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

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

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

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

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