业务实体管理系统：从“碎块化KV”到“全链路中台化”多语言架构实践

1. 架构演进：从极致灵活到极致性能

在我上一篇关于多语言的文章中，我分享过基于 Key-Value（KV） 模式的实现。它通过 (entity_id, field_key, field_value) 实现了“零 Schema 改动”的翻译支持。

但在万级 TPS、大实体、多品类的资产管理场景下，KV 模式遇到了阿喀琉斯之踵：

• 读放大问题：一个拥有 20 个翻译字段的资产，在查询时需要 Join 出 20 行数据再聚合，IO 效率极低。
• 数据膨胀：索引与元数据的冗余远超实际业务数据量。

新的架构共识： 当业务实体的字段逐渐标准化，我们需要从“行扩展”回归到“表扩展”。通过**一主多从（i18n扩展表）**的结构，换取极致的查询性能与链路的统一。

2. 模型设计：主数据与语言层的物理隔离

在确定了放弃 KV 垂直模式后，如何在保证主数据简洁性的同时，支撑起结构化、高性能的多语言查询？

我的答案是：“一主多副本 + 维度垂直拆分”。

2.1 物理表结构：一主多副本

我建立了主从分离的存储模型。主表（asset_item）作为单实体的“真实来源（Source of Truth）”，只存储与语言无关的物理事实；而所有涉及文本描述的内容，全部外排至扩展表。

SQL

-- 1. 资产主表：极致精简，存储物理事实
CREATE TABLE asset_item (
    id          BIGINT PRIMARY KEY,
    category    VARCHAR(20) NOT NULL, -- 手表, 车等
    source_type INT DEFAULT 0,        -- 官方/非官方
    created_at  TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    -- 仅保留主语言(默认英文)的影子字段，用于 Resolver 缺失时的极速回退
    default_name TEXT NOT NULL
);

-- 2. 基础多语言表：存储跨品类通用字段
CREATE TABLE asset_item_i18n (
    asset_id        BIGINT NOT NULL,
    language_locale VARCHAR(10) NOT NULL, -- zh-CN, zh-TW, en
    name            TEXT,
    description     TEXT,
    analysis_text   TEXT,                -- 专家分析
    PRIMARY KEY (asset_id, language_locale),
    CONSTRAINT fk_asset_i18n FOREIGN KEY (asset_id) REFERENCES asset_item(id) ON DELETE CASCADE
);

2.2 维度垂直拆分：应对多品类字段爆炸

业务实体管理系统中，不同品类（Category）的规格字段差异极大。如果全部塞进一张 asset_item_i18n，会导致该表拥有几百个字段且极其稀疏。

采取了**“维度扩展表”**策略。例如，针对汽车和雪茄品类：

SQL

-- 汽车品类专属翻译
CREATE TABLE asset_car_i18n (
    asset_id        BIGINT NOT NULL,
    language_locale VARCHAR(10) NOT NULL,
    engine_type     TEXT, -- 发动机配置翻译
    exterior_color  TEXT, -- 外观颜色翻译
    PRIMARY KEY (asset_id, language_locale)
);

2.3 关键设计取舍与性能优化

在进行物理设计时，针对高并发场景做了如下深度优化：

1. 复合主键与聚集索引（Clustered Index Optimization）： 将 (asset_id, language_locale) 设为复合主键。在物理存储上，同一个资产的不同语言版本会紧凑地排列在一起。这种局部性原理使得数据库在执行字段回退（查询某资产的所有语言版本）时，只需要一次 IO 预读即可将所有候选翻译数据载入 Buffer Pool，性能远超 KV 模式下的多行扫描。
2. 级联删除（Cascade）的工程考量： 通过物理外键约束，确保了主记录删除时，分布在 5 张品类表中的语言副本会被原子化清理。这规避了旧方案中“孤儿记录”导致的数据残留风险。
3. 零查询开销回退（The Shadow Field）： 在主表保留了 default_name。当 request_language == 'en' 时，Resolver 会直接读取主表字段。对于占比 40% 以上的英文请求，成功实现了零 I18n 表查询开销，极大缓解了翻译中台的吞吐压力。

💡 架构 Tips

• 字段定义统一：在设计扩展表列名时，务必与 DTO 的字段名保持高度映射关系（如采用标准的 snake_case 到 camelCase 转换规则），这能让你后续通过 Java 反射或元编程极大简化 Resolver 的代码量。
• 避免超宽表：如果你的系统支持超过 50 种品类，建议引入分表策略或**JSONB（PostgreSQL 适用）**存储低频查询的非标属性，以平衡灵活性与解析性能。

3. 领域层核心：字段级回退（Field-level Fallback）

领域层的核心挑战在于：当数据库中的翻译数据存在“缺口”时，如何保证输出结果的连续性与可用性？传统的重写方案通常采用“整对象回退”，即如果缺失繁体版记录，则直接展示全量英文。这种处理方式过于粗糙，会导致用户体验产生剧烈的断层感。

