最好看的小说排行,完美世界小说下载,小说排行榜完结版

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

微服務(wù)：服務(wù)間如何通信？

在微服務(wù)架構(gòu)中，會將一個完整的應(yīng)用程序拆分成一組服務(wù)。這些服務(wù)之間需要經(jīng)過協(xié)作，通過接口調(diào)用，才能組成一個完整的應(yīng)用。

成都創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),閬中企業(yè)網(wǎng)站建設(shè),閬中品牌網(wǎng)站建設(shè),網(wǎng)站定制,閬中網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,閬中網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。

不同的服務(wù)部署在不同的機(jī)器上，或者同一個機(jī)器的多個容器中，進(jìn)程間進(jìn)行通信就不可避免了，也變得非常重要。

按種類來分，進(jìn)程間的通信方式有很多種，比如遠(yuǎn)程過程調(diào)用的 RESTful API 和 gRPC 、基于消息機(jī)制的異步方式等。

RESTful API ：現(xiàn)在前后端分離比較流行，RESTful API 大家應(yīng)該都比較熟悉。REST 是一種使用 HTTP 協(xié)議的進(jìn)程間通信機(jī)制，一般使用 Json 來傳遞數(shù)據(jù);
gRPC ：是一個高性能、開源和通用的 RPC 框架，基于 ProtoBuf ( Protocol Buffers ) 序列化協(xié)議開發(fā)，支持眾多開發(fā)語言。面向服務(wù)端和移動端，基于 HTTP/2 設(shè)計，帶來諸如雙向流、流控、頭部壓縮、單 TCP 連接上的多復(fù)用請求等特性;
異步消息：使用消息中間件來實現(xiàn)，比如 RabbitMQ、Kafka 等。

按照交互方式來分，會有同步、異步。

同步：客戶端向服務(wù)端發(fā)起請求、等待服務(wù)端響應(yīng)，等待的過程會造成阻塞;
異步：客戶端向服務(wù)端發(fā)起請求，服務(wù)端立即響應(yīng)，不會造成阻塞，比如說消息隊列的發(fā)布、訂閱方式。

這里有幾個概念需要統(tǒng)一下語言：接口、客戶端、服務(wù)端

接口：如果使用的是消息機(jī)制，那么接口就是由消息通道、類型和消息格式組成的;如果是基于 HTTP ，則是由 URL、HTTP 動詞和請求響應(yīng)的格式來組成;當(dāng)然，也可以是提供一組方法的類;
客戶端、服務(wù)端：說起客戶端，第一印象容易想到瀏覽器、移動 APP ，這里的客戶端是指在調(diào)用和被調(diào)用的調(diào)用方，服務(wù)端就是被調(diào)用方。而接口的定義是由服務(wù)端來進(jìn)行定義。

在前后端分離之前的單體應(yīng)用中，當(dāng)接口方法有變化時，進(jìn)行代碼編譯就知道哪些地方需要調(diào)整，或者在 IDE 中進(jìn)行接口方法引用的查找，也能很容易處理。

在微服務(wù)中，不同的服務(wù)可能是不同的團(tuán)隊來進(jìn)行開發(fā)，服務(wù)端接口的修改、滾動發(fā)布等都需要有很好的兼容性和可用性。

一種方式是在接口中向下兼容，但時間越長代碼就會變得越復(fù)雜，比如：

添加一些控制性的參數(shù)。
接口方法新添加的參數(shù)需要給默認(rèn)值。
返回值可能也需要進(jìn)行特殊處理。

另一種方式就是不向下兼容，所有的客戶端需要進(jìn)行代碼的調(diào)整來適應(yīng)新的接口。在客戶端代碼還沒有完全調(diào)整完之前，新老接口需要共存，共存有兩種方式：

使用 URL 地址中添加版本號，比如：/api/v1/xxx , /api/v2/xxx 。
在請求頭或消息體中添加版本號，接口方法中根據(jù)版本號來進(jìn)行適配，調(diào)用對應(yīng)版本的邏輯然后返回給客戶端。

