Nexora ERP
统一架构战略方案

从哪里出发

GitLab xipugold group 下实际有 34 个仓库,战略相关的核心是 12 个:4 套 ERP + 2 套商城 + 3 套小程序体系 + 3 套手机端相关。下面是实测数据。

1.1 ERP 主干四仓库(合并的核心对象)

1.2 商城与共享 shop 数据层

1.3 小程序体系(3 端莱雅)

• laiya_wx — 主商城小程序
• laiya_jxs_wx — 经销商小程序
• laiya_lss_wx — 零食师小程序(含金蛋/盲盒/秒杀活动)
• pyerp_shop_wx — 妈祖商城小程序
• lyshop_wx — 另一个未验证的小程序(仓库存在,未 clone)

1.4 手机端(3 套 UniApp + 1 套 Kotlin 后端)

1.5 其他仓库(战略相关性次要)

• hjhs — 黄金回收(CRMEB 独立框架)· 200+ controllers · 完全不同基因,建议保持独立
• wl_php / wl_web — 未验证(名称疑似「物流」)
• waimao_php — 未 clone(疑似「外贸」)
• hjt / supererp / xipu_new / pyerp_php_api — 未验证(未 clone 或 clone 后未深入)
• electron_exe / python-auto-print-desktop / password — 桌面工具集,和 ERP 主干无关

一张图看懂 Nexora

分三层:外部入口 → 统一 API 网关 → Nexora ERP 核心(一份代码)+ 平台中心库 + 共享 shop 数据层 → 租户业务库(一租户一库)。核心改动:把「每客户一份独立部署」升级为「一份部署跑多租户」,复用已有的 aid + bid + pt_type 隔离机制。

10 条已经拍板的选型(v3 修订)

从龙凤骨架到 Nexora 的三步走

v6 最终版:Phase 1 龙凤先入 → Phase 2 摆件+妈祖并入 → Phase 3 手机端+Kotlin变薄+商城。囍铺放到最后视情况处置,莱雅系全弃,商城简化为妈祖单基座。比 v5 少一个阶段,因为囍铺代码全在龙凤里,不需要单独 Phase。

模块是差异化的最小单位

5.1 核心模块(所有租户必装)

• account — 账号 / 角色 / 权限 / 组织架构 · 复用 aid/bid/pt_type 上下文
• feature-flag — 功能开关引擎 · 大模块 / 菜单级
• product — 商品 / SKU / 分类 · 通用 54 controller 里的核心
• inventory — 库存 / 库位 / FIFO / 调拨 / 盘点
• order — 采购 / 销售 / 审核状态机 / Bill / 财务
• store — 门店 / 仓库 / 收银
• supplier-customer — 供应商 / 客户 / 联系人

5.2 可选模块(按租户启用)

• ymetal — 贵金属(妈祖专属)· 50 个 controller · 18884 行代码 · 40+ 张 Ymetal* 表
• myhw-shop — 妈祖商城对接(Ep* 系列)
• aliyun-image — 阿里云图搜 + OSS(xipu 独有)
• config-scoring — Config / ScoreConfig(xylferp 独有,评估中)
• mall-sync — 商城对接 API · products / orders / stock
• mobile-api — Kotlin WebSocket 接入 · SSO · 实时通信
• distribution — 分销 / 经销商 / 零食师(莱雅系)
• marketing — 金蛋 / 盲盒 / 秒杀 / 优惠券

5.3 模块生命周期规范

每个模块目录 modules/<name>/ 内自包含:路由声明 / 控制器 / 数据表 migrations / 菜单声明 / 权限声明 / 服务接口 Facade。模块间禁止直接调用,统一走 Facade。

5.4 功能开关粒度

5.5 一租户一库运维套件(v4 新增)

一租户一库的唯一真正代价:运维成本随客户数线性增长。必须把每个环节脚本化,否则 20 个客户后运维会累趴。以下 4 件套是 Nexora 主干必备的运维基础设施,写一次终身受用。

套件 1 · 新租户开通脚本

bin/tenant-onboard <tenant-slug> --modules ymetal,mall-sync · 一次跑完 4 件事:

