正在使用微服务实现系统。为了减少在架构中“在同一级别”实现的微服务之间的交互，某些微服务将在本地缓存由其他服务管理的表的副本。假设是本地缓存的表（a）由微服务以“读取模式”频繁访问，并且（b）具有相对静态的内容（即，更多的“查找表”与事务性内容）。
本地缓存将使用服务间消息传递来保持同步。由于内容应该是相当静态的，因此这不是一个重要的问题/工作量。但是，在微服务启动时，本地缓存可能已过时。
我想在源表上实现某种滚动版本号，以便具有本地缓存的微服务可以检查此版本号，从而有可能避免重新同步事件。
这种方法是否有“最佳实践”？或者，考虑到每个微服务都由其自己的数据库（即没有共享数据库）支持，是“更好的选择”吗？
答案 0 :(得分：0)
我认为您不应该在启动时加载数据。维护版本可能有点复杂。
缓存备用模式
通常在微服务体系结构中，您会考虑“缓存模式”。您不是在前端而是根据需要构建缓存。收到请求时，请检查缓存，如果不存在，则使用最新值更新缓存并返回响应，从那里总是从缓存中返回。好处是您不需要先加载所有内容。假设您有200条记录，而服务仅经常使用其中的50条记录，那么您正在维护可能不需要的额外缓存。
让请求建立缓存，这是数据库命中一次。您可以在缓存上设置过期时间，然后传入请求再次构建它。
如果您的数据完全是静态的（从未更改过），则此模式可能不值得讨论，但如果您的查找表每周，每月甚至可以更改一次，则应该使用此模式具有更长的缓存过期时间。维护版本可能会很昂贵。但实际上取决于您如何实现。
https://docs.microsoft.com/en-us/azure/architecture/patterns/cache-aside
答案 1 :(得分：0)
我们遇到了同样的问题，并通过使用LastUpdated时间戳比较（与VersionNumber相同的概念）暂时解决了该问题。每天晚上（当我们的应用程序运行缓慢时），每个服务都会发布一条ServiceXLastUpdated消息，其中包括添加/编辑其拥有的数据时的最新时间戳。订阅此数据的任何其他服务都将处理该消息，如果存在不匹配，则自上次本地更新以来，它会请求“触摸”所有行，以便可以恢复同步。
对于我们来说，目前还可以，因为新服务通常不会在线上并在同一天使用。但是，我们的未来计划是，每当服务启动时，它都可以为每个订阅的服务发布一条消息，指示该消息是最新的缓存更新时间戳。如果“源”服务发现时间戳不是最新的，则它可以发送更新以重新同步数据。这样的优点是，即使（至少对我们而言）所有订阅的服务都可以访问消息，也仅将所需的更新发送到需要更新的特定服务。
我们从使用持久性队列开始，因此，如果微服务的所有实例都关闭，则消息只会在其队列中累积。有两个问题使我们可以做得更好：
1）显然没有解决“首次启动”的问题，因为没有队列可以在其中建立消息
2）如果在存储排队的消息或处理它们时出现任何错误，则最终将导致不同步。如果发生这种情况，您仍然需要像我们现在这样使事情恢复同步的主动机制。所以，这条路线似乎很值得
我不会说我们的方法是“最佳实践”，如果有的话，我不会意识到。但是，到目前为止，我们的工作方式（包括计划中的未来工作）已证明易于构建，易于理解和监控，并且功能强大，因为极少会发生由本地数据不同步引起的事件。