好生活集团系统架构设计文档

1、背景（或者叫目的、概述）

好生活集团是一家聚焦本地生活服务的互联网公司，致力于通过数字化手段提升居民"吃、购、住、服"一体化体验。当前公司同时运营三大核心业务：

快送达：即时外卖配送平台
邻里购：社区团购平台
安心帮：上门家政服务平台

随着用户规模增长（当前 MAU ≈ 50 万），各业务系统在早期采用独立建设模式，导致用户体系割裂、支付重复开发、运维成本高、数据无法打通等问题日益突出。

本架构设计目标：

构建统一的技术底座，实现用户、订单、支付、通知等能力复用；
保障系统高可用、可扩展、安全合规；
支撑未来 3 年业务增长（目标 DAU 100 万+）；
为后续向微服务演进奠定基础。

2、场景分析（或者叫需求分析）

2.1 业务场景

|-----|---------------------------|----------|
| 业务线 | 核心场景 | 日均单量（预估） |
| 快送达 | 用户点餐 → 餐厅接单 → 骑手配送 → 完成 | 8 万单 |
| 邻里购 | 用户拼团 → 团长开团 → 次日自提 → 分佣结算 | 5 万单 |
| 安心帮 | 用户预约 → 服务人员接单 → 上门服务 → 评价 | 1 万单 |

2.2 非功能性需求

|------|-------------------------------|
| 类别 | 要求 |
| 可用性 | 核心链路 99.9% 可用（全年宕机 ≤ 8.76 小时） |
| 性能 | 下单响应 < 800ms，支付成功 < 1.5s |
| 一致性 | 用户余额、优惠券、订单状态强一致 |
| 安全性 | 符合《网络安全法》，用户隐私数据加密存储 |
| 可观测性 | 全链路日志追踪、关键指标监控告警 |
| 可维护性 | 支持灰度发布、快速回滚 |

3、架构设计

3.1、总体架构

采用中心化统一服务平台架构，以"一个中心、三大业务、共享能力"为核心思想。

所有通用能力由中央核心系统提供，业务子系统专注领域逻辑。

✅ 优势：快速上线、数据一致、成本可控

⚠️ 风险：单点故障、扩展瓶颈（需通过高可用设计缓解）

3.2、业务架构

3.3、应用架构

企业级应用架构：

|-----|------------------------------|----------------|
| 层级 | 组件 | 职责 |
| 接入层 | API 网关（Spring Cloud Gateway） | 路由、认证、限流、日志 |
| 核心层 | 中央核心系统（单体应用） | 用户/订单/支付/通知/客服 |
| 业务层 | 快送达服务、邻里购服务、安心帮服务 | 各自领域逻辑 |
| 支撑层 | 文件存储（OSS）、短信服务、地图API | 第三方集成 |

单个系统的应用架构：

3.4、技术架构

语言：Java 17（Spring Boot 3.x）
数据库：
- MySQL 8.0（主从复制 + 读写分离）
- Redis 7（缓存 + 分布式锁）
中间件：
- RabbitMQ（异步解耦：如发短信、更新ES）
- Elasticsearch（订单搜索）
监控：
- Prometheus + Grafana（指标）
- SkyWalking（链路追踪）
- ELK（日志）

3.5、网络架构

用户 → CDN（静态资源）
用户 → 阿里云 SLB（负载均衡） → 应用服务器集群
应用服务器 → 内网访问数据库/Redis/MQ
所有公网流量经 WAF 防护，敏感接口 IP 白名单

3.6、部署架构

环境：DEV / TEST / STAGING / PROD
生产部署：
- 应用：4 台 ECS（8C16G），部署 Central Core + 3 个业务服务
- 数据库：RDS 高可用版（1 主 1 备）
- 缓存：Redis 哨兵模式（3 节点）
CI/CD：GitLab CI → Docker 镜像 → 阿里云 ACK（K8s 集群）

4、微服务设计

4.1、微服务功能边界

