跨服务共享轴突查询
sharing axon queries across services
我有三个不同的服务（A、B 和 C）运行 并且都连接到 axonserver 4.3.3。除了它们，我还有一个 api 服务，它包含所有事件，以便它可以在所有服务之间共享。当一个事件被触发时（比如服务 A），它正在被其他服务（B 和 C）监听，并且它们会做出相应的反应。
现在我也想分享查询，这样当一个服务（假设 A）想要一些属于另一个服务（假设 B）的信息时，它可以直接触发相应的查询，该查询将被服务 B 和将 return 信息。
- 在 axon 中是否允许（即在服务之间共享查询，就像我们对事件所做的那样）？
- 如果允许，它是否遵循轴突最佳实践？
- 如果不allowed/doesn不遵循最佳实践，替代解决方案是什么？
UPDATE
我只是将查询添加到 common-api 服务并从服务 A 中触发它，如下所示：
- 当我使用
queryGateway.query( findCourierByIdQuery, responseType) 时：我得到查询处理程序未找到异常
- 当我使用
queryGateway.subscriptionQuery( findCourierByIdQuery, initialResponseType, updateResponseType)时：我什么都没有
- 当我使用
queryGateway.scatterGather( findCourierByIdQuery, responseType, timeout, timeUnit) 时：我得到一个空流
当我从服务 B 本身触发 findCourierByIdQuery 时，查询处理程序被调用并且我得到了正确的响应。
我的观察是，仅当从同一组件（在本例中为服务 B）触发查询时才会调用查询处理程序，如果我从其他组件触发查询则不会调用它（服务 A).
注意，所有服务运行独立于不同的主机和端口，但连接到同一个axonserver，queryhandler写在服务B中。
所以基本上实现是这样的：
- findCourierByIdQuery 在公共 api 服务中定义。
- 服务 A 和 B 具有公共 api 服务的依赖性。
- 服务 A 查询 findCourierByIdQuery。
- 服务 B 具有 findCourierByIdQuery 查询处理程序实现。
我觉得这完全没问题！
Axon 使用三种类型的消息：命令、事件和查询。它们代表您的服务 API。
下游服务（在您的情况下为 B&C）可以发送命令、订阅事件或发送（和订阅）上游服务的查询（在您的情况下为 A）。简单地说，B&C 依赖于 A。如果可能，使这种依赖单向（只有 B 依赖于 A，而不是相反）很重要。
通常，您希望在下游服务 (B&C) 的边缘有一个 anti-corruption layer component。它可以将来自上游服务 (A) 的事件转换为自己的命令，也可以将自己的事件转换为上游服务 (A) 的命令。这是 Saga 或常规事件处理程序（处理器）。
如果您对查询感兴趣，那么您的 anti-corruption layer component 将使用查询网关从上游服务 (A) 发出（订阅）查询，并希望以自动方式将响应转换为命令，类似于我提到的 Saga/Event 处理程序。通常，这种基于查询 API 的集成不是完全自动化的：从查询到命令的转换涉及用户。在这种情况下，服务 B（下游）正在使用（服务 A 的）查询响应来呈现用户可以从中发出下一个命令（服务 B）的视图
在下游系统中拥有 anti-corruption 层组件将使您的服务自治。
最好的，
伊万
我有三个不同的服务（A、B 和 C）运行 并且都连接到 axonserver 4.3.3。除了它们，我还有一个 api 服务，它包含所有事件，以便它可以在所有服务之间共享。当一个事件被触发时（比如服务 A），它正在被其他服务（B 和 C）监听，并且它们会做出相应的反应。
现在我也想分享查询，这样当一个服务（假设 A）想要一些属于另一个服务（假设 B）的信息时，它可以直接触发相应的查询，该查询将被服务 B 和将 return 信息。
- 在 axon 中是否允许（即在服务之间共享查询，就像我们对事件所做的那样）？
- 如果允许，它是否遵循轴突最佳实践？
- 如果不allowed/doesn不遵循最佳实践，替代解决方案是什么？
UPDATE
我只是将查询添加到 common-api 服务并从服务 A 中触发它，如下所示：
- 当我使用
queryGateway.query( findCourierByIdQuery, responseType)时：我得到查询处理程序未找到异常 - 当我使用
queryGateway.subscriptionQuery( findCourierByIdQuery, initialResponseType, updateResponseType)时：我什么都没有 - 当我使用
queryGateway.scatterGather( findCourierByIdQuery, responseType, timeout, timeUnit)时：我得到一个空流
当我从服务 B 本身触发 findCourierByIdQuery 时，查询处理程序被调用并且我得到了正确的响应。
我的观察是，仅当从同一组件（在本例中为服务 B）触发查询时才会调用查询处理程序，如果我从其他组件触发查询则不会调用它（服务 A).
注意，所有服务运行独立于不同的主机和端口，但连接到同一个axonserver，queryhandler写在服务B中。
所以基本上实现是这样的：
- findCourierByIdQuery 在公共 api 服务中定义。
- 服务 A 和 B 具有公共 api 服务的依赖性。
- 服务 A 查询 findCourierByIdQuery。
- 服务 B 具有 findCourierByIdQuery 查询处理程序实现。
我觉得这完全没问题！
Axon 使用三种类型的消息：命令、事件和查询。它们代表您的服务 API。 下游服务（在您的情况下为 B&C）可以发送命令、订阅事件或发送（和订阅）上游服务的查询（在您的情况下为 A）。简单地说，B&C 依赖于 A。如果可能，使这种依赖单向（只有 B 依赖于 A，而不是相反）很重要。
通常，您希望在下游服务 (B&C) 的边缘有一个 anti-corruption layer component。它可以将来自上游服务 (A) 的事件转换为自己的命令，也可以将自己的事件转换为上游服务 (A) 的命令。这是 Saga 或常规事件处理程序（处理器）。
如果您对查询感兴趣，那么您的 anti-corruption layer component 将使用查询网关从上游服务 (A) 发出（订阅）查询，并希望以自动方式将响应转换为命令，类似于我提到的 Saga/Event 处理程序。通常，这种基于查询 API 的集成不是完全自动化的：从查询到命令的转换涉及用户。在这种情况下，服务 B（下游）正在使用（服务 A 的）查询响应来呈现用户可以从中发出下一个命令（服务 B）的视图
在下游系统中拥有 anti-corruption 层组件将使您的服务自治。
最好的， 伊万