1. 创建新 DB nexora_<slug>(charset utf8mb4)
2. 跑 核心模块 migrations(account / product / inventory / order / store / supplier-customer)
3. 按 --modules 参数选择性跑 可选模块 migrations(ymetal / wedding / distribution ...)
4. 初始化种子数据:默认角色 · 菜单树 · 管理员账号 · tenants 中心库注册

验收:执行完毕 30 秒内新租户能登录 · 前台菜单只显示启用的模块 · 中心库 tenants.enabled_modules 有正确记录。

套件 2 · migrations 分发机制

核心痛点:主干加了一张新表,要在 N 个租户库都跑一遍。

• 每次发布带 migration 版本号(V20260701_120000__add_xxx.sql)
• bin/migrate-all 遍历中心库 tenants,对每个租户 DB 检查 schema_migrations 表,执行未跑过的 migration
• 失败任一租户即停 + 输出报错;不能"跑了一半就走人"
• 模块启用/禁用时,只跑该模块专属的 migrations

套件 3 · 备份轮询

每个租户库独立备份 · 每晚自动:

1. 遍历中心库 tenants 拉全部租户清单 + DB 连接串
2. 对每个租户 mysqldump | gzip 到独立目录 /backup/tenant/<slug>/<date>.sql.gz
3. 保留策略:daily 7 天 · weekly 4 周 · monthly 6 月
4. 校验大小(比昨天缩水 >20% 报警) · 校验能否 gunzip -t 完整解压
5. 周期性抽样恢复演练(每季度对一个租户做 restore 到临时库,验证备份可用)

套件 4 · 部署监控

• 中心库 tenants.status 有 active / paused / archived 三态
• 监控面板按租户视角展示:请求 QPS · 错误率 · DB 慢查询 · 磁盘用量 · 备份状态
• 租户级熔断:某个租户 DB 挂了不影响其他租户(连接池按租户隔离)
• 灰度发布支持:同一个二进制部署,按租户 slug 白名单启用新功能开关

立刻就能启动的事

1. 在 GitLab nexora group(gid=75,已建)下建 nexora-erp repo · 以 xylferp_php clone 起点 · 保留完整 git 历史
2. 建租户中心库 schema · 从龙凤(xylferp)一个租户开始
3. 抽第一个可选模块 aliyun-image(未来给囍铺租户用) · 作为「模块隔离」样板
4. 把「一租户一库运维套件」4 件套(§5.5)先落地最小可用版
5. Phase 1 完成:龙凤客户在 Nexora 环境跑通 · 关键 UI 无 regression · 批发+零售双业态可用
6. Phase 2 顺移:摆件(15 分钟) + 妈祖(主战场) 并入
7. Phase 3 收尾:手机端 + Kotlin 变薄 + 妈祖商城合入 + 囍铺择机

34 个仓库 · 一表打尽 · 唯一 SoT

执行时任何"这个仓要不要动"的问题,以本表为准。Action 列 = 强制约束,和路线图冲突以本表为准。

Action 标签定义:

• MERGE — 合并到 nexora/nexora-erp,原 repo 完成后归档 read-only
• KEEP — 原样保留 · 手机端 Phase 3 才动 · Phase 1-2 不动
• LATER — Phase 3 择机处理 · 视客户情况决定合并或退役
• ARCHIVE — 归档 · 客户已停用 · 不做迁移不做合并 · GitLab 标 archived 后完成
• DROP — 弃用 · 客户不再用 · 不投入任何工作 · 归档时打 tag "dropped"
• OUT-OF-SCOPE — 战略无关 · 桌面工具 / 内部小工具 · 无需处置

ERP 主干仓库(4 个)

商城仓库(3 个)

手机端仓库(6 个)

弃用仓库(6 个 · 不投入工作)

其他仓库(战略无关或未评估)

下面这些事情不做

执行时,任何"要不要顺便把 X 也做了"的问题,以本节为准 · 目的是防止 scope creep。看到不在 §04 路线图 + §08 总表里的东西,默认不做。

战略的血脉——为什么这么定的

主文档只写"要做什么"和"不做什么"。这里留每一次战略调整的为什么 · 未来接手的人或者 AI 需要理解历史脉络时看这里。