本次架构改造引入了**字段级级联回退（Field-level Cascading Fallback）**机制，将其作为多语言中台的决策中枢。

3.1 决策中枢：EntityI18nResolverService

EntityI18nResolverService 承担了从原始数据到本地化 DTO 的“最后一步装配”职责。其核心逻辑不再是简单的字段映射，而是一套基于优先级链路的探测算法。

该服务通过**回退链（Fallback Chain）**定义不同语言环境下的寻址优先级。例如：

• 繁体中文（zh-HK）请求：探测优先级为 zh-HK $\rightarrow$ zh-CN $\rightarrow$ 主表默认值（en）。
• 简体中文（zh-CN）请求：探测优先级为 zh-CN $\rightarrow$ zh-HK $\rightarrow$ 主表默认值（en）。

这种设计的精妙之处在于：回退动作发生在字段级别。如果一个资产的“名称”有繁体翻译但“描述”只有简体，系统最终会拼装出“繁体名称 + 简体分析”的组合，最大限度地保留了本地化信息的覆盖率。

3.2 策略模式处理品类差异

由于不同资产的规格字段（Spec）完全不同，Resolver 内部采用了策略模式（Strategy Pattern）。主解析服务负责调度，具体的品类处理器（Handler）负责执行特定的回退逻辑。

Java

/**
 * 字段级回退的核心逻辑实现示例
 */
@Service
public class EntityI18nResolverService {

    // 预定义回退链路配置
    private static final Map<String, List<String>> FALLBACK_MAP = Map.of(
        "zh-TW", List.of("zh-TW", "zh-CN"),
        "zh-CN", List.of("zh-CN", "zh-TW")
    );

    public void resolve(AssetCardDto dto, String lang) {
        // 1. 语言归一化与链路获取
        List<String> chain = FALLBACK_MAP.getOrDefault(lang, Collections.emptyList());
        
        // 2. 批量拉取所有候选语言的翻译数据（避免在循环中查库）
        // 关键点：一次性取出所有语种副本，在内存中计算回退
        Map<String, AssetItemI18n> dataMap = i18nRepository.findAllByAssetIdAsMap(dto.getId());

        // 3. 执行字段级回退探测
        dto.setName(pickField(chain, dataMap, AssetItemI18n::getName, dto.getDefaultName()));
        dto.setDesc(pickField(chain, dataMap, AssetItemI18n::getDesc, dto.getDefaultDesc()));

        // 4. 委派给品类特定的处理器（如汽车、雪茄等）处理 Spec 字段
        categoryHandlers.stream()
            .filter(h -> h.supports(dto.getCategory()))
            .findFirst()
            .ifPresent(h -> h.resolveSpec(dto, dataMap, chain));
    }

    /**
     * 回退探测器：按优先级链寻找第一个非空值
     */
    private String pickField(List<String> chain, Map<String, AssetItemI18n> data, 
                             Function<AssetItemI18n, String> getter, String fallback) {
        for (String locale : chain) {
            AssetItemI18n record = data.get(locale);
            if (record != null && StringUtils.hasText(getter.apply(record))) {
                return getter.apply(record);
            }
        }
        return fallback; // 最终兜底：主表原始数据
    }
}

3.3 性能权衡：内存运算 vs 数据库 IO

在实现字段级回退时，存在一个典型的技术权衡：

• 错误做法：在循环中按语言优先级多次查询数据库。这会导致查询次数爆炸（N+1 问题）。
• 架构选优：利用 (asset_id, language_locale) 的复合索引特性，一次性将该资产的所有语种记录（通常 $<3$ 条）加载到内存中，由 Java 代码进行 pickField 运算。

这种做法将复杂的业务决策从 SQL 逻辑（如极其繁琐的 COALESCE 或 LEFT JOIN）中剥离出来，利用应用服务器的 CPU 换取了宝贵的数据库 IO 性能。

3.4 边界处理：影子字段的妙用

对于核心字段（如 name），主表保留了一份“影子字段（Shadow Field）”作为全局兜底。这保证了即使 i18n 系统因为极端原因不可用，系统依然能够输出最基本的英文名称，而不是展示意义不明的 ID 或空白卡片，确保了系统在高并发场景下的防御性架构能力。

4. 全链路透传：从“实时”到“回放”的端到端一致性

多语言架构最常见的失效场景并非发生在“翻译缺失”，而是发生在**“参数丢失”**。在一个复杂的微服务或分布式架构中，language 参数如果仅存在于 API 入口，极易在异步调用、消息队列传输或历史数据回放过程中丢失，导致用户看到的界面在不同语种间反复“跳变”。

本次改造的核心目标是实现语言状态的全链路隐形传播，确保“请求语言”与“返回语言”在任何时空维度下均保持一致。

