微服务架构中缓存模式 _微服务架构

在微服务世界中，每个人都使用缓存，缓存无处不在。缓存可以提高性能，减少后端负载，或者减少down机时间。有许多方法可以配置系统中的缓存，缓冲应该被放在系统的哪个层上?根据以往成功经验，系统中您应该只在一个地方使用缓存。不应该同时在多个层中组合模式和缓存，例如同样的内容在HTTP层和应用程序级别同时做缓存。这种方法可能导致更多的缓存失效问题，并使您的系统更容易出错，且难于调试。
如果您在一个特定的层上使用缓存，那么您可以选择使用哪种模式。最保守的方法是老式的客户机-服务器(或云)模式，这个问题的正确答案不止一个。您可以将缓存放在每个服务中，或者作为一个完全独立的缓存服务器。您还可以将它放在每个服务的前面，甚至作为属于服务的sidecar容器等等。本文下面，让我们总结一下您在微服务世界多种方式的缓存体系结构。
嵌入式缓存最简单的缓存模式是嵌入式缓存。

文章插图
嵌入式缓存
在上图中，流程如下:
1.请求进入负载平衡器。
2.负载均衡器将请求转发给应用程序服务之一。
3.应用程序服务接收请求，并检查是否相同的请求已经执行(并存储在缓存)?
如果是，然后返回缓存数据。反之，则执行业务操作，并把结果数据存储在缓存中，并返回结果数据。
业务操作可以是任何值得缓存的内容。例如，执行计算、查询数据库或调用外部web服务等。
这种缓存逻辑非常简单，我们可以使用内置的数据结构或一些缓存库(如Guava cache)为其快速编写代码。我们还可以将缓存放在应用程序层中，并使用大多数web框架提供的缓存功能。例如，对于Spring ，添加缓存层只需要向方法添加@Cacheable注释。
嵌入式缓存方法有一个严重的问题。假设有一个向我们的系统发出的请求，它第一次被转发到顶部的应用程序服务A 。然后，同样的请求出现，但这一次负载平衡器将其转发给底部的应用程序服务B 。这种情况下，我们收到了两次相同的请求，但是必须执行两次业务逻辑，因为图中的两个缓存是分别完成的。为了处理这样的问题，可以使用嵌入分布式缓存。
嵌入分布式缓存