微服務(wù)的消費(fèi)模式

基于HTTP的客戶(hù)端經(jīng)常被用作微服務(wù)的消費(fèi)者。這類(lèi)客戶(hù)端往往有著平臺(tái)無(wú)關(guān)性、語(yǔ)言無(wú)關(guān)性等特征，而被社區(qū)廣泛支持，各類(lèi)HTTP客戶(hù)端框架也是層出不窮。

本節(jié)我們將帶領(lǐng)大家來(lái)了解微服務(wù)常見(jiàn)的消費(fèi)模式。

服務(wù)直連模式

服務(wù)直連模式是最容易理解的，例如，我們?cè)跒g覽器里面訪問(wèn)某篇文章，我們知道這篇文章的URL，就能直接通過(guò)URL 訪問(wèn)到想要的資源。

又如，在之前章節(jié)中實(shí)現(xiàn)的天氣數(shù)據(jù)采集微服務(wù)，我們通過(guò)一個(gè)RestTemplate類(lèi)來(lái)訪問(wèn)REST-ful API服務(wù)，諸如此類(lèi)都是屬于服務(wù)直連模式。以下是一個(gè)RestTemplate訪問(wèn)RESTfulAPI服務(wù)的例子。

@Service
public class WeatherDataServicelmpl implements WeatherDataService {
@Autowired
private RestTemplate restTemplate;
private WeatherResponse doGetWeatherData(String uri)[
ResponseEntity response = restTemplate.getForEntity(uri,
String.class);
// ...
}
/l ...
}

服務(wù)直連模式具有以下特點(diǎn)。

• 簡(jiǎn)潔明了。

• 平臺(tái)語(yǔ)言無(wú)關(guān)性。

當(dāng)然，這種模式也有一個(gè)最大的問(wèn)題，就是假設(shè)給定的URL不可用，怎么辦?由于這種模式

無(wú)法保證服務(wù)的可用性，所以在生產(chǎn)環(huán)境中比較少用。

客戶(hù)端發(fā)現(xiàn)模式

客戶(hù)端發(fā)現(xiàn)模式是一種由客戶(hù)端來(lái)決定相應(yīng)服務(wù)實(shí)例的網(wǎng)絡(luò)位置的解決方案。其原理如下。

• 當(dāng)服務(wù)實(shí)例啟動(dòng)后，將自己的位置信息提交到服務(wù)注冊(cè)表(Service Registry)中。服務(wù)注冊(cè)表維護(hù)著所有可用的服務(wù)實(shí)例的列表。

• 客戶(hù)端從服務(wù)注冊(cè)表進(jìn)行查詢(xún)，來(lái)獲取可用的服務(wù)實(shí)例。

• 在選取可用的服務(wù)實(shí)例的過(guò)程中，客戶(hù)端自行使用負(fù)載均衡算法從多個(gè)服務(wù)實(shí)例中選擇一個(gè)，然后發(fā)出請(qǐng)求。

圖9-1顯示了客戶(hù)端發(fā)現(xiàn)模式的架構(gòu)。

服務(wù)注冊(cè)表中的實(shí)例也是動(dòng)態(tài)變化的。當(dāng)有新的實(shí)例啟動(dòng)時(shí)，實(shí)例會(huì)將實(shí)例信息注冊(cè)到服務(wù)注冊(cè)表中;當(dāng)實(shí)例下線或不可用時(shí)，服務(wù)注冊(cè)表也能及時(shí)感知到，并將不可用實(shí)例及時(shí)從服務(wù)注冊(cè)表中清除。服務(wù)注冊(cè)表可以采取類(lèi)似于心跳等機(jī)制來(lái)實(shí)現(xiàn)對(duì)服務(wù)實(shí)例的感知。

