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

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

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

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

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

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

使用 HTTP 進(jìn)行通信

HTTP 是萬維網(wǎng)的基礎(chǔ)，廣泛用于網(wǎng)絡(luò)瀏覽器和服務(wù)器之間的通信。近年來，它也被用作微服務(wù)之間的通信手段。在此技術(shù)中，RESTful API 用于跨微服務(wù)交換數(shù)據(jù)。

讓我們看一些代碼來觀察微服務(wù)中基于 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...
}
}

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

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

基于 HTTP 的通信的好處

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

基于 HTTP 的通信的缺點(diǎn)

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

通過消息通信

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

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

1. 客戶微服務(wù)
2. 訂單微服務(wù)

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

客戶微服務(wù)標(biāo)識符

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);
}
}

訂購微服務(wù)代碼

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

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

基于消息的通信的好處

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

基于消息的通信的缺點(diǎn)

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

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

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

結(jié)論

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

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

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

最終，HTTP 和消息傳遞之間的選擇將取決于微服務(wù)架構(gòu)的具體要求。在決定通信協(xié)議時，團(tuán)隊?wèi)?yīng)仔細(xì)考慮可擴(kuò)展性、靈活性和兼容性等因素。

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