提供以下三项服务：
将所有这些组合在一起是一项BFF服务，该服务协调所有需要做出的请求，以便向客户提供有关哪些产品符合其标准，哪些产品可用以及价格如何的信息。随着时间的流逝，产品的数量将达到数百种，甚至数千种。每个请求都会返回一页产品（例如，每100个产品中有10个）。
当客户搜索产品时，将调用BFF服务，该服务将依次列出列出的三个服务。
问题 产品需要分类。第一个要求是价格。价格是： 1.存储在其他服务中 2.使用各种算法确定（甚至可以是动态确定的价格，即“个性化”价格）
问题 我们如何根据价格排序？我对一些不太好的解决方案有一些想法。但是，从可能解决了该问题的其他人那里寻求更多的投入。 Booking.com做类似的事情...
答案 0 :(得分：-1)
我了解您希望几乎实时地显示一致的数据。我会考虑以下选项：
重新考虑您的微服务组成。也许在当前设计中它们太小了。尽管您提到的所有微服务都与产品实体紧密结合。但是当然，这取决于许多因素，我在这里将不介绍它们，并且我对您的系统不够了解，无法提出这样的建议。
合并BFF服务中的所有三个源。排序/分页可以应用于合并值的顶部。原始的合并结果可以被缓存，以避免每个页面不断的API往返。我猜价格不会经常改变，因此这可能是一个可行且简单的解决方案。
即使产品的数量只有几千个，内存内缓存也应该足以应付需要。
构建用于读取的专用模型（换句话说，就是复制数据）。如果BFF负责提供读取模型，则它可以侦听域事件，例如“价格已更改”，“产品已添加”，“产品已删除”，并建立自己的异步读取模型。这样就可以使用单个数据库查询来构建分页视图。
您还可以结合使用2 + 3，并使缓存机制了解域事件。某些事件可能会使整个缓存或部分缓存无效（例如，单个产品）。
我假设您的微服务具有自己的专用数据库。您可以公开一个跨数据库视图，以在单个数据库查询中提供所需的功能。微服务的传播者会说这是一种邪恶的反模式。嗯，是的，但是如果您知道自己在做什么，那可能是一个务实的选择，我不会删掉。
我提到的每种选择都有其优缺点。如果没有更广泛的生态系统知识，就很难判断哪种方法最适合您。