如何最好地将多个微服务的搜索服务与API网关集成
我们有一堆前面有API网关的微服务。我们创建了一个搜索服务，可以搜索服务并为客户端应用程序聚合数据。我们有两种方法可以做到这一点：
- 让 API 网关直接联系搜索服务，为其提供有关要搜索的微服务的上下文。 让 API 网关直接联系每个微服务（
- 我们目前已经在这样做），并让每个微服务自行处理联系（或不联系）搜索服务。
我喜欢第二种方法，因为它可以将搜索抽象完全隐藏在API网关之外，但由于每个微服务都负责联系搜索服务，因此可能会出现跨服务的搜索处理逻辑重复，我们希望避免这种情况，因为我们拥有的服务数量巨大。
您认为哪种模式更好？有没有比这些更好的架构可以利用？
共有1个答案
我不知道搜索服务的具体职责是什么，但如果如我想象的那样，是一个聚合其他服务信息以向用户显示的服务，我将使用以下两种方法之一来处理这个问题：
>
搜索服务是定期调用每个微服务的服务，询问需要的信息并相应地处理它。
如果搜索服务不知道何时会生成此信息，并且您希望近乎实时地更新它，而无需执行密集轮询的成本，我将使用消息代理，其中不同的微服务将使用信息生成事件，搜索服务将使用它们并相应地更新其信息
无论哪种方式，我都不会使用 API 网关作为业务流程协调程序来调用不同的微服务，因为 API 网关不应该了解业务逻辑，它的责任只是作为外部调用的单一入口点，也许是其他跨领域任务，如审计或授权
-
这种功能性应该如何实施？有关于这方面的指导方针或文章吗？
-
我正在尝试构建一个微服务架构。我已经了解了API网关的一些好处，比如：负载平衡、调用多个微服务并聚合结果、缓存管理等。所以我决定将它包含在我的系统中。 我的问题是，我应该在网关层还是在每个微服务endpoint单独实现授权？例如，在网关上验证用户，并以解密的形式将用户声明传递给每个服务调用的授权逻辑。 在调用每个服务之前授权一些聚合似乎是有意义的，并且节省了处理时间。然而，授权逻辑实际上是单个服务
-
我们能在Spring Cloud API网关和没有服务发现的情况下生存吗？
-
当我们部署到pcf时，Netflix eureka、zuul、ribbon、feign spring cloud配置不有用？（如果是，在pcf中有哪些可选方案以及如何配置它们？） 由于构建微服务遵循CI/CD方法，开发人员在推送代码之前如何验证其微服务的工作，因为我们在生产PCF中没有使用eureka、zuul、ribbon、feign。（如何在developer Machine中模拟pcf环境？
-
到目前为止，我还没有找到使用Blazor服务器（不是WebAssembly）和API网关和微服务的指导。讨论这些Blazor以及API网关和微服务的文章总是提到Blazor WebAssembly（Wasm）。（是不是假设Blazor Server应用程序不会使用微服务？此外，值得一提的是，选择Blazor服务器而不是Blazor WebAssembly的原因是为了更好地保护知识产权。） 无论如何
-
问题内容： 我实际上是在阅读有关微服务体系结构的文章， 但是，似乎他们正在以最简单的方式处理这些事情， 而无需进行深入的解释。 为了向您解释我的问题，我将向您展示我的实际小体系结构： 在此处输入图片说明 所以，这就是我要使用的。在技术上做任何事情之前，我需要更多的 理论信息。 我的网域描述 我有一些基于移动和浏览器的客户，他们能够在 应用程序上建立联系，获得他们的用户信息，并能够查询 有关所购