|-----------------|---------------|------------------------------------|
| 服务名 | 职责 | 关键接口 |
| user-service | 用户注册、登录、地址管理 | /users/{id}, /addresses |
| order-service | 全局订单创建、查询、状态机 | /orders, /orders/{id}/status |
| payment-service | 支付、退款、优惠券核销 | /payments/create, /coupons/use |
| food-service | 餐厅、菜单、骑手调度 | /restaurants, /dispatch |
| group-service | 拼团、团长、自提点 | /groups, /commisions |
| service-service | 服务人员、排班、评价 | /workers, /schedules |

5、系统上下文

6、核心流程

6.1 用户下单（以"快送达"为例）

App 调用 /order/create（含商品、地址、token）
网关鉴权 → 路由至中央订单中心
订单中心：
- 调 user-service 获取用户地址
- 调 payment-service 冻结金额
- 生成订单（状态=待支付）
- 发送 MQ 消息：order.created
food-service 监听 MQ，分配骑手
支付成功后，更新订单状态为"已支付"，触发配送

6.2 社区团购成团流程

用户参团 → group-service 扣减库存（Redis 原子操作）
达到成团人数 → 发送 group.success 事件
order-service 创建正式订单
payment-service 批量扣款
通知团长备货，用户次日自提

7、模型设计

7.1、用例模型

普通用户

骑手

团长

服务人员

管理员

7.2、数据模型

8、特性设计

8.1 可靠性设计

数据库：主从 + 自动切换（RDS HA）
缓存：Redis 哨兵，缓存穿透用布隆过滤器
异步：关键操作（如支付）走 MQ，失败重试 3 次
限流：Sentinel 对下单接口 QPS ≤ 1000
灾备：每日全量备份 + Binlog 增量，RPO < 5min

8.2 安全设计

认证：JWT + Refresh Token，Token 有效期 2h
授权：RBAC 模型，区分用户/团长/骑手/管理员
数据：
- 敏感字段（手机号）AES 加密存储
- HTTPS 全站强制
- SQL 注入/XSS 过滤（MyBatis + 前端转义）
审计：关键操作（如退款）记录操作日志

8.3 。。。

9、成本与收益估算

本节从投入成本与业务收益两个维度，对比"中心化统一架构"与"原有独立系统模式"，量化架构升级的 ROI（投资回报率）。

9.1 投入成本（中心化架构建设）

|-----------|-------------------------------------------------------------------------------------------|------------|---------------------|
| 项目 | 明细 | 金额（人民币） | 说明 |
| 人力成本 | 总计 80 人月（见第10节演进计划）按平均 2.5 万元/人月 | ¥2,000,000 | 含开发、测试、DevOps、架构、产品 |
| 云资源成本（首年） | - ECS × 8 台：¥3,000/月 - RDS 高可用：¥2,500/月 - Redis + MQ + OSS：¥1,500/月 - 监控/CDN/WAF：¥1,000/月 | ¥96,000 | 按阿里云华东2区标准配置 |
| 第三方服务 | 短信（100万条）、地图API、支付通道费 | ¥50,000 | 按实际用量预估 |
| 培训与迁移 | 旧系统数据迁移、团队培训 | ¥30,000 | 一次性支出 |
| 合计首年总投入 | --- | ¥2,176,000 | ≈ 218 万元 |

9.2 收益分析

（1）直接成本节约

|-----------|---------------|---------------|-----------------------|
| 项目 | 旧模式（三套独立系统） | 新模式（中心化） | 年节省 |
| 服务器资源 | ¥264,000/年 | ¥96,000/年 | ¥168,000 |
| 运维人力 | 需 3 名专职运维 | 1 名 DevOps 兼顾 | ¥480,000（按20k×2人×12月） |
| 开发重复投入 | 每个业务自建用户/支付模块 | 复用统一能力 | ¥600,000+（避免重复造轮子） |
| 年直接成本节约合计 | --- | --- | ≈ ¥1,248,000 |

（2）业务收益（隐性但高价值）

