在客户端应用程序中，我们将monotith系统的各个部分移动到微服务架构。它以一种非常简单的方式看起来如此： - 核心应用程序拥有自己的产品数据库 - 微服务拥有自己的数据库，其中包含各种对象，可能与产品有关。
场景1： 我们想要展示产品＆＃34; Apple＆＃34;在页面上，与微服务的相关数据。 这很容易：只是得到＆＃34; Apple＆＃34;从core-app数据库中，从微服务中检索此产品的其他数据。好。
场景2： 我们希望显示具有核心应用程序数据库的各种条件的产品列表以及微服务数据库的其他条件。怎么做？ 我应该从数据库（核心应用程序）获得1000个产品，并为这些产品调用微服务以获取更多数据吗？但是怎么样？我应该发送一个包含1000个ID或1000个API调用的查询，还是从API服务中获取部分数据，例如10个API调用100个项目？我不喜欢这些选项。
场景3： 我们有＆＃34;仓库＆＃34;微服务。
我想要按名称排序的前100个产品的列表，升序，在仓库中有可用的标志= true。怎么做？如果我从core-app db获得100个产品然后调用API来检查标志，那么最终产品列表可能低于100。 获取仓库中所有可用项目的列表是一个坏主意，因为可能有数百万项，因此执行时间和API响应大小是不可接受的。
一般来说，我需要一个想法，如何合并来自一个数据库的一些数据和来自其他数据库的一些数据，并将其返回给用户视图。
该应用程序是用PHP编写的，但也许有些在J2EE方面有经验的人知道这些问题的解决方案吗？
编辑：我发现：http://microservices.io/patterns。我会仔细看看它。答案 0 :(得分：0)
首先，虽然对我而言，一般来说，微服务应该处理给定的有界上下文/域。所以我想知道这是什么＆＃39;额外的＆＃39;您要添加到产品中的数据，以及它是否也不属于产品微服务。
如果你确定它不应该是，那么这些是不同的域，那么这就是你的API设计的问题。如果您预测经常查询具有1000个ID的另一个微服务，请构建一个可以处理1000个ID（或者最好是ID列表的任意长度）的API。
对于方案3 - 如果我得到这样的任务，我会创建一个处理排序和过滤的API，这样数据库所有的那些操作都将由数据库处理。
一般来说，我的pov是API应该由您的业务需求驱动，并且不应该限制您快速提供高质量的解决方案。因此，如果简单的CRUD API不适用于您（并且它很少），只需更改它。