元数据驱动是什么、微服务是什么、元数据 vs Oracle EBS/Fusion 的表字段、微服务 vs Oracle 存储过程/API。最后给一张可直接拿去汇报的对比表。
一、华为 MetaERP 里的「元数据驱动」到底是什么
核心一句话：传统 ERP 是“代码里写死业务”，元数据驱动是“用数据描述业务，引擎读数据生成功能”。
1. 三层结构（传统 vs 元数据驱动）
- 传统 EBS 风格：代码 + 数据库表
- 加一个“项目参考号”字段 → 改表结构、改 Form、改 PL/SQL、改报表、发版
- MetaERP 元数据驱动：引擎 + 元数据 + 物理表
- 加同一个字段 → 在元数据层建一条“对象=采购订单 / 字段=项目参考号 / 类型=文本 / 必填=否”的记录
- 元数据引擎自动：建列或映射到扩展存储、生成 UI、校验、权限、API、列表、导出
2. MetaERP 元数据管什么
不是只管“字段名”，而是管一整条业务骨架：
- 业务对象：订单、物料、凭证、核算维度
- 字段属性：类型、默认值、校验、可见性、跨租户覆盖
- 关系：一对一、一对多、父子级联
- 流程：状态机、审批路由、条件分支
- 规则：会计引擎映射、计税规则、信用检查
- 界面：列表、表单、仪表盘布局
- 权限：角色对对象/字段/操作的访问控制
3. 一个具体例子：会计科目（COA）
- Oracle EBS：公司段+部门段+科目段+项目段拼成CCID（弹性域大宽表），维度固化在字符串里，加维度要重构科目结构
- MetaERP：把 COA 拆成核算单元 / 自然科目 / 核算维度 三块元数据
- 维度是独立元数据，可动态增删
- 事件进来 → 会计规则（也是元数据）→ 自动出多维凭证
注意：元数据驱动不等于 EAV 万能宽表。现代做法（含 MetaERP 思路）是“元数据描述结构，物理层仍用正常关系表或动态 ORM 映射”，避免 EAV 性能灾难。
二、微服务在 MetaERP 里是什么角色
核心一句话：把一个巨型 ERP 单体，按业务域拆成几百个独立部署、独立库、通过 API/事件说话的服务。
1. 拆分粒度（以财务链为例）
- 应付微服务（有自己的表：
t_ap_invoice*） - 采购微服务（
t_po_*） - 会计引擎微服务（
t_journal_*） - 主数据微服务
- 维度/元数据微服务
每个服务：
- 独立代码仓库、独立容器、独立 DB Schema
- 对外只暴露声明式 API + 事件
- 内部爱用啥索引、啥表结构自己定
2. 跨模块怎么协作
- EBS：同一个 Oracle 库里，PL/SQL 直接
INSERT应付表再UPDATE采购分布表，一个事务搞定 - MetaERP：
- 应付服务落本地事务
- 发“发票已录入”事件 / 调会计服务 API
- 会计服务自己落凭证
- 失败用Saga 补偿事务，不是数据库级 rollback
3. 微服务的代价（必须知道）
- 分布式事务变最终一致，不能像 EBS 那样“全成功或全回滚”
- 跨服务查询要做 CQRS / 只读副本 / 聚合层
- 运维复杂度高（K8s、服务网格、链路追踪）
三、元数据 vs Oracle EBS / Fusion 的「数据库表+字段」
这是你问题里最容易被混淆的一点：元数据不是替代表，而是“表的上面再盖一层描述层”。
维度 | Oracle EBS / Fusion 物理表字段 | MetaERP 元数据 |
|---|---|---|
本质 | 业务数据的真实存储位置（ | 关于“有什么对象/字段/规则”的描述数据（存在元数据表或元数据服务里） |
谁定义 | 甲骨文产品组写死，客户改要 AD 补丁/个性化 | 平台预置 + 租户管理员在界面配 |
加字段路径 | 新建列 → 改 PKG → 改 OAF/Form → 迁移 | 元数据加记录 → 引擎决定落物理列还是扩展表 |
表样例 |
|
|
业务含义绑定 | 表名和列名即含义，但规则在 PL/SQL 里 | 含义、校验、标签、权限全在元数据里，物理列可能只是 |
多租户差异 | 靠 | 标准元数据全局，租户元数据叠加，互不影响 |
升级影响 | 升 EBS R12 经常要跑 adop、处理客户化失效 | 核心引擎升，租户元数据兼容迁移即可 |
关键区别一句话：
- EBS 的“字段”是物理存储 + 代码含义
- MetaERP 的“元数据字段”是逻辑定义，物理落库由引擎翻译（可能真建列，可能进扩展表，可能进 JSON 半结构化列）
Fusion 比 EBS 好一点（有更多配置化、OTBI、弹性字段），但底层仍是“预定义表结构 + 部分扩展”，不是 MetaERP 那种“对象/流程/规则全元数据化”。
四、微服务 vs Oracle 存储过程 / API
1. Oracle 存储过程（PL/SQL Package）
- 位置：在数据库内部，和表在同一个 Oracle 实例
- 能力：直接读全表、游标、触发器、自治事务、CCID 校验
- 事务：原生 ACID，一个
COMMIT跨应付/总账/库存 - 扩展：改 PKG 要数据库权限，版本靠文件加载
- 痛点：业务逻辑沉到 DB，应用层变薄，无法跨非 Oracle 库，难以容器化
2. Oracle EBS 的 API
- 形式：
xxx_pub.create_invoice这种 PL/SQL 包包装的“API”，或 OAF 的 AM/VO - 本质：仍是库内调用，外面 Java/Form 过来走 JDBC 调包
- 限制：绑定 Oracle 技术栈，水平扩展靠 RAC 堆机器
3. MetaERP 微服务
- 位置：独立进程/容器，可能连 GaussDB、可能连 Redis、可能只存事件
- 能力：自己决定怎么存，跨服务靠 HTTP/gRPC/消息队列
- 事务：本地 ACID + 跨服务最终一致（Saga/事件补偿）
- 扩展：服务独立发版，A 服务升级不影响 B
- 对外：标准 RESTful / gRPC 声明式 API，前端和低代码平台直接消费
对照表
维度 | Oracle PL/SQL 存储过程 | Oracle EBS Pub API | MetaERP 微服务 |
|---|---|---|---|
运行位置 | Oracle DB 内 | Oracle DB 内（被外部调） | 独立容器/K8s |
跨模块写数据 | 直接跨表写，一个事务 | 调包间接跨表写，仍同库事务 | 只写自己库，跨模块发事件/API |
一致性 | 强一致 | 强一致 | 最终一致+补偿 |
技术绑定 | 死绑 Oracle | 死绑 Oracle | 自主栈（GaussDB/欧拉） |
扩容 | RAC 纵向/横向受限 | 同左 | 按服务独立 HPA 扩容 |
改逻辑 | 改 PKG 重编译 | 改 PKG | 改某个服务镜像 |
低代码/AI 接入 | 难，要懂 PL/SQL | 难 | 易，API+元数据即描述 |
五、把四件事串起来（MetaERP 的全局画面）
- 元数据驱动解决“业务怎么描述”：对象、字段、流程、规则、UI 都是数据
- 微服务解决“代码怎么部署”：按域拆开，各管各的表和事务
- 元数据引擎读元数据 → 动态生成物理表 DDL / CRUD SQL / 表单 / API 路由
- 微服务把这些能力按“应付”“总账”“采购”切成独立运行时
→ 所以 MetaERP 里：你配元数据，引擎建表；你调微服务 API，服务按元数据校验后写自己的物理表。
反观 Oracle EBS：
- 表是甲骨文建的（你动不了核心）
- 规则在 PL/SQL 里（你改要会写 Package）
- 模块靠同库事务粘在一起（你拆不出去）