所以，一個設(shè)計良好的接口可以在暴露有用功能的同時隱藏實現(xiàn)細(xì)節(jié)，對于細(xì)節(jié)，可以進(jìn)行擴(kuò)展，修改，并不會影響到客戶端的調(diào)用，這就要求在接口設(shè)計之前，需要先進(jìn)行定義，經(jīng)過多輪評審后再進(jìn)行編碼實現(xiàn)。

好的設(shè)計自帶防腐層。

因為客戶端和服務(wù)端是互相獨立的，服務(wù)端有時在特定時間內(nèi)無法完全響應(yīng)客戶端的請求，可能是自己本身的故障，也可能是超過了負(fù)載。這時，客戶端請求就會被阻塞，無限地等待。

有幾種方式可以來解決這個問題：

設(shè)置超時：在等待請求響應(yīng)時，不要無限阻塞，設(shè)置一個超時時間，超過時間就返回。
根據(jù)負(fù)載能力，限制客戶端請求的數(shù)量，超過上限，后面的請求直接返回失敗。
對客戶端請求進(jìn)行監(jiān)控，如果失敗的比例超過閾值，就進(jìn)行熔斷，讓調(diào)用立即失敗。

現(xiàn)在有一些成熟的框架可以方便進(jìn)行熔斷的處理，比如：.NET 中的 Polly、Spring Cloud 中的 Sentinel、Hystrix 。

在傳統(tǒng)軟件中，經(jīng)常使用環(huán)境變量和配置文件來進(jìn)行靜態(tài)地址的配置，而部署在云端的分布式微服務(wù)程序中，地址是動態(tài)的，那客戶端怎么能找到這些地址呢?這就需要用到服務(wù)發(fā)現(xiàn)。

服務(wù)發(fā)現(xiàn)就是客戶端不再依賴一個靜態(tài)的固定地址去尋找服務(wù)端，而是根據(jù)一個路由名稱在服務(wù)注冊表去尋找服務(wù)端地址，服務(wù)端部署后會將地址寫入服務(wù)注冊表。

在微服務(wù)框架中，也有相關(guān)的框架來實現(xiàn)服務(wù)發(fā)現(xiàn)，比如：.NET 中的 consul 、Spring Cloud 中的 Eureka、Nacos 等。

對于實時性要求不高的場景，可以采用異步消息的方式來實現(xiàn)。比如刪除數(shù)據(jù)時，需要刪除數(shù)據(jù)中對應(yīng)的附件信息、各種操作的日志記錄、流程流轉(zhuǎn)中需要發(fā)送消息通知等。

使用異步消息有下面幾個好處：

不需要知道是接收方的地址，只需要將消息發(fā)出去就行，發(fā)送方和接收方充分解耦。
消息的消費者可以是一個，也可以是多個，當(dāng)處理速度不夠時，可以橫向擴(kuò)展多個消費者來進(jìn)行處理。
消息中間件在發(fā)送方和接收方中間起到一個緩沖的作用。

現(xiàn)在流行的開源中間件有 RabbitMQ、ActiveMQ、RokcetMQ、Kafka 等，選擇這些中間件時需要考慮：

支持的編程語言。
支持的消息標(biāo)準(zhǔn);。
是否支持持久化?
延遲是否在接受范圍之內(nèi)?
消息在處理時能否保持順序?

很多工作流引擎使用的是消息驅(qū)動機(jī)制，流程在流轉(zhuǎn)過程中需要保證消息是順序處理的，否則流程數(shù)據(jù)可能出現(xiàn)錯亂，如何在保證消息順序處理的情況下又能橫向進(jìn)行擴(kuò)展，這是一個挑戰(zhàn)。在 Kafka 中可以使用分片的方式進(jìn)行解決。

上面介紹的是服務(wù)間通信的一些常用方式，了解了基本邏輯，在具體實踐時，無論是使用 .NET 技術(shù)棧還是 Java 技術(shù)棧來做微服務(wù)，就都不是什么難事了。

本文標(biāo)題：微服務(wù)：服務(wù)間如何通信？
地址分享：http://fisionsoft.com.cn/article/dpjcgpo.html

新聞中心

其他資訊