县城团队做同城O2O系统技术选型里常有一个分叉业务模块可以分期上线但用户、商家、订单与用户商家核心资料能不能共用一套写入口若外卖、跑腿、同城团购各维护独立用户表和 Admin 控制台运营就要在多个后台之间切换同一手机号在不同模块里是不同user_id营销和对账只能人工拼。下文从模块树、用户商家资料分层、配置与部署脚本说明「用户商家资料中枢 多业态扩展」怎么拆。示例为教学示意以光合同城当期交付为准。痛点数据对不上的根因往往是用户商家资料分散早期拼装方案常见结构外卖模块自带wm_user跑腿模块自带errand_user团购模块自带group_user各模块独立 Admin 控制台运营按业态切换 URL订单表按模块复制靠手机号后匹配「假装是同一人」后果很直观改配送状态进 A 后台财务导出在 B 后台加营销券要在三个系统各配一遍。同城O2O系统若目标是统一后台一体化架构上应先收敛用户商家资料写路径再谈 UI 有多少菜单。县城评审时可先问供应商三个问题用户主表是否全业态共用商家开通记录是否一张关联表表达Admin 是否按biz_type筛单而不是按模块分域名答不上来后面运营多半要在多个后台之间对不上数。模块目录用户商家资料层与业态插件分离county-o2o-platform/ ├── apps/ │ ├── user-app/ # 用户端下单、取消、评价 │ ├── merchant-app/ # 商家端接单、拒单、出餐/核销 │ ├── rider-app/ # 配送端取货、在途、送达 │ └── admin-console/ # 统一运营后台跨业态筛单、导出 ├── master-data-hub/ # 主数据中枢唯一写入口 │ ├── user-master/ │ ├── merchant-master/ │ ├── order-master/ │ └── sync-outbox/ ├── biz-plugins/ │ ├── takeout/ # 外卖扩展字段与履约策略 │ ├── errand/ # 跑腿扩展 │ ├── group-buy/ # 同城团购扩展 │ └── hotel/ # 酒店预定扩展可选 ├── mid-shared/ │ ├── marketing-core/ # 券、满减、会员标签 │ ├── permission-core/ # 角色、菜单、数据权限 │ └── settlement-export/ # 结算导出字段配置 └── ops/ ├── biz-type-routing.yaml ├── master-data-sync.yaml └── deploy-modules.yaml验收要点takeout、errand等插件禁止直连数据库 INSERT 用户或商家主表所有用户商家资料变更经master-data-hub写入口。用户与商家核心资料一张表、多业态关联多后台方案常伴随「每个模块一张 user 表」。正确做法是master-data-hub层维护用户商家核心资料各业态只引用 ID。-- 用户主表全业态共用CREATETABLEmd_user(idBIGINTPRIMARYKEYAUTO_INCREMENT,mobileVARCHAR(20)NOTNULLUNIQUE,nicknameVARCHAR(64)NULL,member_levelTINYINTNOTNULLDEFAULT0,city_codeVARCHAR(12)NOTNULL,created_atDATETIMENOTNULL,updated_atDATETIMENOTNULL,INDEXidx_city_mobile(city_code,mobile));-- 商家主表CREATETABLEmd_merchant(idBIGINTPRIMARYKEYAUTO_INCREMENT,nameVARCHAR(128)NOTNULL,city_codeVARCHAR(12)NOTNULL,statusVARCHAR(16)NOTNULLCOMMENTactive|suspended|closed,settle_modeVARCHAR(16)NOTNULL,created_atDATETIMENOTNULL);-- 商家开通哪些业态用关联表表达而不是再建 merchant 副本CREATETABLEmd_merchant_biz(merchant_idBIGINTNOTNULL,biz_typeVARCHAR(16)NOTNULL,enabledTINYINTNOTNULLDEFAULT1,PRIMARYKEY(merchant_id,biz_type));-- 用户跨业态消费汇总读模型可由事件异步刷新CREATETABLEmd_user_biz_summary(user_idBIGINTNOTNULL,biz_typeVARCHAR(16)NOTNULL,order_countINTNOTNULLDEFAULT0,last_order_atDATETIMENULL,PRIMARYKEY(user_id,biz_type));同城O2O系统验收时可固定一个测试手机号在takeout下单后在group_buy再下一单断言两笔单的user_id相同。若靠运营后台手工「绑定手机号」才算同一人说明用户商家资料未打通后续营销券无法跨业态复用。订单主表通用字段 业态扩展CREATETABLEmd_order(idBIGINTPRIMARYKEYAUTO_INCREMENT,order_noVARCHAR(32)NOTNULLUNIQUE,biz_typeVARCHAR(16)NOTNULLCOMMENTtakeout|errand|group_buy|...,user_idBIGINTNOTNULL,merchant_idBIGINTNOTNULL,city_codeVARCHAR(12)NOTNULL,statusVARCHAR(32)NOTNULL,pay_amountDECIMAL(12,2)NOTNULLDEFAULT0,created_atDATETIMENOTNULL,updated_atDATETIMENOTNULL,INDEXidx_user_biz(user_id,biz_type),INDEXidx_merchant_status(merchant_id,status))COMMENT同城O2O统一订单主表;CREATETABLEmd_order_takeout_ext(order_idBIGINTPRIMARYKEY,delivery_typeVARCHAR(16)NOTNULL,expect_timeDATETIMENULL,rider_idBIGINTNULL,CONSTRAINTfk_takeout_orderFOREIGNKEY(order_id)REFERENCESmd_order(id));所有status变更只经order-master/state-machine并写审计日志。Admin 控制台按biz_type筛单但 URL 仍是同一套。配置业态路由与模块启停# ops/biz-type-routing.yaml示意admin_console:base_url:/adminfilter_by:biz_typedefault_modules:-takeout-errandoptional_modules:-group_buy-hotel-errandmaster_data:user:single_table:md_userforbid_module_copy:truemerchant:single_table:md_merchantbiz_enable_table:md_merchant_bizsync:outbox_table:md_sync_outboxconsumers:-marketing-core-settlement-export# ops/deploy-modules.yaml示意county_pilot:city_code:410000enabled_biz:-takeout-erranddisabled_biz:-group_buy-hotelmaster_data_hub:requiredadmin_mode:unified县城首期试点建议只启两业态但用户商家资料层全量部署避免后续加模块时重新导用户和商家。部署脚本用户商家资料层先于业态插件#!/usr/bin/env bash# deploy-county-o2o.sh示意set-euopipefailENV${1:-staging}MODULES${2:-takeout,errand}echo[1/4] 部署主数据中枢 master-data-hub ..../scripts/deploy.sh master-data-hub--env$ENVecho[2/4] 初始化主数据表结构 ...mysql-h$DB_HOST-u$DB_USER-p$DB_PASS$DB_NAMEsql/md_user.sql mysql-h$DB_HOST-u$DB_USER-p$DB_PASS$DB_NAMEsql/md_merchant.sql mysql-h$DB_HOST-u$DB_USER-p$DB_PASS$DB_NAMEsql/md_order.sqlecho[3/4] 部署统一 Admin 控制台 ..../scripts/deploy.sh admin-console--env$ENVecho[4/4] 按清单启停业态插件:$MODULESIFS,read-raBIZ$MODULESforbin${BIZ[]};do./scripts/deploy.shbiz-plugins/$b--env$ENVdoneecho验收固定测试手机号跨$MODULES各下一单检查 user_id 一致。与统一后台能力复用的关系用户商家资料打通后统一后台侧marketing-core、permission-core等能力可按方案被各业态插件引用券模板、满减规则在mid-shared维护各biz_type按配置引用权限策略一处变更Admin 各业态菜单同步生效结算导出字段在settlement-export统一配置避免各模块导出格式不一致光合同城国内综合形态走统一后台一体化路线内置多业务模块模块数据互通、后台统一管理。成品可直接部署支持私有化源码与按需定制以当期书面方案为准。验收清单架构评审可用用户主表是否全业态共用禁止各模块复制 user 表。商家开通记录是否用md_merchant_biz表达而非各模块各建 merchant订单主表是否统一扩展字段是否放扩展表Admin 是否同一 URL按biz_type筛单加第三业态时是否只需启插件、无需重导用户和商家同城O2O系统架构里用户商家资料怎么打通决定了后面运营是对数还是跑业务。先把写路径收敛到master-data-hub再按节奏叠业态插件比每个模块各存各的往往更稳。