具有自己数据库的微服务的聚集，排序，过滤和分页

Posted 2021-03-27

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

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

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

目前，据我所知，数据聚合必须在API网关层中进行，并且最重要的是必须应用排序，过滤和分页功能。

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

问题1：

哪个层（UI，API网关，微服务）应该执行此排序，过滤和分页功能，使其具有最佳性能性能和更好的用户体验？

问题2：

是否可能所有参数（例如排序顺序，排序列名称，页面大小，页码，过滤器列名称，过滤器列值均应总是从API网关层发送到微服务api，并且成功实现所有功能而没有任何延迟，并且读取操作中的最佳性能？

问题3：

这是一种好模式，我们代替上面的选项，创建一个粗粒度的微服务，用于进行汇总，排序，过滤和分页数据而不是API网关层正在进行聚合（当前API Gateway仅在其他微服务中进行聚合）？

答案

1）这取决于数据的性质。例如，如果您具有要分页和排序的数据的核心服务，则该服务应执行此操作。一个示例是您要按排序的顺序显示用户的酒店预订。因此，您可能有3种服务来托管预订，用户和酒店信息。在这种情况下，进行分页的核心服务是预订服务。您检索预订数据，然后为每个预订添加酒店+用户信息。

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

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