很多技術(shù)框架提供這種客戶(hù)端發(fā)現(xiàn)模式。Spring Cloud提供了完整的服務(wù)注冊(cè)及服務(wù)發(fā)現(xiàn)的實(shí)現(xiàn)方式，比如在之前章節(jié)中我們所介紹的Eureka。Eureka提供了服務(wù)注冊(cè)表的功能，為服務(wù)實(shí)例注冊(cè)管理和查詢(xún)可用實(shí)例提供了RESTAPI接口。Ribbon主要功能是提供客戶(hù)端的軟件負(fù)載均衡算法，將中間層服務(wù)連接在一起。Ribbon客戶(hù)端組件提供一系列完善的配置項(xiàng)，例如，連接超時(shí)、重試等。簡(jiǎn)單地說(shuō)，就是在服務(wù)注冊(cè)表所列出的實(shí)例，Ribbon 會(huì)自動(dòng)幫助你基于某種規(guī)則（如簡(jiǎn)單輪詢(xún)、隨即連接等）去連接這些實(shí)例。Ribbon也提供了非常簡(jiǎn)便的方式來(lái)讓我們使用Ribbon實(shí)現(xiàn)自定義的負(fù)載均衡算法。

ZooKeeper是Apache基金會(huì)下一個(gè)開(kāi)源的、高可用的分布式應(yīng)用協(xié)調(diào)服務(wù)，也被廣泛應(yīng)用于服務(wù)發(fā)現(xiàn)。

客戶(hù)端發(fā)現(xiàn)模式的優(yōu)點(diǎn)是，該模式相對(duì)直接，除了服務(wù)注冊(cè)外，其他部分基本無(wú)須做改動(dòng)。此外，由于客戶(hù)端已經(jīng)知曉所有可用的服務(wù)實(shí)例，所以能夠針對(duì)特定應(yīng)用來(lái)實(shí)現(xiàn)智能的負(fù)載均衡。

客戶(hù)端發(fā)現(xiàn)模式的缺點(diǎn)是，客戶(hù)端需要與服務(wù)注冊(cè)表進(jìn)行綁定，要針對(duì)服務(wù)端用到的每個(gè)編程語(yǔ)言和框架，來(lái)實(shí)現(xiàn)客戶(hù)端的服務(wù)發(fā)現(xiàn)邏輯。

服務(wù)端發(fā)現(xiàn)模式

另外一種服務(wù)發(fā)現(xiàn)的模式是服務(wù)端發(fā)現(xiàn)模式。該模式是客戶(hù)端通過(guò)負(fù)載均衡器向某個(gè)服務(wù)提出請(qǐng)求，負(fù)載均衡器查詢(xún)服務(wù)注冊(cè)表，并將請(qǐng)求轉(zhuǎn)發(fā)到可用的服務(wù)實(shí)例。同客戶(hù)端發(fā)現(xiàn)模式類(lèi)似，服務(wù)實(shí)例在服務(wù)注冊(cè)表中注冊(cè)或注銷(xiāo)。圖9-2展現(xiàn)了這種服務(wù)端發(fā)現(xiàn)模式的架構(gòu)。

與客戶(hù)端發(fā)現(xiàn)模式不同的是，服務(wù)端發(fā)現(xiàn)模式中需要有專(zhuān)門(mén)的負(fù)載均衡器來(lái)分發(fā)請(qǐng)求。這樣客戶(hù)端就可以保持相對(duì)簡(jiǎn)單，無(wú)須自己實(shí)現(xiàn)負(fù)載均衡機(jī)制。

DNS域名解析可以提供最簡(jiǎn)單方式的服務(wù)端發(fā)現(xiàn)功能。它作為域名和地址相互映射的一個(gè)分布式數(shù)據(jù)庫(kù)，能夠使人更方便地訪問(wèn)互聯(lián)網(wǎng)。人們?cè)谕ㄟ^(guò)瀏覽器訪問(wèn)網(wǎng)站時(shí)只需要記住網(wǎng)站的域名即可，而不需要記住那些不太容易理解的IP地址。每個(gè)DNS域名可以映射多個(gè)服務(wù)實(shí)例。但DNS 也有限制，例如，它無(wú)法及時(shí)感知服務(wù)實(shí)例是否有效，不能夠按服務(wù)器的處理能力來(lái)分配負(fù)載等。所以一個(gè)常用的解決方法是在DNS服務(wù)器與服務(wù)實(shí)例之間搭建一個(gè)負(fù)載均衡器。