4.1 隐形上下文传播（Implicit Context Propagation）

为了避免在每一个 Service 方法中显式传递 String lang 参数（这会产生严重的参数污染），架构上引入了基于 ThreadLocal 的上下文拦截器。

• 拦截器收口：在网关或 Filter 层，通过 SupportedLanguage 枚举对入参进行标准化校验，随后将其存入 LanguageContextHolder。
• 跨线程传递：针对异步任务（如 Spring 的 @Async）或线程池调用，使用 TransmittableThreadLocal 解决父子线程上下文丢失问题，确保 Resolver 在任何执行环境下都能感知到当前所需的标准 Locale。

4.2 会话历史回放：从“快照”到“动态水合”

在资产管理系统中，一个极具挑战的场景是历史会话回放（Chat/Asset History Rehydration）。当用户查看三个月前的资产卡片时，系统通常面临两种选择：

1. 静态快照：存储时直接保存当时的翻译文本。缺点是如果翻译更正或用户切换语言，历史记录无法更新。
2. 动态水合（Hydration）：数据库仅存储 asset_id。回放时根据当前用户的请求语言，实时调用多语言中台进行填充。

本次改造采用了动态水合方案。通过将 language 参数透传至持久化层的 convertAssetItemToSimplifiedCardDto 统一入口，系统能够在回放历史消息时，实时将存储的资产 ID 转化为符合当前用户语种偏好的动态卡片。这保证了用户即使在切换系统语言后，回看历史记录依然能获得无缝的本地化体验。

💡 架构观察

全链路透传的本质是将多语言属性从“业务参数”降级为“基础设施参数”。通过在底层的 PersistenceService 实现语言注入的统一收口，i18n 从一个“需要额外关注的功能”变成了“系统默认具备的属性”。这种设计大幅降低了业务开发者的心智负担：他们只需关注业务逻辑，而输出的每一张卡片，天然就是具备全球化能力的。

5. 方案评估与架构总结

在完成从“碎块化 KV”到“中台化链路”的改造后，我们需要从工程实践的角度出发，客观评估这套架构带来的收益以及在极端场景下的权衡（Trade-offs）。

5.1 架构优势：从“点”到“面”的质量提升

• 极致的一致性与鲁棒性： 得益于字段级回退策略，系统彻底消除了因部分翻译缺失导致的“空白卡片”现象。即便在最极端的情况下，系统也能通过主表的“影子字段”确保基础信息的展示，极大提升了全球化场景下的用户体验下限。
• 研发效率的释放： 由于多语言逻辑在 PersistenceService 转换层实现了统一收口，普通业务开发者在编写逻辑时不再需要关注 language 参数。i18n 能力成为了系统底座的一部分，实现了“开发无感知，产出天然本地化”。
• 数据治理的可运营性： i18n 扩展表与主业务表解耦后，翻译数据成为了可独立运营的资产。运营团队可以利用离线工具对 asset_item_i18n 进行批量翻译质量审计、热词补全，而无需担心误触或锁定主业务流程。

5.2 潜在挑战与深度优化（The Trade-offs）

架构设计本质上是平衡的艺术。在追求标准化和一致性的同时，我们也面临着新的挑战：

1. 查询放大与缓存策略： 虽然我们通过复合主键优化了物理 IO，但字段级回退依然意味着每次资产查询都需要拉取所有语种记录。在高并发的资产详情页，引入了 Redis 缓存机制：
   • 缓存 Key 设计：以 asset_id 为维度缓存该实体的所有语种 Map，而非按请求语言缓存 DTO。
   • 收益：这种方式能极大地提高缓存命中率，因为无论用户请求哪种语言，都能从同一个缓存对象中完成回退逻辑计算。
2. 双写一致性的挑战： 主表与 i18n 扩展表的同步更新是一个典型的分布式事务（或本地多表事务）场景。为了保证数据一致性，我们建议引入 Outbox Pattern：
   • 在主业务变更时，仅更新主表并发送变更事件。
   • 由专门的 I18n 更新服务监听事件，并异步或半异步地完成翻译数据的维护，确保主流程的极速响应。

5.3 适用场景与总结

本次重构通过“语言标准化 + EntityI18nResolver 集中决策 + 全链路隐形透传 + 维度扩展存储”的设计，将多语言能力从分散的补丁升级为生产级的中台链路。

总结建议：

• 如果你的项目处于初创期，字段不固定且查询压力小，KV 模式依然是快速上线的首选。
• 如果你的项目已进入成熟期，核心资产字段已标准化，且面临 TPS 过万、全球多节点分发的性能挑战，那么本文介绍的中台化改造将是提升系统稳定性与可维护性的必经之路。

架构不是一成不变的，它是业务规模与技术边界博弈后的产物。希望本次实践能为正在经历全球化架构转型的同行提供一份可落地的参考。