系列最后一篇，把视角从「当下怎么做」拉到「未来怎么走」。趣玩搭当前 DAU 约 1,200，目标是在 3 年内支撑百万 DAU。本文给出分阶段演进路线图，以及必须提前准备的风险预案。

一、演进的核心理念

在展开具体阶段之前，先明确一个原则：每个阶段只解决当前阶段的核心瓶颈。

很多技术团队容易犯的错误是在千人 DAU 的阶段就去搞异地多活和 Service Mesh，投入巨大但收益极小。我们的策略是按 DAU 里程碑设置触发条件，达到了才启动对应升级，没达到就不动。

省下来的精力做什么？打磨产品体验、跑通核心业务——这些才是从千人到万人的真正驱动力。

二、四阶段演进路线

Phase 1：夯实基础（DAU < 1 万）

核心瓶颈：链路不可观测，出了问题靠猜。

关键动作：

  1. 完成微服务拆分：从当前单体迁移至 15 个服务，每个服务独立仓库与 CI/CD 流水线

  2. 建立可观测性体系：接入 SkyWalking 全链路追踪 + Prometheus 监控 + Grafana 大盘

  3. 数据库读写分离：1 主 2 从，业务代码标注 @ReadOnly 注解自动路由

  4. Redis 高可用：从主从升级为 Sentinel 哨兵模式

  5. 自动化测试：核心链路覆盖率达到 80% 以上

预计时间：0–6 个月

这个阶段最重要的产出不是性能提升，而是你能看到系统在发生什么。没有可观测性的微服务架构就是盲人开车。

Phase 2：弹性扩展（DAU 1 万–10 万）

核心瓶颈：单机性能天花板，无法应对流量尖峰。

关键动作：

  1. K8s 容器化部署：所有服务容器化，HPA 按 CPU / QPS 自动扩缩容

  2. 订单分库分表：8 库 16 表，ShardingSphere-JDBC 接入

  3. Redis Cluster：6 节点起步，秒杀场景支撑 5 万 QPS

  4. 二级缓存：引入 Caffeine 本地缓存 + Redis，热点活动数据就近读取

  5. MQ 扩容：RocketMQ 分区数扩展至 16，消费端并行度提升

  6. ES 集群扩展：5 节点，索引分片策略调优

预计时间：6–12 个月

这个阶段的核心思路是"水平扩展"——通过加机器而不是优化单机来解决性能问题。K8s + HPA 让扩容可以自动化完成，不再需要半夜起来手动加机器。

Phase 3：精细治理（DAU 10 万–50 万）

核心瓶颈：流量治理粗粒度，数据利用不充分。

关键动作：

  1. Service Mesh（Istio）：灰度发布、流量染色、故障注入测试

  2. 实时数据平台：Flink + Kafka + ClickHouse，支撑运营实时看板

  3. 推荐系统升级：从离线批计算迁移至近实时增量更新，Flink 实时特征工程

  4. 多级限流：Sentinel 集群流控 + 网关层令牌桶 + 业务层自适应降级

  5. TiDB 试点：替代部分分库分表场景，简化运维复杂度

  6. Feature Flag 平台：统一配置中心与特性开关，支撑精细化实验

预计时间：12–24 个月

这个阶段开始从"能用"走向"好用"。Service Mesh 让流量治理精细到请求级别，实时数据平台让运营决策从"拍脑袋"变成"看数据"。

Phase 4：规模化（DAU 50 万–100 万+）

核心瓶颈：单地域可用性不足，跨地域体验差。

关键动作：

  1. 多可用区部署：核心服务（订单、支付）跨 AZ 双活

  2. 数据异地同步：DTS / Canal + MQ，RPO < 1 分钟

  3. 边缘计算：CDN + 边缘节点下沉，静态资源与部分 API 响应边缘缓存

  4. 混沌工程：全面落地 Chaos Mesh，定期演练故障场景

  5. AI 推荐深化：引入实时 CTR 预估模型，千人千面个性化推荐

  6. IM 自建长连接网关：Netty 自建替代融云，降低成本，支撑万人群聊

  7. 组织架构调整：按领域组建全功能 Squad（开发 + 测试 + 运维 + 产品）

预计时间：24–36 个月

到了这个阶段，技术挑战和组织挑战是并行的。50 万+ DAU 意味着团队规模可能达到 80–100 人，Conway 定律告诉我们，系统架构会趋向组织结构。Squad 模式是目前业界证明有效的大规模研发组织方式。

演进总览

阶段

DAU 区间

核心瓶颈

关键动作

预计时间

Phase 1

< 1 万

链路不可观测

微服务拆分 + 监控体系

0–6 月

Phase 2

