趣玩搭（FunPlay）是一个基于 LBS 的垂直领域兴趣社交平台，用户发布线下活动（露营、桌游、运动、读书会等），系统推荐匹配，其他用户报名支付参加。本文作为系列的开篇，梳理项目现状、架构分层与技术选型思路。
一、项目现状
先看几个关键数字：
日活用户：约 1,200
注册用户：6 万
日均活动发布：100+
日均订单：200+
技术团队：30 人
核心业务链路为：发布活动 → 推荐/搜索 → 报名/抢票 → 支付 → 即时通讯 → 活动完成 → 评价/积分。
平台基于 yudao-cloud 开发框架（Spring Cloud Alibaba + Nacos + RocketMQ + Vue），涵盖活动、票务、支付、订单、会员、俱乐部、交友匹配、IM、AI 客服、内容审核、营销等十余个业务模块。
二、架构设计原则
在动手拆服务、选技术之前，我们先对齐五条核心原则，后续所有决策都以此为锚：
最后一条尤其重要——千人 DAU 的项目上来就搞 Service Mesh 和异地多活，是典型的架构过度设计。我们的策略是"按需演进"，每个阶段只解决当前阶段的核心瓶颈。
三、整体架构分层
系统采用经典六层架构，自上而下依次为：
┌─────────────────────────────────────────────────┐
│ 接入层 │
│ 微信小程序 · H5 · 管理后台 │
│ Vue 3 + uni-app + Nginx/Ingress │
├─────────────────────────────────────────────────┤
│ 网关层 │
│ 统一鉴权 · 限流 · 路由 · 灰度发布 │
│ Spring Cloud Gateway + Sentinel │
├─────────────────────────────────────────────────┤
│ 业务服务层 │
│ 活动 · 票务 · 订单 · 支付 · 会员 · 营销 … │
│ Spring Boot 3 + Dubbo / Feign │
├─────────────────────────────────────────────────┤
│ 领域支撑层 │
│ 搜索 · 推荐 · IM · AI · 内容审核 │
│ ES + Milvus + 融云 + LLM │
├─────────────────────────────────────────────────┤
│ 数据层 │
│ 关系型 · 缓存 · 消息 · 对象存储 │
│ MySQL + Redis + RocketMQ + OSS │
├─────────────────────────────────────────────────┤
│ 基础设施层 │
│ 容器编排 · 监控 · CI/CD │
│ K8s + Prometheus + Grafana + GitLab CI │
└─────────────────────────────────────────────────┘请求链路：客户端 → CDN → Nginx/Ingress → Gateway（鉴权 + 限流 + 灰度路由）→ 业务微服务 → 数据层。服务间通信采用 Dubbo RPC（同步）+ RocketMQ（异步） 双模式。
四、技术选型
4.1 后端技术栈
几个关键决策的思考过程：
为什么选 Dubbo 而不是 Feign？ 当前规模下 Feign 完全够用，但考虑到后续抢票秒杀场景的性能需求，Dubbo Triple 协议在序列化效率和长连接复用上有明显优势。而且 Dubbo 3 与 Spring Cloud 的兼容性已经很好，可以渐进切换。
为什么选 RocketMQ 而不是 Kafka？ 趣玩搭的核心场景是交易链路（下单、支付、退款），RocketMQ 原生支持事务消息和延迟消息，这两个能力在我们的业务里高频使用。Kafka 更适合日志流和大数据管道，后续如果建设实时数据平台可以引入。
为什么选 ShardingSphere 而不是 TiDB？ 团队对 MySQL 更熟悉，ShardingSphere-JDBC 透明接入成本低。TiDB 在运维复杂度和成本上当前阶段 ROI 不高，列入 Phase 3 备选方案。
4.2 前端与客户端
4.3 基础设施
五、服务器选型与部署架构
我们按 DAU 增长划分三个阶段，每个阶段的基础设施配置如下：
阶段一：DAU < 5K —— 轻量云服务器
部署方式为 Docker Compose + Nginx 反向代理，Nacos 做服务注册与配置中心，数据库使用云厂商 RDS 托管。
阶段二：DAU 5K–50K —— K8s 集群
切换至 Kubernetes 集群部署，引入 Ingress Gateway 替代单点 Nginx，HPA 实现弹性伸缩。数据库升级为一主多从 + 读写分离，Redis 升级为 Cluster 模式。
阶段三：DAU 50K–100W —— 多 AZ + 异地多活
多可用区部署，核心服务跨 AZ 容灾。引入 TiDB 或分库分表（ShardingSphere）应对写入瓶颈。MQ 升级为 Kafka + RocketMQ 混合架构。引入 Service Mesh（Istio）实现流量治理、灰度发布与熔断。
下一篇：趣玩搭微服务拆分实战：15 个服务的领域划分与通信设计——详解如何基于 DDD 拆分微服务，以及服务间的同步/异步通信规范。