Architecture 微服务：跨不同服务进行过滤

在我当前的项目中，我们有两个具有两个不同DB实例的微服务，它们都有引用相同底层资源的表，尽管名称不同，也就是说，服务A的DB中的资源表称为foo，而服务B的DB中的资源表称为bar

写入操作使用两个服务发送，每个服务负责在更新/写入/删除时写入另一个服务，暂时忽略网络/DB故障

每个服务负责资源的不同信息，因此每个表包含包含相同资源的不同信息的不同列。例如：服务A具有属性health_state，而服务B具有属性[和列]存档

我们希望允许用户同时按服务列/属性进行筛选，即GET/foo？search=health\u state='unchronical'和archived='false'。一个人怎么做呢

我们最初的想法是让一个微服务成为另一个的前端，并支持搜索这两个服务的领域。然后A将相关的搜索字段发送给B，并将结果加入A的数据库中。如果B的结果集很大，这是一个可能无法很好扩展的选项，这是因为A需要上面示例中的所有存档资源才能进行连接。此外，搜索查询的解析可能非常复杂。如果我们采取这种方法，有没有关于如何大规模地这样做的建议

请记住，将我们的应用程序移植到像前面提到的CQR这样的东西似乎是一个巨大的变化，目前相应的DB中有10K+行

---

感谢您的回复

您可以看看GraphQL。您可以将两个不同应用程序的输出缝合在一起以生成结果。这是一个众所周知的可扩展解决方案，您还可以在graphql服务器上应用缓存来提高性能

这是一个很好的起点

---

我还建议您重新审视服务设计，因为对相同资源的过滤通常应该在相同的服务中完成，除非它是通道服务。如果可以近实时访问数据，那么在弹性搜索中为数据编制索引，然后检索也是另一种选择。

为什么您首先需要两种不同的服务？为什么不使用一个微服务来管理资源呢？如果出于某种原因需要，CQRS方法可能是您唯一的选择。@酷，我同意整体式可能是一个不错的选择。但是这个架构是在我加入这个项目之前决定的。如果你真的有可伸缩性的需求，我建议你将它们结合起来，因为数据仍然很小。结合这两个服务或者转移到CQRS——我认为现在这两个选项对我们都不相关。Graphql部分是误导性的，因为它对实际问题没有任何好处。为什么不呢？您可以将API和apply filter的输出结合起来。如果第一个API的输出返回100万行怎么办？我同意这可能是一个问题，但如果它不返回呢？因此，我建议重新设计，因为CQR似乎是一个很大的变化。如果属性不经常更改/记录数量较少，我认为具有良好缓存策略的graphql可以工作