【发布时间】：2017-11-30 20:57:31
【问题描述】：
我们有一个单体系统，我们目前正在使用 gRPC 将其分解为微服务。目前，我们在单体代码的 C# 客户端中使用 enyim 缓存。
在创建我们的第一个 gRPC 服务时，我们对缓存层应该在哪里感到困惑：
- 是否应该将其移至此服务的 gRPC 服务代码？这样每个服务都会有它的缓存代码。这会导致大量重复的缓存代码。
- 我们是否应该创建用于缓存相关代码的 dll 并在新的 gRPC 微服务中使用它？我们仍然需要在每个 gRPC 服务中放置重复的配置。
- 仅处理单体代码中的缓存并仅在缓存未命中的情况下调用 gRPC 服务？
建议？
【问题讨论】：
-
这是一个非常有趣的问题，但我的想法是 grpc 只是关于传输层，应用层中的任何东西，如 authn/r、缓存，都应该在类似网关的东西中处理。
-
是的@chenrui，将它放在 API 网关中看起来更好。那么，服务应该只提取数据，对吗？您是否有任何好的链接建议不要在服务级别使用缓存并将其放在网关上？
-
老实说，您提到的所有方法都可能根据具体情况而适用，并且在不了解有关您的系统的更多详细信息的情况下，无法确定哪种方法是“最佳”的。其他人的说法是正确的，您还应该研究在中间层（如网关）中添加缓存 - 但使用这种缓存的能力取决于您的请求的性质（它们需要是幂等的）。
标签： c# caching microservices grpc