HR主数据_架构治理

一、项目背景

在“蚂蚁搬家”背景下，HR 主数据系统从集团统一平台迁移至蚂蚁自建平台。
迁移完成后，系统逐步演变为集团级数据中台，服务上千调用方。

随着业务规模扩大与组织频繁变动，系统暴露出明显的架构问题：

模块边界不清，基础能力与业务逻辑耦合严重
接口数量膨胀（700+），重复能力多
依赖管理混乱，版本不统一
消息、缓存、定时任务分散管理
监控体系与稳定性建设不足

因此在 CY24 启动系统性架构治理专项。

二、目标与范围

目标

提升系统可维护性与可演进性
收敛接口规模，明确能力边界
建立清晰分层架构与职责模型
提升稳定性与可观测能力
为组织拆分与未来多租户能力预留空间

范围

工程结构重构（DDD化）
接口融合与统一出口治理
依赖治理
消息与定时任务重构
缓存与 DRM 治理
Web 结构调整
存储升级
稳定性体系建设

三、核心逻辑 / 技术方案

1. 工程结构治理（DDD 重构）

1.1 分层重构

重构为标准分层结构：

domain：核心业务规则
application：业务编排
infrastructure：数据库 / RPC / MQ / 中间件
facade：对外接口

设计原则：

所有业务规则沉入 domain
facade 只做参数适配与出入参转换
infrastructure 不侵入业务规则
明确单向依赖关系，避免循环依赖

1.2 模块裁剪与清理

移除或迁移历史冗余模块：

zdal
hrworkcore-facade
hrorg-metadata-ext-client
hrorg-data-gateway
部分 model 模块拆分或下沉

目标：

降低横向依赖
减少“核心模块被全局依赖”的情况
收敛公共能力至 infrastructure 或 common 模块

2. 接口治理

2.1 接口融合

原 700+ 接口收敛至约 200+
同类能力统一出口
旧接口标记 @Deprecated，逐步下线
内部转调新接口，保证平滑迁移

2.2 主数据统一读写模型

所有写操作统一走主数据服务
禁止绕过主数据直接操作底层数据库
工作台只负责请求转发，不允许承载核心业务逻辑

目标：

防止数据一致性破坏
明确系统边界
提升可治理性

3. 依赖治理

统一在 parent pom 管理版本
子模块禁止单独声明版本
统一 groupId 管理策略
facade 禁止依赖实现模块
第三方中间件统一沉入 infrastructure

效果：

降低依赖冲突风险
提升升级可控性
避免隐式传递依赖

4. 消息体系重构

问题

消息逻辑分散
发送与业务强耦合
职责不清晰

重构方案

domain 仅产生业务事件
消息发送统一下沉 infrastructure
建立统一消息服务（创建 / 投递 / 发送）
明确消息拆分策略（写表 -> 发送 -> 归档）
支持幂等控制

优化效果：

消息链路清晰
降低重复发送风险
服务启动时间下降约 20s

5. 定时任务治理

拆分多职责定时任务
一个任务只做一件事
明确任务分发模型
清理无效判断逻辑
强化幂等与重试机制

目标：

提升任务稳定性
提升可观测能力
降低复杂任务的认知成本

6. 缓存与 DRM 治理

6.1 缓存治理

引入缓存开关控制
移除 MapDB 等本地缓存
明确缓存生效路径
统一缓存管理策略

6.2 DRM 治理

梳理 DRM 配置项
合并冗余配置
统一配置沉入 infrastructure 管理
减少配置分散与冲突风险

7. Web 结构治理

前后端分离
工作台与主数据解耦
明确查询接口与操作接口边界
收敛页面逻辑至后端统一能力

8. 存储升级

使用 ZSearch 替代旧 entSearch
优化 ES 模糊搜索能力
建立数据版本控制机制
支持历史数据回滚能力

9. 稳定性建设

9.1 监控体系

摘要日志接入监控大盘
流量 TOP 统计
业务方调用统计
慢 SQL 监控
慢接口监控

9.2 数据治理

数据版本快照
查询审计
告警降噪治理
日志分级与统一输出规范

10. 平台建设

输出系统白皮书
用户手册
QA 文档
接入 GPT 进行知识问答支持

四、关键难点

模块裁剪时依赖链复杂，隐式依赖多
上千调用方，接口收敛风险高
双系统共存阶段数据一致性风险
消息与缓存重构难以完全静态验证
组织变动频繁，治理过程中需求不断插入

五、风险与应对

风险	应对措施
接口下线导致业务中断	灰度发布 + 日志对比 + 流量监控
模块裁剪影响隐式依赖	全链路梳理 + 影子测试
消息重构导致重复发送	引入幂等校验
定时任务拆分引入问题	单测覆盖 + 数据回放
缓存治理影响性能	压测验证 + 开关控制

六、过程反思

架构治理必须以“边界清晰”为核心，而非简单代码整理
不应过度抽象，应优先保证业务可理解性
监控体系建设应与功能重构同步推进
接口收敛必须提供替代能力，避免强行删除
主数据系统的核心价值在于“统一执行与统一治理能力”

七、QA（问答总结）

Q1：为什么要进行 DDD 重构？
A：历史系统以功能堆叠为主，业务规则散落在各层，导致难以演进与扩展。通过 DDD 重构，明确边界与职责，提升系统可演进能力。

Q2：接口收敛如何避免影响上千调用方？
A：保留旧接口并内部转调新接口，灰度观察流量与日志，逐步下线。

Q3：消息体系重构的核心收益是什么？
A：统一消息出口，降低耦合，增强幂等控制与可观测性。

2026-02-28-HR主数据_架构治理