在商業(yè)產(chǎn)品領(lǐng)域，Amazon公司的Elastic Load Balancing (
https:/laws.amazon.com/cn/elasticload-balancing/）提供了服務(wù)端發(fā)現(xiàn)路由的功能，可以在多個(gè)Amazon EC2實(shí)例之間自動(dòng)分配應(yīng)用程序的傳入流量。它可以實(shí)現(xiàn)應(yīng)用程序容錯(cuò)能力，從而無(wú)縫提供路由應(yīng)用程序流量所需的負(fù)載均衡容量。

Elastic Load Balancing 提供兩種類(lèi)型的負(fù)載均衡器，一種是Classic負(fù)載均衡器，可基于應(yīng)用程序或網(wǎng)絡(luò)級(jí)信息路由流量;另一種是應(yīng)用程序負(fù)載均衡器，可基于包括請(qǐng)求內(nèi)容的高級(jí)應(yīng)用程序級(jí)信息路由流量。Classic負(fù)載均衡器適用于在多個(gè)EC2實(shí)例之間進(jìn)行簡(jiǎn)單的流量負(fù)載均衡，而應(yīng)用程序負(fù)載均衡器則適用于需要高級(jí)路由功能、微服務(wù)和基于容器的架構(gòu)的應(yīng)用程序。應(yīng)用程序負(fù)載均衡器可將流量路由至多個(gè)服務(wù)，也可在同一EC2實(shí)例的多個(gè)端口之間進(jìn)行負(fù)載均衡。這兩種類(lèi)型均具備高可用性、自動(dòng)擴(kuò)展功能和可靠的安全性。

在開(kāi)源領(lǐng)域，Kubernetes ( https:/kubernetes.io）及 NGINX ( http:/nginx.org/）也能用作服務(wù)端發(fā)現(xiàn)的負(fù)載均衡器。NGINX是一個(gè)高性能的HTTP和反向代理服務(wù)器，在連接高并發(fā)的情況下，可以作為Apache服務(wù)器不錯(cuò)的替代品，在分布式系統(tǒng)中，經(jīng)常被作為負(fù)載均衡服務(wù)器使用。

Kubernetes作為Docker生態(tài)圈中的重要一員，是Google多年大規(guī)模容器管理技術(shù)的開(kāi)源版本。

其中，Kubernetes的 Proxy(代理）組件實(shí)現(xiàn)了負(fù)載均衡功能。Proxy 會(huì)根據(jù)Load Balancer將請(qǐng)求透明地轉(zhuǎn)發(fā)到集群中可用的服務(wù)實(shí)例。

使用服務(wù)端發(fā)現(xiàn)模式的好處是，它通常會(huì)簡(jiǎn)化客戶(hù)端的開(kāi)發(fā)工作，因?yàn)榭蛻?hù)端并不需要關(guān)心負(fù)載均衡的細(xì)節(jié)工作，其所要做的工作就是將請(qǐng)求發(fā)到負(fù)載均衡器即可。市面上也提供了很多商業(yè)或開(kāi)源的負(fù)載均衡器的實(shí)現(xiàn)，開(kāi)箱即用，方案也比較成熟。

實(shí)施服務(wù)端發(fā)現(xiàn)模式也有難點(diǎn)，一個(gè)比較大的問(wèn)題是需要考慮如何來(lái)配置和管理負(fù)載均衡器成為高可用的系統(tǒng)組件。

本篇文章內(nèi)容給大家講解的是微服務(wù)的消費(fèi)模式

1. 下篇文章給大家講解常見(jiàn)微服務(wù)的消費(fèi)者；

2. 覺(jué)得文章不錯(cuò)的朋友可以轉(zhuǎn)發(fā)此文關(guān)注小編；

3. 感謝大家的支持！