在微服務(wù)世界中，每個(gè)人都使用緩存，緩存無(wú)處不在。緩存可以提高性能，減少后端負(fù)載，或者減少down機(jī)時(shí)間。有許多方法可以配置系統(tǒng)中的緩存，緩沖應(yīng)該被放在系統(tǒng)的哪個(gè)層上?根據(jù)以往成功經(jīng)驗(yàn)，系統(tǒng)中您應(yīng)該只在一個(gè)地方使用緩存。不應(yīng)該同時(shí)在多個(gè)層中組合模式和緩存，例如同樣的內(nèi)容在HTTP層和應(yīng)用程序級(jí)別同時(shí)做緩存。這種方法可能導(dǎo)致更多的緩存失效問(wèn)題，并使您的系統(tǒng)更容易出錯(cuò)，且難于調(diào)試。

如果您在一個(gè)特定的層上使用緩存，那么您可以選擇使用哪種模式。最保守的方法是老式的客戶(hù)機(jī)-服務(wù)器(或云)模式，這個(gè)問(wèn)題的正確答案不止一個(gè)。您可以將緩存放在每個(gè)服務(wù)中，或者作為一個(gè)完全獨(dú)立的緩存服務(wù)器。您還可以將它放在每個(gè)服務(wù)的前面，甚至作為屬于服務(wù)的sidecar容器等等。本文下面，讓我們總結(jié)一下您在微服務(wù)世界多種方式的緩存體系結(jié)構(gòu)。

嵌入式緩存

最簡(jiǎn)單的緩存模式是嵌入式緩存。

嵌入式緩存

在上圖中，流程如下:

1.請(qǐng)求進(jìn)入負(fù)載平衡器。

2.負(fù)載均衡器將請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用程序服務(wù)之一。

3.應(yīng)用程序服務(wù)接收請(qǐng)求，并檢查是否相同的請(qǐng)求已經(jīng)執(zhí)行(并存儲(chǔ)在緩存)◦

如果是，然后返回緩存數(shù)據(jù)。反之，則執(zhí)行業(yè)務(wù)操作，并把結(jié)果數(shù)據(jù)存儲(chǔ)在緩存中，并返回結(jié)果數(shù)據(jù)。

業(yè)務(wù)操作可以是任何值得緩存的內(nèi)容。例如，執(zhí)行計(jì)算、查詢(xún)數(shù)據(jù)庫(kù)或調(diào)用外部web服務(wù)等。

這種緩存邏輯非常簡(jiǎn)單，我們可以使用內(nèi)置的數(shù)據(jù)結(jié)構(gòu)或一些緩存庫(kù)(如Guava cache)為其快速編寫(xiě)代碼。我們還可以將緩存放在應(yīng)用程序?qū)又?，并使用大多?shù)web框架提供的緩存功能。例如，對(duì)于Spring，添加緩存層只需要向方法添加@Cacheable注釋。

嵌入式緩存方法有一個(gè)嚴(yán)重的問(wèn)題。假設(shè)有一個(gè)向我們的系統(tǒng)發(fā)出的請(qǐng)求，它第一次被轉(zhuǎn)發(fā)到頂部的應(yīng)用程序服務(wù)A。然后，同樣的請(qǐng)求出現(xiàn)，但這一次負(fù)載平衡器將其轉(zhuǎn)發(fā)給底部的應(yīng)用程序服務(wù)B。這種情況下，我們收到了兩次相同的請(qǐng)求，但是必須執(zhí)行兩次業(yè)務(wù)邏輯，因?yàn)閳D中的兩個(gè)緩存是分別完成的。為了處理這樣的問(wèn)題，可以使用嵌入分布式緩存。

嵌入分布式緩存

嵌入式分布式緩存仍然是嵌入式緩存的模式;但是，這一次我們將使用Hazelcast(Hazelcast 是由Hazelcast公司開(kāi)發(fā)和維護(hù)的開(kāi)源產(chǎn)品，可以為基于jvm環(huán)境運(yùn)行的各種應(yīng)用提供分布式集群和分布式緩存服務(wù))而不是默認(rèn)的非分布式緩存庫(kù)。從現(xiàn)在開(kāi)始，所有緩存(嵌入到所有應(yīng)用程序中)形成一個(gè)分布式緩存集群。因?yàn)镠azelcast是用Java編寫(xiě)的，所以您可以將它與Spring一起使用;

您需要做的就是添加以下CacheManager配置。

通過(guò)這幾行代碼，我們讓Spring為它提供的所有緩存功能使用Hazelcast。