1–10 万

单机性能天花板

K8s + 分库分表 + Redis 集群

6–12 月

Phase 3

10–50 万

流量治理与数据

Service Mesh + 实时数据平台

12–24 月

Phase 4

50–100 万+

可用性与容灾

多 AZ 双活 + 混沌工程

24–36 月

三、其他关键方案速览

在演进过程中，还有几个横向能力需要同步建设。

3.1 LBS 活动推荐

Redis GEO 存储活动坐标，GEORADIUS 检索附近活动，配合 ES 做多维过滤（类别、时间、价格区间）。推荐算法基于用户兴趣标签的余弦相似度 + 距离衰减因子，离线计算生成推荐列表缓存至 Redis，实时展示时仅做召回层过滤。Phase 3 升级为 Flink 近实时特征更新。

3.2 分布式 ID 生成

订单号采用美团 Leaf 号段模式，格式为：时间前缀（yyMMdd）+ 6 位 Leaf 序列号 + 2 位分库路由键后缀。这样通过订单号就能直接定位分片，避免广播查询。

3.3 IM 消息架构

Phase 1–3 使用融云 SDK 托管长连接，活动群聊在活动创建时自动建群，报名成功后自动拉入。系统消息通过融云服务端 API 推送，本地留存一份至消息中心表。Phase 4 视成本评估是否自建 Netty 长连接网关。

3.4 内容审核流水线

三级流水线：第一级本地敏感词库（DFA 算法，毫秒级）→ 第二级 LLM 语义审核（识别隐晦违规）→ 第三级人工复核队列。图片审核对接数美 API，异步回调更新审核状态。

四、六大核心风险与应对

任何架构设计都不能只画美好蓝图，必须正视可能出问题的地方。以下是我们识别的六大风险及预案：

风险

影响

应对策略

秒杀超卖

资金损失、用户投诉

Redis Lua 原子扣减 + DB CHECK 约束 + 定时校准

支付掉单

用户已付款但未出票

支付回调重试 + T+1 对账补偿 + 人工处理通道

MQ 消息丢失

订单创建遗漏

RocketMQ 同步刷盘 + 本地消息表兜底

Redis 集群故障

缓存雪崩

多级缓存降级 + 热 key 本地缓存 + 限流保护 DB

三方服务不可用

融云/数美/微信宕机

超时熔断 + 降级方案（离线消息补推 / 人工审核）

数据不一致

账务差异

三层对账 + 告警 + 人工复核 + 事务日志审计

展开说几个重点：

支付掉单

这是交易系统最常见也最头疼的问题。微信支付回调可能因为网络抖动丢失，用户已扣款但平台不知道。我们的防线是：

  • 主动查单：支付发起后，延迟 5 秒主动查询微信支付状态，不完全依赖回调

  • 定时补偿：XXL-JOB 每 5 分钟扫描超时未收到回调的支付中订单，批量查单

  • T+1 对账兜底：前两层都没catch住的，在对账时一定能发现

MQ 消息丢失

RocketMQ 的默认配置是异步刷盘，极端宕机场景可能丢消息。我们的应对是：

  • 核心 Topic 开启同步刷盘（flushDiskType=SYNC_FLUSH），牺牲一点吞吐换可靠性

  • 本地消息表：业务写入数据库时同时写一条本地消息记录，后台线程扫描未投递成功的消息进行重试。这是经典的 Transactional Outbox Pattern

Redis 集群故障

Redis 全挂是小概率但高影响事件。降级策略是：

  • L1 缓存（Caffeine 本地缓存）继续提供热数据服务

  • 秒杀接口自动切换为「暂停售票」状态，前端展示排队页

  • 限流阈值自动下调至 DB 承受能力（如 500 QPS），保护数据库不被打垮

  • Redis 恢复后，从 DB 重建缓存数据

五、写在最后

趣玩搭的架构设计到这里就告一段落了。四篇文章从整体分层、服务拆分、关键方案到演进规划，试图完整地呈现一个 LBS 兴趣社交平台的架构全貌。

几点核心总结：

  • 架构服务于业务，不是业务服务于架构。所有技术决策都应该回到"这样做能解决什么业务问题"上来

  • 渐进式演进优于一步到位。千人 DAU 做千人 DAU 该做的事，百万 DAU 做百万 DAU 该做的事

  • 可观测性是一切的前提。没有监控和链路追踪，其他所有优化都是盲目的

  • 资金安全没有捷径。三层对账看起来很重，但每一层都有它存在的理由

许可协议

本文由 困困鱼 原创，采用 CC BY-NC-SA 4.0 许可协议，转载请注明出处。

分享文章

本站由 困困鱼 使用 Stellar 创建。