多微服务跨源用户数据合并查询的最优实现方案咨询

我有三个微服务（Facebook、Google、LinkedIn），它们具备部分通用功能，但API实现逻辑和专属数据库表（tbl_google、tbl_facebook、tbl_linkedin）各不相同，每个都提供User模块的CRUD接口。单服务的增删改、带分页/过滤/排序的用户列表查询均正常运行。

当前需要开发一个合并查询API，需求如下：

• 默认按added_at倒序返回所有微服务的用户数据
• 支持可选过滤条件

我自行设想的几种方案均存在缺陷：

• 方案a：从各API拉取所有过滤后的数据，再合并、排序、分页 → 数据量大（数千/数十万条）时完全不可行
• 方案b：从各API拉取分页/过滤/排序后的数据再合并 → 结果会出现偏差，比如实际前30条最新记录里28条来自同一服务，但该方案仅从每个服务拉取10条
• 方案c：使用通用表 → 存在技术障碍，且各服务字段差异较大，需拆分多张表（如tbl_common、tbl_facebook等）并维护数据同步，成本过高
• 方案d：使用DB Views → 适合只读场景，但不确定在微服务架构下的可行性

希望仅通过代码或数据库逻辑实现需求，不引入第三方高端架构方案。

示例数据 #

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"
}]

预期结果（过滤role=Manager后） #

[
    {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"}
]

可行解决方案 #

方案1：数据库层面联合查询（支持跨库访问场景） #

如果三个微服务的数据库允许跨库查询（如同属一个集群或通过数据库链路打通），直接用SQL的UNION ALL实现整合查询：

SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'Google' AS type 
FROM tbl_google 
WHERE role = 'Manager' -- 动态替换过滤条件
UNION ALL
SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'Facebook' AS type 
FROM tbl_facebook 
WHERE role = 'Manager'
UNION ALL
SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'LinkedIn' AS type 
FROM tbl_linkedin 
WHERE role = 'Manager'
ORDER BY added_at DESC
LIMIT 10 OFFSET 0; -- 分页参数

优势：利用数据库优化能力，性能最优，不会出现结果偏差问题。
注意：需保证各表字段类型兼容（如added_at统一为DATE/DATETIME类型），字段名不一致时需用别名统一。

方案2：代码层面"预查询+精准拉取"策略（仅API访问场景） #

如果无法跨库访问，只能通过API调用，可按以下步骤实现：

1. 预查询各服务的时间边界与统计数据：向每个服务请求满足过滤条件的max_added_at、min_added_at及总记录数。
2. 估算全局分页的时间区间：根据用户分页参数，确定需要覆盖的时间范围，向各服务拉取该区间内的符合条件数据。
3. 合并排序后截取分页结果：将各服务返回数据合并，按added_at倒序排序，再截取对应分页的结果。

优化点：若首次拉取数据量不足分页需求，扩大时间范围继续拉取，直到满足数量或确认无更多数据；缓存各服务时间边界，减少重复查询。

示例伪代码：

def get_merged_users(filter_params, page=1, page_size=10):
    service_clients = [GoogleClient(), FacebookClient(), LinkedInClient()]
    all_data = []
    
    # 1. 获取各服务过滤后的统计信息
    service_stats = []
    for client in service_clients:
        stats = client.get_filtered_stats(filter_params)
        service_stats.append((client, stats))
    
    # 2. 从最新时间开始拉取数据，直到满足分页需求或无更多数据
    target_count = page * page_size
    current_end_time = max([s[1]['max_added_at'] for s in service_stats])
    earliest_time = min([s[1]['min_added_at'] for s in service_stats])
    
    while len(all_data) < target_count and current_end_time >= earliest_time:
        for client, stats in service_stats:
            data = client.get_filtered_data(filter_params, end_time=current_end_time)
            all_data.extend([{**item, 'type': client.service_name} for item in data])
        # 每次往前推7天缩小时间范围，可根据业务调整
        current_end_time = subtract_days(current_end_time, 7)
    
    # 3. 排序并分页
    sorted_data = sorted(all_data, key=lambda x: x['added_at'], reverse=True)
    start_idx = (page - 1) * page_size
    end_idx = start_idx + page_size
    return sorted_data[start_idx:end_idx]

优势：避免拉取全量数据，同时保证结果准确性，不会出现方案b的偏差。
注意：需各服务支持按时间范围过滤的API，且统一时间格式。

方案3：基于DB View的整合（支持跨库访问场景） #

如果允许跨库访问，可创建联合View整合三个表的数据，后续直接查询View即可：

CREATE VIEW vw_all_users AS
SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'Google' AS type,
    NULL AS facebook_specific_field,
    NULL AS linkedin_specific_field
FROM tbl_google
UNION ALL
SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'Facebook' AS type,
    facebook_specific_field,
    NULL AS linkedin_specific_field
FROM tbl_facebook
UNION ALL
SELECT 
    id, 
    name, 
    role, 
    added_at, 
    'LinkedIn' AS type,
    NULL AS facebook_specific_field,
    linkedin_specific_field
FROM tbl_linkedin;

查询View示例：

SELECT * FROM vw_all_users 
WHERE role = 'Manager'
ORDER BY added_at DESC
LIMIT 10 OFFSET 0;

优势：将整合逻辑放在数据库层，代码层只需查询View，简化开发；View实时同步数据，无需额外维护。
注意：字段差异大时，用NULL填充缺失字段保证结构统一。

内容的提问来源于stack exchange，提问作者Kuldeep KV