使用嵌入式緩存(分布式和非分布式)很簡(jiǎn)單，因?yàn)樗恍枰魏晤~外的配置或部署。而且，您總是可以獲得低延遲的數(shù)據(jù)傳輸，因?yàn)榫彺嬖谖锢砩线\(yùn)行在相同的JVM中。稍后我們將更仔細(xì)地研究這個(gè)解決方案的優(yōu)缺點(diǎn)。

下面讓我們介紹另一個(gè)完全不同的緩存模式，客戶(hù)機(jī)-服務(wù)器。

客戶(hù)端/服務(wù)器式緩存

此時(shí)，圖中所示流程如下:

1.請(qǐng)求進(jìn)入負(fù)載均衡組件并被轉(zhuǎn)發(fā)到應(yīng)用程序服務(wù)

2.應(yīng)用程序使用緩存客戶(hù)機(jī)連接到緩存服務(wù)器

3.如果沒(méi)有找到值，則執(zhí)行通常的業(yè)務(wù)邏輯，緩存值并返回響應(yīng)

該體系結(jié)構(gòu)與經(jīng)典的數(shù)據(jù)庫(kù)體系結(jié)構(gòu)相似。我們有一個(gè)中心服務(wù)器(或者更準(zhǔn)確地說(shuō)是一組服務(wù)器)，應(yīng)用程序連接到該服務(wù)器。如果我們將客戶(hù)機(jī)-服務(wù)器模式與嵌入式緩存進(jìn)行比較，主要有兩個(gè)區(qū)別:

• 首先，緩存服務(wù)器在我們的體系結(jié)構(gòu)中是一個(gè)單獨(dú)的單元，這意味著我們可以單獨(dú)管理它(向上/向下伸縮、備份、安全)。然而，這也意味著它通常需要單獨(dú)的項(xiàng)目事務(wù)處工作(甚至單獨(dú)的項(xiàng)目事務(wù)處團(tuán)隊(duì))。
• 第二個(gè)區(qū)別是應(yīng)用程序使用緩存客戶(hù)端庫(kù)與緩存通信，這意味著我們不再局限于基于jvm的語(yǔ)言。有一個(gè)定義良好的協(xié)議，服務(wù)器部分的編程語(yǔ)言可以與客戶(hù)端部分不同。這實(shí)際上是許多緩存解決方案(如Redis或Memcached)僅為其部署提供這種模式的原因之一。

我之前提到過(guò)，嵌入式緩存和客戶(hù)機(jī)-服務(wù)器緩存的第一個(gè)區(qū)別是前者是單獨(dú)管理的。一個(gè)單獨(dú)的Ops團(tuán)隊(duì)甚至可以管理它，或者您可以更進(jìn)一步，將管理部分轉(zhuǎn)移到云計(jì)算中。

云端緩存

就架構(gòu)而言，云類(lèi)似于客戶(hù)機(jī)-服務(wù)器，不同之處在于服務(wù)器部分被移到組織之外，由云提供商管理，因此您不必?fù)?dān)心所有的組織問(wèn)題。

如果您對(duì)某個(gè)示例感興趣，可以在Hazelcast云平臺(tái)上創(chuàng)建一個(gè)Hazelcast集群，然后，您可以在這里找到一個(gè)完整的客戶(hù)機(jī)應(yīng)用程序。

最有趣的部分是Spring配置:

@Bean 
CacheManager cacheManager() { 
 ClientConfig clientConfig = new ClientConfig(); 
 clientConfig.getNetworkConfig().getCloudConfig() 
 .setEnabled(true) 
 .setDiscoveryToken("KSXFDTi5HXPJGR0wRAjLgKe45tvEEhd"); 
 clientConfig.setGroupConfig(new GroupConfig("test-cluster", "b2f9845")); 
 return new HazelcastCacheManager( 
 HazelcastClient.newHazelcastClient(clientConfig)); 
} 

使用客戶(hù)機(jī)-服務(wù)器模式很簡(jiǎn)單，使用云模式更簡(jiǎn)單。它們都帶來(lái)了類(lèi)似的好處，比如將緩存數(shù)據(jù)與應(yīng)用程序分離、獨(dú)立管理(向上/向下擴(kuò)展、備份)以及使用任何編程語(yǔ)言的可能性。然而，有一件事變得更加困難——延遲。對(duì)于嵌入式模式，緩存始終與應(yīng)用程序位于同一臺(tái)機(jī)器上(甚至在同一JVM中)。然而，當(dāng)服務(wù)器部分被分離時(shí)，我們現(xiàn)在需要考慮它的物理位置。最好的選擇是使用相同的本地網(wǎng)絡(luò)(或者在云解決方案中使用相同的VPC)。

現(xiàn)在，讓我們轉(zhuǎn)移到一個(gè)新的稍微不尋常的模式，緩存作為一個(gè)邊車(chē)。

邊車(chē)式緩存(Sidecar)

