使用拥有自己数据库的微服务进行聚合、排序、过滤和分页

Question

方法和要求： 我们有一个使用 Sql Server 数据库在 ASP.Net Core 中开发的微服务架构，其中每个微服务都有自己的 SQL 数据库，并且不允许我们进行跨微服务通信来聚合数据并将数据从微服务发送回 api 网关和进一步回到 UI（浏览器）。

我们的浏览器有一个数据网格，需要从不同的微服务聚合数据后显示数据，例如一个数据网格必须显示客户姓名、地址、预订参考号。电话号码、国家/地区名称、酒店名称、酒店地址、酒店费用和其他更多详细信息。

上面的数据网格中还有一个功能，可以根据其中的每一列对上面的网格数据进行排序；根据不同的列值过滤网格也是一个要求。此外，我们还需要在同一网格中进行分页，页面大小为 10 条记录。

目前，据我所知，数据聚合必须发生在 API 网关层，并且在其之上必须应用排序、过滤和分页功能。

我们使用 EF Core 2.0 作为数据 ORM，将数据发送回微服务并进一步响应。

问题1：

哪一层（UI、API 网关、微服务）应该执行这种排序、过滤和分页功能，以便获得最佳性能和更好的用户体验？

问题2：

是否有可能所有参数（例如排序顺序、排序列名称、页面大小、页码、筛选列名称、筛选列值）都应始终从 API 网关层发送到微服务 api，并成功实现所有功能而没有任何延迟以及读取操作的最佳性能？

问题3：

我们创建一个粗粒度的微服务来代替上述选项，对数据进行聚合、排序、过滤和分页，而不是 API 网关层进行聚合（目前 API 网关仅在其他微服务中进行聚合），这是一个好的模式吗？ ？

Answer 1

1) 这取决于数据的性质。例如，如果您有一个核心服务，其中包含要对数据进行分页和排序的数据，那么该服务应该执行此操作。一个示例是，您希望按排序顺序显示用户的酒店预订。因此，您可能有 3 项服务来托管预订、用户和酒店信息。在这种情况下，进行分页的核心服务是预订服务。您检索预订数据，然后用酒店+用户信息补充每个预订。

2）延迟永远存在。微服务的整个想法会引入延迟，因为您正在添加更多的网络交互。但这是抽象和快速迭代的成本。然而，这些问题可以通过缓存和数据库改进来解决。此外，如果您对结果进行分页，无论如何数据都应该受到限制，因此性能不应成为问题

3）是的，绝对有可能，这实际上是一种很常见的模式