|--------|---------------------------------|-------------------------------|
| 收益类型 | 说明 | 估算价值 |
| 用户体验提升 | 用户一次注册，三端通用；优惠券跨业务使用 | 提升留存率 5%~8%，年增 GMV ≈ ¥500 万+ |
| 运营效率提升 | 统一用户画像支持精准营销（如"常点外卖用户推团购"） | 营销转化率提升 10%，年节省推广费 ¥200 万 |
| 故障响应提速 | 单一监控体系，MTTR（平均修复时间）从 2h → 20min | 减少资损与客诉，年避免损失 ¥100 万+ |
| 合规与安全 | 统一安全策略，降低数据泄露风险 | 避免潜在罚款（《网络安全法》最高 ¥100 万） |

9.3 ROI（投资回报率）测算

|--------------|----------------------------|
| 指标 | 数值 |
| 首年总投入 | ¥2.18M |
| 首年直接成本节约 | ¥1.25M |
| 首年业务收益（保守估计） | ¥3.0M |
| 首年总收益 | ¥4.25M |
| ROI（首年） | (4.25 - 2.18) / 2.18 ≈ 95% |
| 投资回收期 | < 7 个月 |

9.4 风险对冲说明

若业务增长不及预期，中心化架构的运维成本仍显著低于多套系统；
架构设计预留微服务演进路径，避免未来二次重构；
所有核心模块单元测试覆盖率 ≥ 80%，保障迁移质量。

10、版本演进计划

本演进计划采用"稳中求进"策略：先统一底座，再逐步解耦，避免一次性重构带来的业务风险。人力配置基于标准互联网团队模型（后端、前端、测试、DevOps、产品、架构）。

|-------------------|--------------|---------------------------------|------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|------|-------------------------|
| 阶段 | 时间 | 目标 | 关键交付物 | 所需角色与人力（人月） | 总人月 | 备注 |
| Phase 1：中心化统一平台上线 | 2026 Q1（3个月） | 完成三大业务迁移至中心化架构，统一用户、订单、支付体系 | - 中央核心系统 V1.0 - 快送达/邻里购/安心帮子系统 - 统一网关 + 监控告警体系 | - 后端开发 ×4（12人月） - 前端 ×2（6人月） - 测试 ×2（6人月） - DevOps ×1（3人月） - 架构师 ×1（3人月） - 产品经理 ×1（3人月） | 33人月 | 核心阶段，需保障平滑迁移，旧系统并行运行1个月 |
| Phase 2：核心能力微服务拆分 | 2026 Q3（2个月） | 拆分用户中心、订单中心为独立微服务，实现服务注册发现与链路追踪 | - user-service - order-service - 服务治理平台（Nacos + Sentinel） - 全链路追踪（SkyWalking） | - 后端开发 ×3（6人月） - DevOps ×1（2人月） - 架构师 ×1（2人月） - 测试 ×1（2人月） | 12人月 | 仅拆分通用能力，业务子系统仍调用新服务 |
| Phase 3：全面微服务化 | 2027 Q1（3个月） | 三大业务子系统完全自治，引入事件驱动与最终一致性 | - food-service / group-service / service-service - Kafka 消息总线 - 分布式事务方案（Seata/TCC） | - 后端开发 ×5（15人月） - DevOps ×1（3人月） - 架构师 ×1（3人月） - 测试 ×2（6人月） | 27人月 | 需重构数据同步逻辑，重点保障一致性 |
| Phase 4：智能化与扩展 | 2027 Q4（2个月） | 引入用户画像与推荐引擎，支持跨业务营销 | - 用户行为埋点系统 - 简易推荐引擎（规则+协同过滤） - 营销活动中心 | - 后端开发 ×2（4人月） - 数据工程师 ×1（2人月） - 产品经理 ×1（2人月） | 8人月 | 轻量级AI，不依赖大模型 |

📊 人力汇总

总周期：约10个月（含缓冲期）
总人月投入：33 + 12 + 27 + 8 = 80人月
峰值人力：Phase 1（11人并行），Phase 3（9人并行）

🔑 关键人力说明

后端开发：主力，负责业务逻辑、接口、数据库设计
DevOps：保障CI/CD、K8s部署、监控告警
架构师：主导技术选型、拆分边界、风险控制（全程参与）
测试：自动化覆盖核心链路（下单、支付、退款）
产品经理：定义迁移范围、验收业务一致性