基于事件源的微服务响应聚合机制
在实现基于事件源的微服务时，我们遇到的主要问题之一是聚合响应数据。例如，我们可能有两个实体，如学校和学生。一个微服务可能负责处理学校相关的业务逻辑，而另一个微服务可能处理学生。
现在，如果有人通过RESTendpoint进行查询并询问某个特定的学生，他们可能希望了解学校和学生的详细信息，那么对我来说，唯一已知的方法是以下方法。
>
使用类似于服务链接的东西。一个例子是Api-Gateway在向几个微服务发出几个请求后聚合响应。
在所有服务中复制所有内容。基本上，数据是重复的。
让服务相互调用这些额外的信息。这个解决方案虽然有效，但很难扩展，并且违背了使用事件源的基本思想。
我的问题是还有什么其他方法可以做到这一点？
共有1个答案
一个更好的方法是创建一个单独的报告/搜索服务，该服务聚合来自这两个服务的数据。例如，使用ElasticSearch或SOLR实现。这现在允许用户跨多个服务和聚合进行搜索和查询。
当然，它最终会保持一致，但我怀疑这是个问题。这可以更好地分离关注点，同时为用户提供良好的搜索体验。
-
我一直在读关于微服务和事件来源的文章，以及它是如何将服务从另一个服务中分离出来的。有两个概念我不清楚。首先，如果在微服务体系结构中，每个服务都可以独立开发，我们如何解释服务间的通信依赖？ 例如，如果服务A和服务B需要通信，那么A需要将一个事件发送到一个中央总线，而B需要监听该事件并根据该事件采取行动，但这似乎会产生很多依赖关系。现在，如果我正在开发服务B，我需要知道服务A可以生成的所有事件。此外，
-
我是事件采购的新手，但对于我们当前的项目，我认为这是一个非常有前途的选择，主要是因为审计跟踪。 有一件事我不是100%满意，那就是缺乏跨聚合的超越。请考虑以下问题： 我有一个订单，它在不同的机器上处理，在不同的车站。我们有集装箱，工人们把订单放进去，然后把它从一台机器运到另一台机器。 必须通过容器（具有唯一的条形码id）进行跟踪，订单本身无法识别。问题是：容器是重用的，需要锁定，因此没有工作人员可
-
我们有一个登录后显示的用户仪表板。仪表板由多个小部件组成。每个小部件从单独的restful服务中提取内容。例如：新闻/邮件/问题/警报。每个小部件在加载到页面上后调用服务。这样就有多个webservice调用。 有没有办法减少多次通话。 它的工作方式是当第一次加载页面时，服务应该在单个调用中返回所有小部件的聚合数据。 每个服务也应该独立可用，以便可以用于刷新单个小部件和其他系统集成。 注意：小部件
-
脚本 我正在使用微服务构建快递服务系统。我不确定一些事情，这是我的场景 预订API-这是客户下订单的地方 付款API-这是我们处理预订付款的地方 通知API-有服务负责在一切完成后发送通知。 系统采用事件驱动架构。当客户下预订订单时，我在预订应用编程接口中提交本地交易并发布事件。支付应用编程接口和通知应用编程接口订阅了各自的事件。一旦完成，支付和通知应用编程接口需要向预订应用编程接口确认。 我的问
-
我有两个微服务，用户微服务和订单微服务。 因此客户端只需要调用一个endpointhttp://localhost:9090/api/getdetail 我们如何在API网关级别实现这一点？
-
我已经意识到事件源、CQRS、DDD和微服务有一段时间了，现在我想尝试并开始实施一些东西并尝试一些东西。 我一直在研究CQRS的技术方面，我理解其中的DDD概念。写入端如何处理来自UI的命令并发布其中的事件，以及读取端如何处理事件并在其上创建投影。 我遇到的困难是沟通 所以我想重点关注eventstore（这一个：https://eventstore.com/不那么模棱两可）。这就是我想要使用的，