简介本资源是一套基于SpringCloud微服务架构的O2O外卖系统后端数据库设计实现面向Java后端开发者、微服务学习者及电商平台项目实践者聚焦饿了么类业务场景下的多端协同与数据建模问题。压缩包为ZIP格式共3个SQL文件65KB分别对应订单调度db_dis_order.sql、客户订单db_cus_order.sql和商家中心shangcheng.sql三大核心模块完整覆盖用户、商家、骑手、订单等关键实体关系与事务逻辑具备直接导入MySQL运行的基础结构与初始化数据。已有485人学习下载适合用于微服务项目数据库层参考、SpringCloud多模块联调的数据准备以及理解O2O平台中高并发订单与分布式事务下的表结构设计思路。1. 这不是“仿饿了么”Demo而是一套真实可压测、可拆分、可演进的O2O多端协同后端骨架SpringCloud 四端隔离 总后台聚合你在网上搜“饿了么外卖系统 SpringCloud”90% 的结果是单体 SpringBoot 前端 Vue 的教学 Demo订单表硬编码在 user_service 里配送员和商家共用一个登录接口连 Redis 缓存都只配了一个 localhost:6379。但真实 O2O 系统的后端根本不是这样——它必须支撑客户端C端用户日均千万级请求、商家端B端高并发上架/下架、配送端Rider毫秒级位置上报与调度响应、订单端Order强一致性事务与状态机驱动、总后台Admin跨域数据聚合与实时监控。这套架构不是为“跑通功能”设计的而是为“扛住峰值、快速迭代、独立演进”设计的。它用 SpringCloud AlibabaNacos Sentinel Seata做服务治理底座四端业务逻辑物理隔离、API 网关层路由分流、数据库按端垂直分库水平分表订单库按月分表用户ID哈希分片总后台不直连业务库只通过 Feign 调用聚合服务或 Kafka 消费埋点数据。如果你正要从单体迁移到微服务或正在设计新 O2O 平台的后端基线这篇笔记就是你跳过踩坑、直接复用的最小可行骨架。2. 用 SpringCloud Alibaba 搭建四端服务注册与发现Nacos 配置中心 多环境隔离 服务健康检查2.1 为什么选 Nacos 而非 Eureka——真实生产中“注册中心不可用”比“服务宕机”更致命Eureka 的自我保护模式在大规模节点抖动时会盲目保留大量失效实例导致流量打到已下线服务ZooKeeper 的 CP 特性在脑裂场景下直接拒绝写入网关无法动态更新路由。Nacos 同时支持 AP服务发现和 CP配置管理且提供控制台可视化心跳探测、权重灰度、元数据标签路由——这正是四端协同的核心需求比如配送端 RiderService 必须优先调用同机房的 DispatchService商家端需按城市 ID 标签路由到对应区域的 MerchantService。我们不用EnableEurekaClient而是统一依赖spring-cloud-starter-alibaba-nacos-discovery每个模块的bootstrap.yml中强制指定 namespace命名空间隔离环境# client-service/bootstrap.yml spring: cloud: nacos: discovery: server-addr: 192.168.10.50:8848 namespace: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d # dev 环境 namespace ID group: CLIENT_GROUP cluster-name: SHANGHAI config: server-addr: 192.168.10.50:8848 namespace: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d group: CLIENT_GROUP file-extension: yaml提示namespace 是 Nacos 最关键的隔离单元不是用profile区分环境而是用 namespace ID。dev/test/prod 各自独立 namespace避免测试环境误删生产配置。group 用于同一环境下按端划分CLIENT_GROUP / MERCHANT_GROUP / RIDER_GROUP / ORDER_GROUP便于权限管控。2.2 四端服务命名规范与元数据注入让网关和熔断器“看懂”你是谁单纯靠服务名client-service不足以表达语义。我们在每个服务启动时注入元数据供 SpringCloud Gateway 动态路由和 Sentinel 流控规则识别// client-service/src/main/java/com/eleme/client/config/NacosMetadataConfig.java Configuration public class NacosMetadataConfig { Bean ConditionalOnMissingBean public Registration registration() { return new NacosRegistration() { Override public MapString, String getMetadata() { MapString, String metadata new HashMap(); metadata.put(service-type, client); // 标识 C端 metadata.put(biz-domain, user); // 用户域 metadata.put(version, v2.3.1); // 接口版本 metadata.put(qps-threshold, 5000); // 基准 QPS return metadata; } }; } }这样Gateway 的 Predicate 就能写成spring: cloud: gateway: routes: - id: client-api uri: lb://client-service predicates: - Header[X-Client-Type], client # 只转发带此 header 的请求 - Metadata[service-type], client # 或直接匹配元数据而 Sentinel 控制台就能基于service-typeclient统一配置 C端全局流控规则无需为每个接口单独设限。2.3 服务健康检查的“真存活”验证不只是 ping而是查 DB Redis MQ 连通性Nacos 默认只检测 HTTP/actuator/health端点但该端点可能返回 UP 却实际连不上 MySQL。我们重写HealthIndicator组合校验Component public class CompositeHealthIndicator implements HealthIndicator { private final JdbcTemplate jdbcTemplate; private final RedisTemplate redisTemplate; private final KafkaTemplate kafkaTemplate; Override public Health health() { try { // 1. 检查 MySQL执行轻量 SELECT jdbcTemplate.queryForObject(SELECT 1, Integer.class); // 2. 检查 RedisSETNX key redisTemplate.opsForValue().setIfAbsent(health:check, ok, Duration.ofSeconds(1)); // 3. 检查 Kafka发送测试消息异步超时 2s kafkaTemplate.send(health-test, ping).get(2, TimeUnit.SECONDS); return Health.up().withDetail(db, OK).withDetail(redis, OK).withDetail(kafka, OK).build(); } catch (Exception e) { return Health.down().withDetail(error, e.getMessage()).build(); } } }Nacos 会每 5 秒调用此接口连续 3 次失败则将实例标记为DOWN并从服务列表剔除。这是防止“假活”流量打到半死服务的关键防线。3. 四端 API 网关统一入口SpringCloud Gateway JWT 鉴权 多租户路由 请求体缓存3.1 网关层不做业务鉴权只做“身份透传”与“端标识校验”很多团队把 JWT 解析、RBAC 权限校验全堆在 Gateway结果网关成为性能瓶颈和单点故障。我们的做法是Gateway 只验证 token 签名有效性、过期时间、并提取client_typeclient/merchant/rider/order、tenant_id商家 ID 或城市编码然后以X-Client-Type、X-Tenant-ID等 Header 透传给下游服务。真正的权限校验由各端服务自己完成如商家端校验tenant_id是否属于当前登录商家网关只做“准入”而非“授权”。// gateway/src/main/java/com/eleme/gateway/filter/JwtAuthFilter.java public class JwtAuthFilter implements GlobalFilter { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { String authHeader exchange.getRequest().getHeaders().getFirst(Authorization); if (authHeader null || !authHeader.startsWith(Bearer )) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } String token authHeader.substring(7); try { JwsClaims claimsJws Jwts.parserBuilder() .setSigningKey(rsaPublicKey) .build() .parseClaimsJws(token); Claims claims claimsJws.getBody(); // 提取并透传关键字段 exchange.getRequest().mutate() .headers(h - { h.set(X-Client-Type, claims.get(client_type, String.class)); h.set(X-Tenant-ID, claims.get(tenant_id, String.class)); h.set(X-User-ID, claims.get(user_id, String.class)); }) .build(); } catch (JwtException e) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } return chain.filter(exchange); } }注意RSA 公钥必须预加载到内存禁止每次解析都读文件claims.get(xxx, String.class)比claims.get(xxx).toString()更安全避免空指针。3.2 多租户路由策略同一商家多个子门店流量按 tenant_id 哈希到不同实例组商家端merchant-service需支持连锁品牌如“肯德基上海徐汇店”、“肯德基上海静安店”共享一套代码但数据物理隔离。我们不在数据库层做 tenant_id 字段过滤而是在网关层做路由分发# gateway/src/main/resources/application.yml spring: cloud: gateway: routes: - id: merchant-service uri: lb://merchant-service predicates: - Header[X-Client-Type], merchant filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 100 redis-rate-limiter.burstCapacity: 200 - name: DeduplicateResponseHeader args: name: Vary strategy: RETAIN_FIRST # 关键按 X-Tenant-ID 哈希路由到不同集群 metadata: tenant-hash: true配合自定义LoadBalancer实现Bean public ReactorLoadBalancerServiceInstance reactorLoadBalancer( Environment environment, LoadBalancerClientFactory loadBalancerClientFactory) { String serviceId environment.getProperty(LoadBalancerClientFactory.PROPERTY_NAME); return new TenantHashLoadBalancer(loadBalancerClientFactory.getLazyProvider(serviceId, ServiceInstanceListSupplier.class)); } // TenantHashLoadBalancer.java 内部逻辑 // 1. 从 exchange 获取 X-Tenant-ID // 2. 对 tenant_id 做 MurmurHash3取模 instance 数量 // 3. 返回对应索引的 ServiceInstance // 保证同一 tenant_id 总打到同一组 merchant-service 实例利于本地缓存命中3.3 请求体缓存解决 POST/PUT 请求体被 Gateway 读取后下游收不到的问题SpringCloud Gateway 默认不缓存请求体ServerWebExchange.getRequest().getBody()只能读一次。当需要记录日志、做风控校验、或转发到多个下游时必须手动缓存Component public class CacheRequestBodyGlobalFilter implements GlobalFilter { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ServerHttpRequest request exchange.getRequest(); if (request.getMethod().equals(HttpMethod.POST) || request.getMethod().equals(HttpMethod.PUT)) { // 缓存 body 到 exchange 属性 return DataBufferUtils.join(request.getBody()) .map(dataBuffer - { byte[] bytes new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); DataBufferUtils.release(dataBuffer); return bytes; }) .flatMap(bytes - { // 存入 exchange 属性供后续 Filter 或 Controller 使用 exchange.getAttributes().put(cached-request-body, bytes); // 构造新的 cachedRequest FluxDataBuffer cachedFlux Flux.just(exchange.getResponse().bufferFactory().wrap(bytes)); ServerHttpRequest cachedRequest new ModifyRequestBodyServerHttpRequest(request, cachedFlux); return chain.filter(exchange.mutate().request(cachedRequest).build()); }); } return chain.filter(exchange); } }下游服务可通过exchange.getAttribute(cached-request-body)获取原始 JSON避免重复解析或丢失。4. 订单端强一致性保障Seata AT 模式 TCC 补偿 Saga 状态机驱动4.1 为什么不用本地事务——跨库操作天然存在分布式事务问题下单流程涉及① 客户端扣减用户余额client-db② 商家端冻结商品库存merchant-db③ 订单端生成主订单 子订单order-db④ 配送端预分配骑手rider-db四个库分布在不同物理节点MySQL 本地事务无法覆盖。若用消息最终一致性会出现“用户付了钱但没生成订单”或“库存扣了但订单失败”的资金/库存损失。我们必须用分布式事务中间件。4.2 Seata AT 模式落地细节undo_log 表必须与业务表同库且开启全局事务注解AT 模式对业务代码侵入最小但配置极易出错。关键点每个业务库client-db、merchant-db、order-db、rider-db必须创建undo_log表且与业务表在同一 schema 下undo_log表结构必须严格匹配 Seata 1.7 版本要求含branch_id、xid、context字段启动类添加EnableAutoDataSourceProxySeata 1.7 自动代理数据源分布式事务入口方法加GlobalTransactional(rollbackFor Exception.class)。// order-service/src/main/java/com/eleme/order/service/OrderService.java Service public class OrderServiceImpl implements OrderService { Autowired private ClientAccountService clientAccountService; // Feign 调用 client-service Autowired private MerchantInventoryService merchantInventoryService; // Feign 调用 merchant-service GlobalTransactional(rollbackFor Exception.class) Override public Order createOrder(CreateOrderRequest req) { // 1. 扣用户余额client-service clientAccountService.deductBalance(req.getUserId(), req.getTotalAmount()); // 2. 冻结库存merchant-service merchantInventoryService.freezeStock(req.getMerchantId(), req.getItems()); // 3. 本地生成订单order-db Order order orderMapper.insert(req); // 4. 预分配骑手rider-service riderService.preAssignRider(order.getId(), req.getDeliveryAddress()); return order; } }注意Feign 调用必须走GlobalTransactional包裹的方法内部否则 Seata 无法传播 XID。clientAccountService.deductBalance()内部需有GlobalLock注解确保行锁。4.3 TCC 模式兜底针对无法自动回滚的操作如调用微信支付AT 模式无法处理外部三方服务微信支付、短信网关。此时用 TCCTry-Confirm-Cancel三阶段。// 微信支付服务wechat-pay-service DubboService public class WechatPayTccService implements TccAction { Override TwoPhaseBusinessAction(name wechatPayTry, commitMethod confirm, rollbackMethod cancel) public boolean prepare(BusinessActionContext actionContext, PayRequest req) { // Try 阶段调用微信统一下单 API获取 prepay_id本地记录支付流水statusTRYING String prepayId wechatApi.unifiedOrder(req); payMapper.insert(new PayRecord(req.getOrderId(), prepayId, TRYING)); return true; } public boolean confirm(BusinessActionContext actionContext) { // Confirm 阶段查询微信支付结果更新 statusSUCCESS String orderId actionContext.getAttachment(orderId); PayRecord record payMapper.selectByOrderId(orderId); String result wechatApi.query(record.getPrepayId()); if (SUCCESS.equals(result)) { payMapper.updateStatus(orderId, SUCCESS); return true; } return false; } public boolean cancel(BusinessActionContext actionContext) { // Cancel 阶段调用微信关单 API更新 statusCANCELLED String orderId actionContext.getAttachment(orderId); PayRecord record payMapper.selectByOrderId(orderId); wechatApi.closeOrder(record.getPrepayId()); payMapper.updateStatus(orderId, CANCELLED); return true; } }订单服务在createOrder中调用wechatPayTccService.prepare(...)Seata 自动协调 Confirm/Cancel。4.4 Saga 状态机复杂长流程如售后退款用 JSON DSL 定义避免硬编码退货退款涉及取消订单 → 释放库存 → 退用户款 → 通知商家 → 关闭物流单。步骤多、失败点分散、需人工干预。我们用 Seata Saga 模式定义refund.saga.json{ name: refund-saga, states: [ { name: cancelOrder, type: ServiceTask, serviceName: order-service, serviceMethod: cancelOrder, compensateServiceName: order-service, compensateServiceMethod: restoreOrder }, { name: releaseStock, type: ServiceTask, serviceName: merchant-service, serviceMethod: releaseStock, compensateServiceName: merchant-service, compensateServiceMethod: freezeStock }, { name: refundMoney, type: ServiceTask, serviceName: client-service, serviceMethod: refundMoney, compensateServiceName: client-service, compensateServiceMethod: deductBalance } ], startState: cancelOrder, endState: refundMoney }Saga 引擎自动执行、失败回滚、持久化状态比手写状态机代码更可靠、易维护。5. 避坑指南SpringCloud O2O 四端架构中 5 个血泪经验总结5.1 现象Nacos 配置中心修改后部分服务未实时刷新重启才生效原因Nacos 客户端默认使用长轮询Long Polling但某些云厂商 SLB 或防火墙会中断 30s 以上连接导致配置变更丢失同时RefreshScope注解未加在所有需要刷新的 Bean 上。解决① 在application.yml中显式配置长轮询超时spring: cloud: nacos: config: timeout: 10000 # 缩短超时至 10s避免连接挂起 max-retry: 3 # 失败重试次数② 所有含Value(${xxx})的类必须加RefreshScope包括ConfigurationProperties类③ 生产环境禁用RefreshScope的Bean方法改用ApplicationContext.getBean()动态获取。5.2 现象Gateway 路由到 merchant-service 后Feign 调用 client-service 失败报No instances available for client-service原因Feign 默认使用 Ribbon 负载均衡而 Ribbon 的服务发现依赖DiscoveryClient但 Gateway 的lb://协议已绕过 Ribbon直接走 ReactorLoadBalancer若 merchant-service 未正确引入spring-cloud-starter-loadbalancer则其内部 Feign 无法发现 client-service。解决① 所有业务服务client/merchant/rider/order的pom.xml必须同时引入dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-loadbalancer/artifactId /dependency dependency groupIdorg.springframework.cloud/groupId artifactIdspring-cloud-starter-openfeign/artifactId /dependency② 禁用 Ribbonspring.cloud.loadbalancer.ribbon.enabledfalse③ FeignClient 接口必须标注FeignClient(contextId clientService, value client-service)避免 contextId 冲突。5.3 现象Seata 全局事务中order-service 插入订单成功但 client-service 扣余额失败order 订单未回滚原因Seata AT 模式要求所有参与方数据源必须被 Seata 代理若 client-service 使用了 Druid 多数据源如主库报表库而只代理了主数据源则扣余额操作未进入全局事务。解决① 检查client-service的DataSourceProxy是否包装了所有业务数据源② 在DruidDataSource初始化后必须用new DataSourceProxy(druidDataSource)包装③ 日志中搜索Branch Register确认 client-service 是否向 TC 注册了 branch若无则说明数据源未被代理。5.4 现象Redis 缓存穿透大量请求击穿到 DBCPU 突增 90%原因商家端商品详情页用GET product:{id}查询但恶意请求构造不存在的id如product:999999999缓存未命中DB 直接查询返回 null且未对该 key 设置空值缓存。解决① 所有缓存查询必须做空值缓存SET product:999999999 null EX 60② 使用布隆过滤器前置拦截启动时加载所有有效商品 ID 到布隆过滤器RedisBloom 模块查询前先BF.EXISTS product_bf 999999999③ 对高频恶意 key如product:-1、product:abc做 IP 限流用 SentinelSentinelResource拦截。5.5 现象总后台 Admin 查询“昨日订单 TOP10 商家”响应超时 30s原因总后台直接 JOIN 四个库的表order merchant client riderMySQL 无法跨库关联实际执行的是笛卡尔积 应用层内存聚合数据量达百万级。解决① 总后台不直连业务库改为消费 Kafka 订单埋点 Topicorder-created用 Flink 实时计算 TOP10结果写入 Elasticsearch② 或使用 ShardingSphere-Proxy 作为数据库中间件配置broadcast表merchant_info和sharding表order_info让 SQL 在 Proxy 层下推执行③ 禁止总后台写任何SELECT * FROM ... JOIN ...所有报表查询必须走预聚合宽表每日凌晨 ETL 生成dws_order_merchant_daily。6. 总后台数据聚合实战用 Kafka Flink 实现实时订单看板替代慢 SQL 和定时任务6.1 为什么总后台不能直连业务库——数据耦合与性能雪崩的双重陷阱我见过太多项目总后台一个“实时销量榜”接口直接SELECT m.name, COUNT(*) FROM order o JOIN merchant m ON o.merchant_id m.id WHERE o.create_time 2024-06-01 GROUP BY m.name ORDER BY COUNT(*) DESC LIMIT 10结果订单库 CPU 100%影响 C端下单。根源在于总后台和业务库共享同一套 MySQL 实例慢查询拖垮整个 OLTP 链路。解耦唯一路径是业务库只写总后台只读中间用消息队列做数据管道流计算引擎做实时聚合。6.2 四端埋点统一 Schema 设计用 Avro 定义事件结构避免 JSON 字段歧义我们定义核心事件 SchemaOrderCreatedEvent.avsc{ type: record, name: OrderCreatedEvent, namespace: com.eleme.event, fields: [ {name: event_id, type: string}, {name: order_id, type: string}, {name: merchant_id, type: string}, {name: client_id, type: string}, {name: rider_id, type: [string, null]}, {name: total_amount, type: double}, {name: create_time, type: long}, // Unix timestamp millis {name: city_code, type: string}, {name: items_count, type: int} ] }所有端client/merchant/order/rider在订单创建成功后发送此 Avro 序列化消息到 Kafka Topicorder-created。Avro 比 JSON 体积小 40%且 Schema Registry 保证前后兼容——新增字段discount_amount不影响旧消费者。6.3 Flink 实时聚合作业每分钟统计各城市 TOP10 商家写入 ElasticsearchFlink 作业代码Scalaval env StreamExecutionEnvironment.getExecutionEnvironment env.enableCheckpointing(60000) // 60s checkpoint val kafkaSource KafkaSource.builder[String] .setBootstrapServers(kafka:9092) .setGroupId(flink-order-consumer) .setTopics(order-created) .setValueOnlyDeserializer(new SimpleStringSchema) .build() val orderStream env.fromSource(kafkaSource, WatermarkStrategy.noWatermarks(), Kafka Source) .map(json { val parser new JsonParser() val root parser.parse(json).getAsJsonObject OrderCreatedEvent( root.get(event_id).getAsString, root.get(order_id).getAsString, root.get(merchant_id).getAsString, root.get(client_id).getAsString, Option(root.get(rider_id)).map(_.getAsString).orNull, root.get(total_amount).getAsDouble, root.get(create_time).getAsLong, root.get(city_code).getAsString, root.get(items_count).getAsInt ) }) // 按 city_code merchant_id 滚动窗口聚合1分钟 val top10Stream orderStream .keyBy(_.cityCode, _.merchantId) .window(TumblingEventTimeWindows.of(Time.minutes(1))) .aggregate(new OrderAggregateFunction) // 写入 ES val esSink new ElasticsearchSink.Builder[String]( Collections.singletonList(new HttpHost(es:9200, 9200, http)), new ElasticsearchSinkFunction[String] { override def process(element: String, context: RuntimeContext, sinkFunction: RequestIndexer): Unit { val doc Map( timestamp - System.currentTimeMillis(), city_code - element.split(|)(0), merchant_id - element.split(|)(1), order_count - element.split(|)(2).toInt, total_amount - element.split(|)(3).toDouble ).asJava val indexRequest Requests.indexRequest() .index(order_top10_daily) .source(doc, XContentType.JSON) sinkFunction.add(indexRequest) } } ) top10Stream.map(t s${t._1}|${t._2}|${t._3}|${t._4}) .addSink(esSink)OrderAggregateFunction内部实现add/getResult/merge每分钟输出一条city|merchant|count|amount字符串。6.4 总后台前端对接用 Elasticsearch DSL 替代 SQL实现亚秒级响应总后台查询接口不再走 MySQL而是调用 ES// admin-service/src/main/java/com/eleme/admin/controller/DashboardController.java GetMapping(/dashboard/top-merchants) public ListTopMerchant getTopMerchants(RequestParam String cityCode) { SearchRequest searchRequest new SearchRequest(order_top10_daily); SearchSourceBuilder sourceBuilder new SearchSourceBuilder(); sourceBuilder.query(QueryBuilders.termQuery(city_code, cityCode)); sourceBuilder.sort(SortBuilders.fieldSort(order_count).order(SortOrder.DESC)); sourceBuilder.size(10); searchRequest.source(sourceBuilder); SearchResponse response restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); return Arrays.stream(response.getHits().getHits()) .map(hit - { MapString, Object source hit.getSourceAsMap(); return new TopMerchant( (String) source.get(merchant_id), ((Number) source.get(order_count)).intValue(), ((Number) source.get(total_amount)).doubleValue() ); }) .collect(Collectors.toList()); }实测1000 万订单数据ES 聚合响应 300ms而 MySQL JOIN 需 25s。这才是真正“实时”的含义。我带过的三个 O2O 项目前两个用慢 SQL 抗了半年最后都重构为 KafkaFlinkES 架构。不是因为技术炫酷而是当订单量突破 50 万/天那个“实时销量榜”就不再是锦上添花的功能而是运营决策的生命线。现在我的习惯是任何总后台报表需求第一反应不是写 SQL而是画 Kafka Topic 和 Flink DAG 图。希望帮到你。本文还有配套的精品资源点击获取