我有三个微服务，比如说 Facebook、Google、LinkedIn。它们都有一些共同的功能，但根据其 API 的不同，实现方式也有所不同。此外，数据库表是特定于该微服务的，如 tbl_google、tbl_facebook、tbl_linkedin。现在，所有服务都具有简单的 CRUD api，用于像用户所说的特定功能。
虽然添加、编辑、删除不是问题，但正如特定 API 请求所述，POST /api/google/user 将命中 google 微服务并请求创建 google 用户。放置、删除相同。他们还列出了 GET API，它提供了启用分页、过滤和排序的该服务的用户列表。
但问题是，我需要创建一个 API，它将按最新添加的默认顺序获取所有用户数据，并且还可以应用一些可选的过滤器。现在我认为没有更简单的最佳解决方案可以实现这一目标。我想到了这种方法，但并不完全相信。
a）从每个 API 获取所有过滤后的数据，然后对它们进行组合、排序/分页可能不起作用，因为过滤后的数据仍然很大（数千、数十万行）。
b) 从每个 api 获取分页/过滤/排序数据并将它们组合起来可能不起作用，因为实际上最新 30 条记录中的 28 条可能来自单个服务，但逻辑将为每个服务获取 10 个用户。
c) 使用公用表。他们有一些技术障碍来实现这一目标。但除此之外，我也不喜欢维护公共表的想法，而大多数列可能是特定于服务的，所以我什至可能需要将表分成多个表来实现公共表解决方案，如 tbl_common、tbl_facebook、tbl_google 其中需要将数据同步/保存到两个不同的表中。
d）数据库视图，这似乎是一个更好的主意。因为建议使用视图作为读取解决方案。但在微服务的背景下，不完全确定
我不想涉及第三方高架构解决方案，只想通过代码/DB逻辑本身来实现这一点。
示例数据
Google Service
[{id: 1, name: "Google User 1", role: "Supervisor", added_at: "2024-01-20"}, {id: 2, name: "Google User 2", role: "Manager", added_at: "2024-01-18"}, {id: 3, name: "Google User 3", role: "Support", added_at: "2024-01-03"}, {id: 4, name: "Google User 4", role: "Manager", added_at: "2024-01-22"}]
Facebook Service
[{id: 1, name: "Facebook User 1", role: "Manager", added_at: "2024-01-23"}, {id: 2, name: "Facebook User 2", role: "Tech", added_at: "2024-01-12"}, {id: 3, name: "Facebook User 3", role: "Sales", added_at: "2024-01-24"}]
LinkedIn Service
[{id: 1, name: "LinkedIn User 1", role: "Manager", added_at: "2024-01-11"}, {id: 2, name: "LinkedIn User 2", role: "Tech", added_at: "2024-01-10"}, {id: 3, name: "LinkedIn User 3", role: "Manager", added_at: "2024-01-09"}]
Required Results :
[
{id: 1, name: "Facebook User 1", role: "Manager", added_at: "2024-01-23", type: "Facebook"},
{id: 4, name: "Google User 4", role: "Manager", added_at: "2024-01-22", type: "Google"},
{id: 2, name: "Google User 2", role: "Manager", added_at: "2024-01-18", type: "Google"}.
{id: 1, name: "LinkedIn User 1", role: "Manager", added_at: "2024-01-11", type: "LinkedIn"},
{id: 3, name: "LinkedIn User 3", role: "Manager", added_at: "2024-01-09", type: "LinkedIn"}
]
根据提供的描述，您似乎实际上在服务之间共享数据库。虽然共享数据库是一种模式，在微服务架构中并不罕见，但总的来说，我认为它实际上是一种反模式，应该尽快解决，因为它会导致服务之间的耦合，应该避免.
可以提出的另一点是，这里不应该有 3 个不同的服务，而只能有一个（用户）。但如果没有全面概述导致当前设计的原因，就很难说清楚。
我会考虑的选项：
最“微服务”的方法可以是引入一种新服务——用户将结合这 3 个服务的共享数据并维护一些逻辑来区分它们。理想情况下，它将使用某种异步方式来维护数据副本来处理更改（即，将“最终一致”，就像微服务架构中经常所做的那样）
，例如每个层次结构表（TPH） 、每个类型一个表 (TPT) 和每个具体类型一个表 (TPC)（某些 ORM 甚至开箱即用地支持它 - 例如 .NET 的 EF Core） 意见。它应该是最容易实现的选项，因为公共表方法不可用。虽然您对此的担忧是有道理的，并且这种方法不太适合微服务架构，但一般来说共享数据库是适合的。如果您应该走这条路，很大程度上取决于应用程序/项目的下一步计划是什么以及可用的资源是什么。