上面的圖表是特定于Kubernetes的，因?yàn)镾idecar模式主要出現(xiàn)在Kubernetes環(huán)境中(但不限于)。在Kubernetes中，部署單元稱(chēng)為POD。這個(gè)POD包含一個(gè)或多個(gè)容器，這些容器總是部署在相同的物理機(jī)器上。

通常，一個(gè)POD只包含一個(gè)容器和應(yīng)用程序本身。然而，在某些情況下，您不僅可以包含應(yīng)用程序容器，還可以包含一些提供附加功能的附加容器。這些容器稱(chēng)為邊車(chē)容器。

流程如下:

1.請(qǐng)求到達(dá)Kubernetes服務(wù)(負(fù)載平衡器)并被轉(zhuǎn)發(fā)到其中一個(gè)吊艙。

2.請(qǐng)求到達(dá)應(yīng)用程序容器，應(yīng)用程序使用緩存客戶(hù)機(jī)連接到緩存容器(從技術(shù)上講，緩存服務(wù)器總是在localhost上可用)。

這個(gè)解決方案混合了嵌入式模式和客戶(hù)機(jī)-服務(wù)器模式。

它類(lèi)似于嵌入式緩存，因?yàn)?

• 緩存始終與應(yīng)用程序位于同一臺(tái)機(jī)器上(低延遲)。
• 資源池和管理活動(dòng)在緩存和應(yīng)用程序之間共享。
• 緩存集群發(fā)現(xiàn)不是問(wèn)題(它總是在本地主機(jī)上可用)。

它也類(lèi)似于客戶(hù)機(jī)-服務(wù)器模式，因?yàn)?

• 應(yīng)用程序可以用任何編程語(yǔ)言編寫(xiě)(它使用緩存客戶(hù)端庫(kù)進(jìn)行通信)。
• 緩存和應(yīng)用程序有一些隔離。

現(xiàn)在讓我們討論一個(gè)完全不同的模式，反向代理。

反向代理緩存

到目前為止，在前面每個(gè)場(chǎng)景中，應(yīng)用程序都清楚自己使用了緩存。然而，這一次，我們將緩存部分放在應(yīng)用程序前面，所以流程如下:

1.請(qǐng)求進(jìn)入負(fù)載平衡器。

2.負(fù)載均衡器檢查這樣的請(qǐng)求是否已經(jīng)緩存。

3.如果是，則返回響應(yīng)，而不將請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用程序。

這樣的緩存解決方案是基于協(xié)議級(jí)別的，所以在大多數(shù)情況下，它是基于HTTP的，這有一些好的和壞的含義:

• 好的方面是，您可以將緩存層指定為配置，因此不需要更改應(yīng)用程序中的任何代碼。
• 不好的是，您不能使用任何基于應(yīng)用程序的代碼來(lái)使緩存失效，因此失效必須基于超時(shí)(以及標(biāo)準(zhǔn)HTTP TTL、ETag等)。

NGINX提供了成熟的反向代理緩存解決方案;然而，緩存中保存的數(shù)據(jù)不是分布式的，不是高可用性的，數(shù)據(jù)存儲(chǔ)在磁盤(pán)上。

我們可以對(duì)反向代理模式做的一個(gè)改進(jìn)是將HTTP反向代理注入到sidecar中。你可以這樣做:

反向代理邊車(chē)

同樣，當(dāng)涉及到Sidecar時(shí)，該圖僅限于Kubernetes環(huán)境。流程如下:

1.請(qǐng)求進(jìn)入Kubernetes服務(wù)(負(fù)載平衡器)并被轉(zhuǎn)發(fā)到其中一個(gè)pod。

2.在POD中，接收請(qǐng)求的是反向代理緩存容器(而不是應(yīng)用程序容器)。

3.反向代理緩存容器檢查這樣的請(qǐng)求是否已經(jīng)緩存。

4.如果是，則發(fā)送緩存的響應(yīng)(甚至不將請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用程序容器)。

應(yīng)用程序容器甚至不知道緩存的存在?？紤]一下本文開(kāi)頭介紹的微服務(wù)系統(tǒng)。使用此模式，我們可以查看整個(gè)系統(tǒng)并指定(在Kubernetes配置文件中)應(yīng)該緩存服務(wù)2v1和服務(wù)1。

前還沒(méi)有成熟的HTTP反向代理緩存Sidecar解決方案，然而，我相信它會(huì)變得越來(lái)越流行，因?yàn)橐恍╉?xiàng)目已經(jīng)在積極地進(jìn)行一些穩(wěn)定的實(shí)現(xiàn)。

優(yōu)點(diǎn)和缺點(diǎn)

我們提到了許多可以在微服務(wù)系統(tǒng)中使用的緩存模式。

優(yōu)缺點(diǎn)列表：