麦瓣健康 - APP产品开发方案

项目名称: 麦瓣健康 - 康护到家上门服务平台

团队规模: 5人（产品1 + 后端2 + Flutter前端1 + 全栈1）

开发周期:

• 一期：12周（3个月）MVP核心功能上线
• 二期：8周（2个月）增值功能与优化

文档日期: 2025-10-20 最后更新: 2025-10-27

一、产品定位

核心定位

O2O专业医疗护理服务平台，连接有康复护理需求的家庭与专业护理师，提供老年人康复护理、孕产妇专业护理、慢病管理等上门服务。

服务类别（5大类）

平台提供5大服务类别，满足不同用户群体的健康管理需求：

目标用户

C端用户（6大群体）:

B端护理师: 持证护士、康复师、育婴师，提供专业上门护理服务。根据服务类别有不同准入要求：

• 专业严选：线下考核入驻（高级认证）
• 健康管理：持有专业证书，仅限女性技师
• 其他类别：持有专业证书均可注册

商业模式

• 平台撮合模式: 连接用户与护理师
• 收入来源:
  • 服务佣金（主）：15%-25%佣金
  • 护理套餐（辅）：周卡/月卡/季卡/年卡
  • 健康管理增值服务
  • 团购业务：肩颈快按支持企业团购，批量采购优惠

二、产品架构

系统架构图

主架构：康护到家系统分层架构

graph TB
    A[客户端层<br/>3个应用端]
    B[API网关层<br/>Spring Cloud Gateway]
    C[微服务层<br/>10个微服务]
    D[服务治理层<br/>Nacos]
    E[数据存储层<br/>MySQL/Redis/MQ/OSS]
    F[第三方服务层<br/>支付/地图/推送/认证]

    A -.HTTPS/REST/WebSocket.-> B
    B --> C
    C --> D
    C --> E
    C --> F

    style A fill:#e1f5ff
    style B fill:#fff4e1
    style C fill:#e8f5e9
    style D fill:#f3e5f5
    style E fill:#fff3e0
    style F fill:#fce4ec

架构说明

• 客户端层: 用户端APP（Flutter）、护理师端APP（Flutter）、管理后台Web（React）
• API网关层: 统一入口，负责路由、限流、认证鉴权
• 微服务层: 10个Spring Boot微服务，业务核心层
• 服务治理层: Nacos实现服务注册发现与配置管理
• 数据存储层: MySQL主从、Redis集群、RabbitMQ、阿里云OSS
• 第三方服务层: 支付、地图、推送、身份认证等外部服务

子架构1：客户端层架构

graph LR
    subgraph 用户端APP
        A1[Flutter<br/>iOS/Android]
        A1_1[订单流程]
        A1_2[护理师选择]
        A1_3[健康档案]
        A1_4[个人中心]
    end

    subgraph 护理师端APP
        A3[Flutter<br/>iOS/Android]
        A3_1[接单管理]
        A3_2[服务流程]
        A3_3[护理日志]
        A3_4[收入提现]
    end

    subgraph 管理后台Web
        A4[React<br/>Ant Design]
        A4_1[用户管理]
        A4_2[护理师审核]
        A4_3[订单管理]
        A4_4[财务报表]
    end

子架构2：微服务层架构

graph TB
    subgraph 核心业务服务
        S1[订单服务<br/>订单创建/状态流转/查询/预约]
        S2[支付服务<br/>微信支付/支付宝/退款/流水]
        S3[用户服务<br/>注册登录/实名认证/成员管理]
        S4[护理师服务<br/>注册审核/状态管理/推荐算法]
    end

    subgraph 辅助支撑服务
        S5[消息推送服务<br/>极光推送/WebSocket/订单通知]
        S6[地图服务<br/>高德API/距离计算/位置追踪]
        S7[健康档案服务<br/>档案CRUD/病史/体征管理]
        S8[护理日志服务<br/>护理记录/体征/照片/OSS]
    end

    subgraph 财务管理服务
        S9[财务结算服务<br/>佣金计算/分账/提现/报表]
        S10[套餐服务<br/>套餐管理/购买/核销/有效期]
    end

    S1 --> S2
    S1 --> S5
    S4 --> S6
    S8 --> S7
    S2 --> S9

子架构3：数据存储层架构

graph TB
    subgraph MySQL主从
        M1[MySQL主库<br/>写入]
        M2[MySQL从库<br/>读取]
        M1 -.主从复制.-> M2
    end

    subgraph Redis集群
        R1[缓存层<br/>护理师/订单/档案]
        R2[分布式锁<br/>抢单/扣费]
        R3[实时数据<br/>状态/位置]
    end

    subgraph RabbitMQ
        Q1[消息队列<br/>异步处理]
    end

    subgraph 阿里云OSS
        O1[对象存储<br/>图片/文件]
    end

    SVC[微服务层] --> M1 & M2
    SVC --> R1 & R2 & R3
    SVC --> Q1
    SVC --> O1

子架构4：第三方服务集成架构

graph LR
    subgraph 支付集成
        PAY1[微信支付]
        PAY2[支付宝支付]
    end

    subgraph 地图集成
        MAP[高德地图API]
    end

    subgraph 消息推送
        PUSH[极光推送]
    end

    subgraph 身份认证
        AUTH1[阿里云短信]
        AUTH2[实人认证]
        AUTH3[人脸识别]
    end

    PSVC[支付服务] --> PAY1 & PAY2
    LSVC[地图服务] --> MAP
    MSVC[推送服务] --> PUSH
    USVC[用户服务] --> AUTH1 & AUTH2 & AUTH3
    NSVC[护理师服务] --> AUTH2 & AUTH3

子架构5：数据流转架构

sequenceDiagram
    participant C as 客户端
    participant G as 网关
    participant S as 微服务
    participant DB as 数据层

    Note over C,DB: 写操作
    C->>G: 请求
    G->>S: 转发
    S->>DB: 写入
    S-->>C: 返回

    Note over C,DB: 读操作
    C->>G: 请求
    G->>S: 转发
    S->>DB: 查询(缓存优先)
    S-->>C: 返回

    Note over S,DB: 异步处理
    S->>DB: 消息队列
    DB-->>S: 异步消费

数据流转说明

• 写操作: 客户端 → 网关 → 微服务 → 数据层(MySQL主库+缓存更新+消息队列)
• 读操作: 客户端 → 网关 → 微服务 → 数据层(Redis缓存优先,未命中查MySQL从库)
• 异步任务: 微服务 → RabbitMQ → 消费者微服务
• 文件上传: 客户端 → 微服务 → 阿里云OSS

三端架构说明

1. 用户端APP

• 平台: iOS + Android
• 技术栈: Flutter 3.x
• 核心功能: 浏览护理师、选择护理服务、下单支付、订单追踪、健康档案
• 支付方式: 微信支付、支付宝支付、余额支付

2. 护理师端APP

• 平台: iOS + Android
• 技术栈: Flutter 3.x
• 核心功能: 接单管理、导航、服务记录、收入提现、护理日志

3. 管理后台Web

• 技术栈: React 18 + Ant Design 5.x + TypeScript
• 核心功能: 用户管理、护理师审核、订单管理、财务结算、数据分析

微服务架构说明

核心微服务（10个）

1. 订单服务 - 订单创建、状态流转、订单查询、预约管理
2. 支付服务 - 微信/支付宝支付、退款、支付流水
3. 用户服务 - 用户注册登录、实名认证、家庭成员管理
4. 护理师服务 - 护理师注册、资质审核、在线状态、推荐算法
5. 消息推送服务 - 极光推送、RabbitMQ异步消息
6. 地图服务 - 高德地图集成、距离计算、位置追踪
7. 健康档案服务 - 健康档案CRUD、体征数据管理
8. 护理日志服务 - 护理记录、体征数据、照片存储
9. 财务结算服务 - 佣金计算、分账、提现审核
10. 套餐服务 - 套餐管理、购买、核销

服务间通信

• 同步调用: OpenFeign（服务间REST调用）
• 异步通信: RabbitMQ消息队列
• 服务注册: Nacos（服务发现与健康检查）
• 配置管理: Nacos Config（统一配置中心）

三、完整功能清单

3.1 用户端APP功能（173个功能点，v2.0）

详细功能文档: 请参见 用户端APP功能清单.md

该文档包含完整的功能说明、业务规则、技术实现、测试用例、数据埋点等详细内容。

v2.0 版本更新说明

结合《麦瓣健康项目规划》，v2.0版本新增8个核心功能，优化服务分类和用户体验：

功能模块概览（26个模块，173个功能点）

核心业务模块（7个模块，53个功能）:

• 账户系统 (4个) - 注册登录、实名认证
• 首页与护理师选择 (13个) - 护理师列表、筛选、详情、推荐、服务类别展示、用户群体识别
• 下单与支付 (11个) - 服务选择、预约、支付、团购下单、差异化预约、营业时间智能提示
• 订单管理 (9个) - 订单列表/详情、实时追踪、退款、心率监测记录、团购订单管理
• 健康档案 (4个) - 家庭成员、健康记录、护理日志
• 评价与反馈 (3个) - 服务评价、投诉建议
• 个人中心 (8个) - 个人信息、地址管理、余额充值、客服

增值服务模块（4个模块，21个功能）:

• 服务项目管理 (3个) - 项目详情、分类浏览、服务类别详细说明
• 积分系统 (5个) - 积分累计、升级、兑换、明细
• 会员系统 (6个) - 会员购买、AI体测、折扣、活动券
• 健康管理 (7个) - 体检报告AI分析、身体对应点、推荐、健康计划

核心功能快速索引

P0核心功能（必须开发）:

• 手机号注册/登录、实名认证
• 5大服务类别展示、营业时间显示、用户群体识别
• 护理师列表/详情、下单支付
• 选择服务类别、差异化预约时间、营业时间智能提示
• 订单列表/详情、取消订单、心率监测记录查看
• 家庭成员管理、个人信息、地址管理

P1重要功能（优先开发）:

• 微信授权登录、护理师筛选/推荐
• 团购下单（肩颈快按）、团购订单管理
• 预约时间、健康信息填写、实时位置追踪
• 服务延时、申请退款、护理日志查看
• 健康档案、护理记录、余额充值、护理套餐
• 服务类别详细说明、专业严选客服咨询

P2可选功能（可延后）:

• 账号注销、收藏护理师、搜索护理师
• 健康资讯、健康报告、邀请好友、历史评价

详细功能说明请查看: 用户端APP功能清单.md

3.2 护理师端APP功能（70个功能点，v2.0）

详细功能文档: 请参见 护理师端APP功能清单.md

该文档包含完整的功能说明、业务规则、技术实现、测试用例、数据埋点等详细内容。

v2.0 版本更新说明

结合《麦瓣健康项目规划》，v2.0版本新增10个核心功能，优化服务类别管理和安全保障：

功能模块概览（11个模块，70个功能点）

核心功能快速索引

P0核心功能（必须开发）:

• 手机号注册/登录、实名认证、资质审核、服务类别选择、性别验证
• 在线/离线切换、新订单提醒、接单/拒单、用户群体标签展示
• 导航、到达打卡、开始/结束服务、护理日志、操作前心率监测
• 服务项目配置、资质匹配验证
• 收入统计、提现
• 个人资料、证书管理、营业时间设置

P1重要功能（优先开发）:

• AI智能推荐、消息中心、团购订单管理
• 里程计算、服务延时、考核单生成、时薪显示
• 提成计算、里程补贴、佣金规则
• 服务范围设置、评价管理、业绩统计
• 服务类别切换、专业严选客服咨询、服务前准备清单

P2可选功能（可延后）:

• 学习中心、高级数据统计

详细功能说明请查看: 护理师端APP功能清单.md

3.3 管理后台功能（32个功能点）

详细功能文档: 请参见 管理后台功能清单.md

该文档包含完整的功能说明、业务规则、技术实现、测试用例、数据埋点等详细内容。

功能模块概览

详细功能说明请查看: 管理后台功能清单.md

四、技术架构方案

4.1 前端技术栈

用户端APP

• 跨平台框架: Flutter 3.x
• 状态管理: Riverpod / Provider
• 网络请求: Dio + Retrofit
• 本地存储: SharedPreferences + Hive
• 地图: 高德地图Flutter插件
• 支付: 微信支付SDK + 支付宝SDK
• 推送: 极光推送JPush
• 图表: fl_chart

管理后台Web

• 框架: React 18 + TypeScript
• UI组件: Ant Design 5.x
• 状态管理: Redux Toolkit / Zustand
• HTTP客户端: Axios
• 路由: React Router v6
• 图表: ECharts / Ant Design Charts
• 构建工具: Vite

4.2 后端技术栈

详细技术文档: 请参见 后端技术架构文档.md

该文档包含完整的微服务架构设计、技术选型说明、实现指南、部署方案、监控日志等16个章节的详细内容。

技术架构概览

微服务模块

详细技术实现请查看: 后端技术架构文档.md

4.3 第三方服务集成配置

4.3.1 微信支付配置

APP端微信支付

APP端微信支付

配置步骤:

1. 登录微信商户平台获取商户号
2. 下载商户私钥证书apiclient_key.pem
3. 设置APIv3密钥(32字节随机字符串)
4. 获取证书序列号
5. 配置支付回调域名白名单

4.3.2 支付宝支付配置

配置步骤:

1. 登录支付宝开放平台创建应用
2. 生成RSA2密钥对
3. 上传应用公钥,获取支付宝公钥
4. 配置授权回调地址和支付回调地址
5. 提交应用审核上线

4.3.3 高德地图配置

• 服务端Web API
• Flutter端配置
• 微信APP

4.3.4 极光推送配置

• Flutter配置
• APP推送(微信模板消息)

4.3.5 阿里云OSS配置

配置步骤:

1. 登录阿里云OSS控制台创建Bucket
2. 设置Bucket访问权限(推荐私有读写,通过签名URL访问)
3. 创建RAM子账号,授予OSS读写权限
4. 配置跨域规则CORS允许前端直传
5. 设置生命周期规则自动删除过期文件

4.3.6 阿里云短信服务配置

配置步骤:

1. 登录阿里云短信服务控制台
2. 申请短信签名(需企业资质,2-3个工作日审核)
3. 申请短信模板(不同场景需不同模板)
4. 创建RAM子账号,授予短信发送权限
5. 购买短信套餐包

4.3.7 实名认证配置(阿里云)

配置步骤:

1. 登录阿里云实人认证控制台
2. 开通实人认证服务
3. 选择认证方案(人脸识别+身份证OCR)
4. 配置回调地址
5. 购买认证次数包(按次计费)

4.3.8 Nacos配置中心

• Nacos Server部署
• Spring Boot微服务配置

4.3.9 环境变量安全管理

• 敏感信息不要硬编码,使用环境变量
• Spring Boot读取环境变量

4.3.10 第三方服务成本预估

成本优化建议:

1. 高德地图API使用缓存,减少重复调用
2. OSS配置生命周期,自动清理过期文件
3. 短信验证码添加图形验证码前置,防止恶意刷短信
4. 推送服务区分重要通知和普通通知,降低推送频率

4.4 数据库设计

详细数据库设计文档: 请参见 数据库设计文档.md

该文档包含完整的数据库架构设计、12张核心表详细结构、订单状态机、索引优化策略、数据备份恢复、数据安全与合规等详细内容。

数据库架构概览

核心数据表(12张)

订单状态机

10个订单状态:

• PENDING_PAYMENT(待支付) → PENDING_ACCEPT(待接单) → ACCEPTED(已接单) → ON_THE_WAY(出发中) → ARRIVED(已到达) → IN_SERVICE(服务中) → COMPLETED(已完成) → REVIEWED(已评价)
• 异常状态: CANCELLED(已取消)、REFUNDED(已退款)

超时处理规则:

• 待支付: 15分钟超时自动取消
• 待接单: 5分钟/次推送,3次无人接单自动取消并全额退款
• 服务中: 超过预计时长30分钟系统提醒

异常场景处理: 6种异常场景(护理师临时取消、用户取消、用户不在家、服务意外、护理日志异议、支付异常)详见数据库设计文档。

数据安全策略

详细数据库设计请查看: 数据库设计文档.md

五、5人团队分工

团队配置

详细分工

产品经理（1人）

• Week 1-2: 完成原型设计、UI设计跟进
• Week 3-12: 需求评审、进度跟踪、测试验收
• 全程: 项目协调、风险管理、合规审核

后端开发A（资深Java，1人）

• Week 1-2: 数据库设计、微服务架构设计、Nacos环境搭建
• Week 3-6: 核心模块开发（用户服务、订单服务、支付服务）
• Week 7-10: 地图服务、推送服务、消息队列集成
• Week 11-12: 性能优化、Bug修复、API文档完善

后端开发B（Java，1人）

• Week 1-2: Spring Boot基础框架、API网关配置
• Week 3-6: 护理师服务、健康档案服务、评价模块
• Week 7-10: 财务结算、提现模块、护理日志服务
• Week 11-12: 测试支持、文档整理、部署脚本

Flutter开发（1人）

• Week 1-2: Flutter项目搭建、基础组件开发
• Week 3-5: 用户端APP核心功能（首页、下单、订单管理）
• Week 6-8: 护理师端APP核心功能（接单、服务流程、收入）
• Week 9-10: 两端联调、优化、健康档案功能
• Week 11-12: Bug修复、性能优化、打包发布（iOS + Android双平台）

全栈开发（React，1人）

• Week 1-2: React + Ant Design管理后台框架搭建
• Week 3-6: 用户管理、护理师管理、订单管理模块
• Week 7-9: 财务管理、内容管理、系统管理
• Week 10: 数据统计、报表开发
• Week 11-12: 后端支持（帮助后端分担）、优化

六、开发排期

一期开发（12周）- MVP核心功能

第1-2周：项目启动与设计阶段

产品经理

• [ ] Day 1-3: 详细功能需求文档（PRD）
• [ ] Day 4-7: 完成所有页面原型设计（Axure/Figma）
• [ ] Day 8-10: UI设计外包对接（提供原型和参考）
• [ ] Day 11-14: 需求评审、技术方案评审

后端团队（Java）

• [ ] Day 1-3: Spring Boot + Spring Cloud技术选型、微服务架构设计
• [ ] Day 4-7: 数据库表结构设计、Nacos配置
• [ ] Day 8-14: 开发环境搭建、基础框架搭建、API网关配置

Flutter团队

• [ ] Day 1-3: Flutter技术选型、项目架构设计
• [ ] Day 4-7: Flutter项目脚手架搭建（用户端+护理师端）
• [ ] Day 8-14: 基础组件开发（按钮、输入框、卡片、列表等）

全栈开发（React）

• [ ] Day 1-7: React + Ant Design项目搭建、路由配置
• [ ] Day 8-14: 基础布局、权限框架、通用组件

交付物

• 详细PRD文档
• 完整原型设计
• UI设计稿（外包交付）
• 数据库设计文档
• API接口文档（初版）

第3-4周：账户与认证模块

后端团队（Java）

Flutter开发

• [ ] 用户端APP: 登录注册页面、实名认证页面、微信登录
• [ ] 护理师端APP: 登录注册页面、资质上传页面、证书管理
• [ ] 联调: 与后端联调认证接口

全栈开发（React）

• [ ] 管理后台: 登录页面、用户管理、护理师审核页面、权限管理

里程碑: ✅ 用户和护理师可以注册登录并完成认证

第5-6周：核心业务模块（订单流程）

后端团队（Java）

Flutter开发

• [ ] 用户端APP: 护理师列表、护理师详情、下单页面、订单列表、健康档案
• [ ] 护理师端APP: 订单列表、接单页面、订单详情
• [ ] 联调: 订单创建、支付、接单流程

全栈开发（React）

• [ ] 管理后台: 订单管理、订单详情、实时订单监控大屏

里程碑: ✅ 用户可以下单并支付，护理师可以接单

第7-8周：服务流程与实时功能

后端团队（Java）

Flutter开发

• [ ] 用户端APP: 实时位置追踪地图、订单状态实时更新、评价页面
• [ ] 护理师端APP: 导航到用户地址、服务打卡、上传位置、护理日志记录
• [ ] 推送: 集成极光推送SDK，接收订单通知

全栈开发（React）

• [ ] 管理后台: 实时订单监控大屏、地图展示、护理日志查看

里程碑: ✅ 订单全流程跑通，实时位置追踪可用，护理日志可记录

第9-10周：财务与基础增值功能

后端团队（Java）

Flutter开发

• [ ] 用户端APP: 余额充值、个人中心完善
• [ ] 护理师端APP: 收入统计、提现功能、业绩分析
• [ ] 优化: 性能优化、体验优化

全栈开发（React）

• [ ] 管理后台: 财务管理、提现审核、数据报表、佣金配置

里程碑: ✅ 财务闭环完成，用户和护理师可以充值提现

第11-12周：测试与上线准备

全员任务

• [ ] Week 11: 功能测试、Bug修复
• [ ] Week 11: 压力测试、性能优化
• [ ] Week 12: 用户体验优化、文案完善
• [ ] Week 12: 生产环境部署、灰度测试
• [ ] Week 12: iOS App Store提交、Android应用商店提交

产品经理

• [ ] 编写用户使用手册
• [ ] 编写护理师使用手册
• [ ] 准备首批种子用户和护理师
• [ ] 制定运营推广方案、合规审查

测试重点

一期交付物

• [ ] 用户端APP（iOS + Android）
• [ ] 护理师端APP（iOS + Android）
• [ ] 管理后台Web
• [ ] 后端API（所有核心微服务）
• [ ] 测试报告
• [ ] 部署文档
• [ ] 使用手册

里程碑: ✅ MVP版本上线，可接受真实订单

二期开发（8周）- 增值功能与优化

第13-14周：护理套餐系统

后端团队

Flutter开发

• [ ] 用户端APP: 护理套餐展示、购买、核销记录、套餐管理
• [ ] 护理师端APP: 套餐订单管理、核销操作

全栈开发（React）

• [ ] 管理后台: 套餐管理、套餐配置、销售数据分析

里程碑: ✅ 护理套餐系统上线，支持周卡/月卡/季卡/年卡

第15-16周：积分与会员系统

后端团队

Flutter开发

• [ ] 用户端APP: 积分中心、积分兑换、会员购买、会员权益展示
• [ ] 护理师端APP: 会员订单识别、会员服务标识

全栈开发（React）

• [ ] 管理后台: 积分规则配置、会员管理、会员数据分析

里程碑: ✅ 积分和会员系统上线，提升用户粘性

第17-18周：健康管理功能

后端团队

Flutter开发

• [ ] 用户端APP: 健康报告上传、AI分析结果展示、健康推荐、AI体测功能
• [ ] 护理师端APP: 查看用户健康评分、健康建议

全栈开发（React）

• [ ] 管理后台: 健康数据统计、AI分析配置

里程碑: ✅ 健康管理功能上线，提升平台价值

第19-20周：运营与数据分析

后端团队

Flutter开发

• [ ] 用户端APP: 优惠券中心、活动页面、邀请好友、分享功能
• [ ] 护理师端APP: 营销活动查看、推广奖励

全栈开发（React）

• [ ] 管理后台: 营销活动管理、优惠券配置、数据大盘、高级数据分析

里程碑: ✅ 运营工具上线，数据驱动决策

第21-22周：性能优化与体验提升

全员任务

• [ ] 性能优化: 接口响应时间优化、数据库查询优化、缓存策略优化
• [ ] 体验优化: 交互细节打磨、动画效果优化、加载速度优化
• [ ] 稳定性优化: 异常处理完善、容错机制、降级方案
• [ ] 安全加固: 数据加密升级、权限控制增强、防攻击策略

后端团队

• [ ] Redis缓存优化
• [ ] SQL慢查询优化
• [ ] 接口性能优化
• [ ] 并发处理优化

Flutter开发

• [ ] 启动速度优化
• [ ] 内存占用优化
• [ ] 网络请求优化
• [ ] 图片加载优化

全栈开发

• [ ] 前端资源优化
• [ ] 打包体积优化
• [ ] 首屏加载优化

二期交付物

• [ ] 完整功能的用户端APP
• [ ] 完整功能的护理师端APP
• [ ] 功能完善的管理后台
• [ ] 性能测试报告
• [ ] 优化文档
• [ ] 二期功能使用说明

里程碑: ✅ 产品功能完整，性能稳定，体验优秀

七、技术难点与解决方案

7.1 实时订单匹配与推送（v2.0升级）

难点

• 护理师在线状态管理
• 服务类别与技师资质匹配
• 性别限制验证（健康管理类）
• 营业时间过滤
• 订单推送策略（距离优先/评分优先/专业匹配）
• 超时自动取消机制
• 专业严选预约订单的特殊处理
• 团购订单的批量匹配

解决方案

// 护理师在线状态管理（Redis）
SET nurse:online:{id} {lat},{lng},{service_categories},{operating_hours} EX 300

// v2.0 升级版订单匹配算法
1. 根据服务类别筛选符合资质的护理师
   - 专业严选：仅匹配通过线下考核的技师
   - 健康管理：仅匹配女性技师
   - 其他类别：匹配持有专业证书的技师
   
2. 营业时间过滤
   - 检查订单时间是否在技师的营业时间范围内
   - 差旅放松：可至23:00
   - 肩颈快按：可至22:00
   - 其他：9:00-21:00
   
3. 性别验证（健康管理类）
   if (serviceCategory === '健康管理') {
     nurses = nurses.filter(n => n.gender === 'FEMALE');
   }
   
4. 计算用户位置5km内的在线护理师
   
5. 按评分、专业匹配度、服务次数排序取Top 10
   
6. 推送给护理师，30秒超时
   
7. 若无人接单，扩大范围到10km重试
   
8. 3次无人接单后订单取消或转人工客服

// 专业严选预约订单处理
1. 不支持立即服务，必须预约
2. 可预约14天内（后一周）
3. 提前24小时推送给匹配的高级认证技师
4. 服务前2小时再次提醒
5. 提示"请联系客服做专业了解"

// 团购订单处理（肩颈快按）
1. 检查服务类别是否为"肩颈快按"
2. 根据团购人数匹配多个技师
   - 1个技师最多服务10人
   - 团购50人需要5个技师
3. 批量推送给符合条件的技师
4. 统一调度，确保同时到达
5. 团购优惠自动计算：
   - 2-5人：9折
   - 6-10人：8.5折
   - 11人以上：8折

7.2 实时位置追踪

难点

• 护理师位置频繁上报，性能压力
• 用户端实时显示护理师位置
• 位置数据隐私保护

解决方案

// 护理师端：每10秒上报一次位置（服务中）
WebSocket.send({
  type: 'location_update',
  nurse_id: 'N123456',
  order_id: 'O202501160001',
  lat: 39.9042,
  lng: 116.4074,
  timestamp: 1705392000
})

// 服务端：Redis存储最新位置，10分钟过期
SET nurse:location:{order_id} {nurse_id},{lat},{lng},{timestamp} EX 600

// 用户端：每5秒通过WebSocket接收位置更新
WebSocket.on('location_update', (data) => {
  updateMapMarker(data.lat, data.lng)
})

// 隐私保护：仅在订单进行中显示位置，服务结束后清除

7.3 支付与分账

难点

• 微信支付、支付宝支付集成
• 平台抽成自动分账
• 退款处理
• 护理套餐核销与余额支付

解决方案

// 支付流程
1. 用户下单 → 创建订单（待支付）
2. 调用支付接口 → 生成支付单号
3. 支付成功回调 → 更新订单状态（已支付）
4. 异步记录支付流水

// 分账逻辑（订单完成后）
@Transactional
public void settleOrder(String orderId) {
    Order order = orderRepository.findById(orderId);

    // 计算分账
    BigDecimal totalAmount = order.getServicePrice();
    BigDecimal platformFee = totalAmount.multiply(COMMISSION_RATE); // 平台佣金15%-25%
    BigDecimal nurseFee = totalAmount.subtract(platformFee);

    // 护理师账户入账
    nurseAccountService.addBalance(order.getNurseId(), nurseFee);

    // 记录分账流水
    settlementRecordRepository.save(record);
}

// 退款处理
1. 服务前取消：全额退款
2. 服务中取消：按实际服务时长扣费
3. 退款原路返回
4. 扣除已分账给护理师的部分

7.4 高并发处理

难点

• 订单高峰期的并发
• 数据库查询性能
• 护理师抢单竞争

解决方案

// Redis缓存策略
1. 护理师列表：缓存5分钟
2. 订单状态：实时更新，缓存1分钟
3. 健康档案：缓存10分钟

// 抢单防并发
@RedisLock(key = "order:#{orderId}")
public boolean acceptOrder(String orderId, String nurseId) {
    // Redis分布式锁，防止多个护理师同时接单
    Order order = orderRepository.findById(orderId);
    if (order.getStatus() != OrderStatus.PENDING) {
        return false; // 订单已被接单
    }

    order.setNurseId(nurseId);
    order.setStatus(OrderStatus.ACCEPTED);
    orderRepository.save(order);
    return true;
}

// 数据库优化
1. 读写分离：主库写，从库读
2. 订单ID使用雪花算法生成
3. 热点数据索引优化
4. 消息队列异步处理（短信、推送、护理日志统计）

7.5 健康档案数据安全

难点

• 健康数据属于敏感信息
• 需要符合《个人信息保护法》
• 护理师查看权限控制
• 心率监测数据的存储与查询

解决方案

// 数据加密存储
1. 敏感字段（身份证号、病史）AES加密存储
2. 传输层使用HTTPS + TLS 1.3
3. 心率监测数据加密存储，仅授权查看

// 权限控制
@PreAuthorize("hasPermission(#patientId, 'HEALTH_RECORD', 'READ')")
public HealthRecord getHealthRecord(String patientId, String nurseId) {
    // 只有当前订单的护理师可以查看
    if (!orderService.isNurseInActiveOrder(patientId, nurseId)) {
        throw new AccessDeniedException("无权查看该患者健康档案");
    }
    return healthRecordRepository.findByPatientId(patientId);
}

// 心率监测数据管理
public void saveHeartRateRecord(String orderId, int heartRate) {
    HeartRateRecord record = new HeartRateRecord();
    record.setOrderId(orderId);
    record.setHeartRate(heartRate);
    record.setMonitorTime(LocalDateTime.now());
    
    // 异常判断
    if (heartRate < 50 || heartRate > 120) {
        record.setStatus("ABNORMAL");
        // 触发告警通知
        alertService.sendHeartRateAlert(orderId, heartRate);
    } else {
        record.setStatus("NORMAL");
    }
    
    // 保存到健康档案
    heartRateRepository.save(record);
    healthRecordService.addHeartRateToArchive(orderId, record);
}

// 操作日志
1. 记录所有健康档案访问行为
2. 数据导出需审批
3. 定期审计日志
4. 心率监测数据访问日志

7.6 服务类别与营业时间管理（v2.0新增）

难点

• 技师可提供多种服务类别
• 不同服务类别有不同营业时间
• 订单创建时需验证营业时间
• 技师切换服务类别的资质验证

解决方案

// 技师服务类别配置
@Entity
public class NurseServiceCategory {
    private Long nurseId;
    private String category; // 专业严选/健康管理/功能型/差旅放松/肩颈快按
    private String certification; // 资质证明
    private LocalTime startTime; // 营业开始时间
    private LocalTime endTime; // 营业结束时间
    private Boolean isActive; // 是否启用
}

// 资质验证
public boolean validateCategoryAccess(Long nurseId, String category) {
    Nurse nurse = nurseRepository.findById(nurseId);
    
    switch (category) {
        case "专业严选":
            // 检查是否通过线下考核
            return nurse.hasOfflineExamPassed();
            
        case "健康管理":
            // 检查性别是否为女性
            if (!"FEMALE".equals(nurse.getGender())) {
                throw new BusinessException("健康管理服务仅限女性技师");
            }
            return nurse.hasProfessionalCertificate();
            
        default:
            // 其他类别只需专业证书
            return nurse.hasProfessionalCertificate();
    }
}

// 营业时间验证
public boolean validateOperatingHours(String category, LocalTime orderTime) {
    Map<String, LocalTime> endTimes = Map.of(
        "专业严选", LocalTime.of(21, 0),
        "健康管理", LocalTime.of(21, 0),
        "功能型服务", LocalTime.of(21, 0),
        "差旅放松", LocalTime.of(23, 0),
        "肩颈快按", LocalTime.of(22, 0)
    );
    
    LocalTime endTime = endTimes.get(category);
    LocalTime startTime = LocalTime.of(9, 0);
    
    return !orderTime.isBefore(startTime) && !orderTime.isAfter(endTime);
}

// Redis缓存技师服务类别
SET nurse:categories:{nurseId} 
    {"专业严选":{"start":"09:00","end":"21:00","active":true},
     "健康管理":{"start":"09:00","end":"21:00","active":true}}
EX 3600

7.7 团购订单处理（v2.0新增）

难点

• 团购订单的批量创建与管理
• 多技师协同服务调度
• 团购优惠自动计算
• 企业发票开具
• 团购订单的退款处理

解决方案

// 团购订单创建
@Transactional
public GroupOrder createGroupOrder(GroupOrderRequest request) {
    // 1. 验证服务类别（仅限肩颈快按）
    if (!"肩颈快按".equals(request.getServiceCategory())) {
        throw new BusinessException("仅肩颈快按服务支持团购");
    }
    
    // 2. 验证人数（2-50人）
    int groupSize = request.getGroupSize();
    if (groupSize < 2 || groupSize > 50) {
        throw new BusinessException("团购人数限制2-50人");
    }
    
    // 3. 计算优惠价格
    BigDecimal discount = calculateGroupDiscount(groupSize);
    BigDecimal totalAmount = request.getUnitPrice()
        .multiply(new BigDecimal(groupSize))
        .multiply(discount);
    
    // 4. 创建主订单
    GroupOrder groupOrder = new GroupOrder();
    groupOrder.setGroupSize(groupSize);
    groupOrder.setTotalAmount(totalAmount);
    groupOrder.setDiscount(discount);
    groupOrderRepository.save(groupOrder);
    
    // 5. 计算需要的技师数量（1个技师服务10人）
    int nurseCount = (groupSize + 9) / 10;
    
    // 6. 批量匹配技师
    List<Nurse> nurses = matchNursesForGroup(
        request.getLocation(), 
        nurseCount,
        request.getServiceTime()
    );
    
    // 7. 创建子订单
    for (Nurse nurse : nurses) {
        Order subOrder = new Order();
        subOrder.setGroupOrderId(groupOrder.getId());
        subOrder.setNurseId(nurse.getId());
        orderRepository.save(subOrder);
    }
    
    return groupOrder;
}

// 团购优惠计算
private BigDecimal calculateGroupDiscount(int groupSize) {
    if (groupSize >= 11) {
        return new BigDecimal("0.8"); // 8折
    } else if (groupSize >= 6) {
        return new BigDecimal("0.85"); // 8.5折
    } else {
        return new BigDecimal("0.9"); // 9折
    }
}

// 团购订单退款
@Transactional
public void refundGroupOrder(Long groupOrderId) {
    GroupOrder groupOrder = groupOrderRepository.findById(groupOrderId);
    
    // 计算已服务人数
    int servedCount = orderRepository.countByGroupOrderIdAndStatus(
        groupOrderId, 
        OrderStatus.COMPLETED
    );
    
    // 计算退款金额
    int totalSize = groupOrder.getGroupSize();
    BigDecimal refundAmount = groupOrder.getTotalAmount()
        .multiply(new BigDecimal(totalSize - servedCount))
        .divide(new BigDecimal(totalSize));
    
    // 执行退款
    paymentService.refund(groupOrder.getPaymentId(), refundAmount);
}

八、成本预算

8.1 人员成本（3个月）

8.2 其他成本

8.3 基础设施成本（3个月）

8.4 总成本汇总

备注:

• 以上为MVP开发阶段（3个月）的成本
• 不含运营推广费用
• 不含上线后运维成本

九、风险与应对

9.1 合规风险（⚠️ 中危）

风险描述

• 医疗护理服务涉及医疗资质监管
• 需要符合卫生健康部门规定
• 护理事故责任风险

应对措施

1. 护理师准入严格审核

   • 必须提供护士证/康复师证/育婴师证
   • 健康证、无犯罪记录证明必须
   • 个体户营业执照真实有效
   • 实名认证+人脸识别

2. 服务过程管理

   • 护理日志详细记录，可追溯
   • 体征数据记录，建立健康档案
   • 异常情况及时上报
   • 建立用户投诉快速响应机制

3. 明确服务边界

   • 明确非医疗诊断行为
   • 仅提供生活护理、康复护理服务
   • 强调"专业护理"、"健康管理"
   • 护理师照片展示证书和专业形象

4. 法律与保险

   • 聘请律师审查业务合规性
   • 为护理师购买职业责任险
   • 准备应对监管的预案
   • 定期与卫健部门沟通

9.2 劳动关系风险（⚠️ 中危）

风险描述

• 护理师以个体户身份合作，可能被认定为劳动关系
• 需补缴社保，财务压力巨大

应对措施

1. 法律咨询

   • 聘请劳动法律师评估现有模式
   • 研究"平台用工"新模式

2. 合作协议优化

   • 明确合作关系，非雇佣关系
   • 护理师自由接单，无考勤要求
   • 平台仅提供信息撮合服务

3. 社保预算

   • 预留社保补缴预算
   • 考虑为头部护理师提供社保选项

9.3 服务质量风险（⚠️ 中危）

风险描述

• 护理师水平参差不齐
• 护理效果差异大
• 用户投诉多，品牌受损

应对措施

1. 护理师分级认证

   • 初级/中级/高级/金牌护理师
   • 定期考核，优胜劣汰
   • 专业技能培训

2. 服务质量监控

   • 护理日志详细记录
   • 用户评价系统
   • 低分护理师再培训或淘汰
   • 定期质量抽查

3. 退款政策优化

   • 服务时长不足按比例退款
   • 首单不满意全额退款
   • 服务质量问题快速响应

9.4 技术风险（⚠️ 中危 - v2.0提升）

风险描述

• 开发进度延期（v2.0新增功能较多）
• 技术难点攻克不了
• 服务类别匹配算法复杂度增加
• 团购订单调度逻辑复杂
• 心率监测数据准确性依赖

应对措施

1. 敏捷开发

   • 2周一迭代
   • 及时发现问题并调整
   • v2.0功能分阶段上线

2. 技术选型保守

   • 选择成熟技术栈
   • 避免过度创新
   • 服务类别匹配使用成熟规则引擎

3. 外部支持

   • 关键模块可外包
   • 技术难点寻求外部专家
   • 团购业务前期可人工调度，后期优化自动化

4. MVP简化策略（v2.0）

   • 用户画像先用简单规则，后期引入AI
   • 心率监测异常预警人工介入
   • 服务类别先上线3大核心类别
   • 团购业务先支持小规模（20人以内）

9.5 服务类别运营风险（⚠️ 中危 - v2.0新增）

风险描述

• 专业严选技师线下考核标准难以统一
• 健康管理类服务仅限女性技师，供给可能不足
• 团购业务获客成本高
• 差异化营业时间导致技师管理复杂

应对措施

1. 专业严选准入管理

   • 制定详细的线下考核标准
   • 邀请行业专家参与考核
   • 提供专业培训课程
   • 设置试用期机制

2. 女性技师招募

   • 针对女性技师设计招募计划
   • 提供更优惠的佣金比例（降低至12%）
   • 强调女性专区的市场定位优势
   • 与女性职业培训机构合作

3. 团购业务推广

   • 先从写字楼、园区试点
   • 与企业HR部门合作
   • 推出企业员工福利套餐
   • 棋牌室、会所批量合作

4. 营业时间管理

   • 技师可自主设置营业时间
   • 差旅放松/肩颈快按提供夜间补贴
   • 实时监控各时段技师在线率
   • 动态调整营业时间策略

十、关键决策建议

建议1: 老年康复+孕产护理的市场前景如何？

我的建议: ✅ 强烈推荐这个方向

原因:

1. 中国老龄化严重，养老护理需求巨大
2. 三胎政策下，孕产护理需求增长
3. 比按摩服务更合规，监管风险低
4. 更有社会价值，容易获得政策支持

市场优势:

• 刚需市场 - 老年康复、孕产护理是真实刚需
• 高客单价 - 专业护理服务定价更高
• 长期复购 - 慢病管理、月子护理周期长
• 政策友好 - 符合国家养老、生育政策导向

建议2: 5人团队能否完成？

我的建议: ✅ 可以完成，但需注意风险

团队配置:

1. 产品经理 1人
2. 后端Java开发 2人
3. Flutter开发 1人
4. APP开发 1人
5. React全栈开发 1人

风险点:

1. 无专职测试，质量风险高
2. 无专职UI设计师，需外包
3. Flutter开发负担重（2个APP）
4. 项目延期风险高（预留20%缓冲时间）

优化方案:

• UI外包给专业团队
• 测试由产品经理+开发兼任
• Flutter两端共用组件减少工作量
• APP复用Flutter业务逻辑
• MVP功能适当精简

建议3: MVP功能如何取舍？（v2.0更新）

核心保留（P0 - 必须开发）:

• 用户注册登录、护理师注册审核
• 5大服务类别展示与选择
• 服务类别资质验证（专业严选线下考核、健康管理性别限制）
• 护理师列表筛选、下单支付
• 差异化预约时间（专业严选可预约至后一周）
• 营业时间智能提示（9:00-21:00/22:00/23:00）
• 订单流程（接单、服务、护理日志、评价）
• 操作前心率监测（技师端必填）
• 心率监测记录查看（用户端）
• 健康档案基本功能
• 实时位置追踪
• 管理后台基本功能

重要功能（P1 - 优先开发）:

• 团购下单功能（肩颈快按）
• 团购订单管理
• 用户群体智能识别
• 服务类别详细说明与客服咨询
• 护理套餐系统
• 数据统计报表
• 余额充值与余额支付

可延后（P2 - MVP后迭代）:

• 健康报告生成
• 健康资讯内容
• 培训学习中心
• 社交分享
• AI智能推荐（MVP可用基础算法）
• 高级数据分析

MVP简化策略:

1. 用户画像：MVP阶段可基于订单历史简单判断，不必引入复杂AI算法
2. 团购业务：MVP阶段先支持线下人工调度，后期再优化自动调度
3. 心率监测：MVP阶段仅记录数值，异常预警可人工介入
4. 服务类别：MVP阶段先上线3大核心类别（专业严选、健康管理、肩颈快按），其他类别后续迭代

十一、上线后运营规划（简要）

第1个月：种子用户验证

目标: 验证产品可用性，收集反馈

• 招募30名种子护理师（医院、康复中心）
• 招募100个种子家庭（朋友圈、社群、社区）
• 提供首单优惠（5折）
• 密切跟踪每个订单，快速迭代

关键指标:

• 订单完成率 > 90%
• 用户满意度 > 4.5分
• 护理师投诉率 < 3%
• 护理日志完整率 > 95%

第2-3个月：单城市扩张

目标: 规模化验证，建立口碑

• 护理师扩展到100人
• 用户家庭扩展到2000个
• 日均订单30单
• 月GMV 50万元

运营动作:

• 医院、康复中心合作招募护理师
• 社区推广（养老院、母婴店）
• 线上广告投放（小红书、抖音）
• 口碑传播激励

第4-6个月：多城市复制

目标: 验证模式可复制，准备融资

• 拓展到3个城市
• 护理师规模500人
• 用户家庭5万个
• 月GMV 300万元

十二、交付清单

开发阶段交付物

Week 2 交付:

• [ ] 详细PRD文档
• [ ] 完整原型设计（Axure/Figma）
• [ ] UI设计稿（外包）
• [ ] 数据库设计文档
• [ ] API接口文档（初版）

Week 6 交付:

• [ ] 用户端APP（核心功能）
• [ ] 用户端APP（核心功能）
• [ ] 护理师端APP（核心功能）
• [ ] 后端API（用户、订单、支付、健康档案模块）
• [ ] 管理后台（用户管理、护理师管理、订单管理）

Week 10 交付:

• [ ] 用户端APP（完整功能）
• [ ] 用户端APP（完整功能）
• [ ] 护理师端APP（完整功能）
• [ ] 后端API（所有微服务模块）
• [ ] 管理后台（完整功能）

Week 12 交付:

• [ ] 测试报告
• [ ] 部署文档（Docker + Kubernetes）
• [ ] 用户使用手册
• [ ] 护理师使用手册
• [ ] API接口文档（Knife4j）
• [ ] 运维文档

十三、微服务架构详细实现指南

本章节介绍微服务架构的详细实现

13.1 微服务模块详解

康护到家平台共包含以下模块:

核心基础模块

业务微服务模块(11个)

13.2 Nacos 配置中心实践

部署与配置

Nacos Server 部署:

• 下载Nacos 2.2.3版本,解压后执行 sh startup.sh -m standalone 单机启动
• 访问控制台 http://localhost:8848/nacos (默认账号密码: nacos/nacos)
• 生产环境建议集群部署(3个节点以上),使用MySQL存储配置

命名空间设计:

• dev: 开发环境
• test: 测试环境
• prod: 生产环境

微服务配置结构:

• 本地配置(application.yml): 服务名称、Nacos地址、环境激活
• Nacos配置中心: 数据库连接、Redis配置、第三方服务密钥(使用环境变量)
• 配置自动刷新: refresh-enabled: true

关键配置项:

• 数据库: MySQL驱动、连接池HikariCP、MyBatis Plus映射
• Redis: 连接配置、密码、超时设置
• RabbitMQ: 主机、端口、虚拟主机
• Sa-Token: Token名称、超时时间30天、JWT密钥(环境变量)
• 日志: 按包名设置日志级别(开发环境debug)

13.3 Spring Cloud Gateway 路由与过滤

路由配置策略

自动服务发现:

• 启用 discovery.locator.enabled: true,自动从Nacos发现服务
• 服务ID小写转换: lower-case-service-id: true

核心路由规则:

• 用户服务: /api/user/** → health-user-service (去掉/api前缀)
• 订单服务: /api/order/** → health-order-service
• 护理师服务: /api/nurse/** → health-nurse-service
• 支付服务: /api/payment/** → health-payment-service

限流配置:

• 使用Redis实现分布式限流
• replenishRate: 10 (每秒补充10个令牌)
• burstCapacity: 20 (桶容量20个令牌)

全局过滤器

跨域CORS配置:

• 允许所有来源 (生产环境需指定具体域名)
• 允许方法: GET、POST、PUT、DELETE、OPTIONS
• 允许携带凭证: allowCredentials: true

认证鉴权过滤器:

• 从请求头提取Authorization token
• 白名单路径: /login、/register、/captcha (直接放行)
• 非白名单路径: 验证Token有效性,失败返回401
• 过滤器优先级: -100 (最高优先级)

日志过滤器:

• 记录请求路径、方法、IP、耗时
• 异常请求详细日志记录
• 慢请求告警(>2秒)

13.4 Sa-Token 认证授权实现

登录认证流程

手机号验证码登录:

1. 验证验证码正确性(Redis存储,5分钟有效期)
2. 根据手机号查询或创建用户
3. 调用 StpUtil.login(userId) 完成登录
4. 获取Token: StpUtil.getTokenValue()
5. 返回用户信息+Token给客户端

微信授权登录:

1. 使用微信code换取openid
2. 根据openid查询或创建用户(绑定手机号)
3. Sa-Token登录生成Token
4. 返回用户信息

Token管理:

• Token有效期: 30天
• 刷新机制: StpUtil.renewTimeout(2592000)
• 登出: StpUtil.logout() 清除Token

权限控制方案

基于角色的权限控制:

• @SaCheckRole("admin"): 仅管理员可访问
• @SaCheckRole({"admin", "operator"}, mode = SaMode.OR): 管理员或运营均可访问
• 角色存储在Redis,支持动态更新

自定义权限验证:

• 检查当前登录用户ID: StpUtil.getLoginIdAsLong()
• 业务逻辑验证: 只能查看本人或下属数据
• 抛出 BusinessException 进行权限拦截

权限缓存策略:

• 角色权限缓存10分钟
• 权限变更实时刷新缓存
• 登出清除所有权限缓存

13.5 OpenFeign 服务间通信

Feign Client 设计

接口定义规范:

• @FeignClient(name = "服务名", fallbackFactory = 降级工厂类)
• 服务名必须与Nacos注册的服务名一致
• 接口方法与被调用服务的Controller方法签名一致

核心接口示例:

• 用户服务Client: 查询用户信息、批量查询、扣减余额
• 护理师服务Client: 查询护理师、更新在线状态、评分计算
• 支付服务Client: 创建支付单、查询支付状态、退款

降级策略:

• 实现 FallbackFactory 接口
• 服务不可用时返回友好提示: "XXX服务暂时不可用"
• 记录失败日志,便于排查问题
• 避免降级中执行复杂逻辑

服务调用场景

订单创建场景:

1. 调用用户服务查询用户信息(验证用户状态)
2. 调用护理师服务查询护理师信息(验证可接单状态)
3. 本地创建订单记录
4. 调用消息服务发送订单通知

订单支付场景:

1. 调用支付服务创建支付流水
2. 调用用户服务扣减余额(余额支付)
3. 更新订单状态为已支付
4. 调用消息服务通知护理师

调用优化:

• 批量接口减少网络开销(批量查询用户、护理师)
• 合理设置超时时间(默认1秒,复杂查询3秒)
• 启用请求压缩减少带宽
• 使用连接池复用连接

13.6 RabbitMQ 异步消息实践

延时队列实现订单超时取消

队列设计:

• 延时交换机: order.delay.exchange
• 延时队列: order.delay.queue (设置死信交换机)
• 取消交换机: order.cancel.exchange
• 取消队列: order.cancel.queue

工作流程:

1. 创建订单后发送延时消息到延时队列,过期时间15分钟
2. 消息过期后自动转发到死信交换机
3. 死信交换机路由到取消队列
4. 消费者监听取消队列,检查订单状态
5. 如果仍是"待支付",自动取消订单

配置要点:

• 延时队列设置: x-dead-letter-exchange 指定死信交换机
• 消息过期时间: setExpiration("900000") (15分钟)
• 消费者幂等性: 检查订单状态防止重复取消

消息可靠性保证

生产者确认:

• 启用 publisher-confirms: true
• 发送失败重试3次
• 记录失败消息到数据库

消费者ACK:

• 手动ACK模式
• 消费成功后确认
• 消费失败重新入队(最多3次)

死信队列:

• 消费失败超过3次进入死信队列
• 人工介入处理异常消息

13.7 Seata 分布式事务保障

AT模式实现订单支付

全局事务发起:

• 订单服务使用 @GlobalTransactional 注解
• 事务名称: create-order-tx
• 回滚策略: rollbackFor = Exception.class

事务参与者:

1. 订单服务: 更新订单状态为"已支付"
2. 支付服务: 创建支付流水记录
3. 用户服务: 扣减用户余额(余额支付场景)

回滚机制:

• 任一服务失败,Seata自动回滚所有已执行的SQL
• 使用undo_log表记录回滚日志
• 支持跨数据库事务

性能优化:

• 仅核心业务使用分布式事务
• 非关键流程改用本地消息表+定时补偿
• 控制事务粒度,避免长事务

TCC模式场景

适用场景: 余额扣减、库存扣减等需要精确控制的场景

三个阶段:

• Try: 冻结资源(余额冻结、库存预扣)
• Confirm: 确认扣减(实际扣除余额、库存)
• Cancel: 取消回滚(释放冻结资源)

实现要点:

• 每个阶段幂等性处理
• 使用唯一业务流水号防重
• 资源冻结表独立设计

13.8 Docker + Kubernetes 部署方案

Docker镜像构建

Dockerfile最佳实践:

• 基础镜像: openjdk:17-slim (精简版)
• 多阶段构建减小镜像体积
• 使用 .dockerignore 排除无关文件
• 健康检查: HEALTHCHECK CMD curl -f http://localhost:8080/actuator/health

镜像分层优化:

• 依赖层(pom.xml依赖)单独缓存
• 业务代码层独立,提高构建速度
• 镜像大小控制在200MB以内

Kubernetes部署

资源配置:

• Deployment: 每个微服务独立部署,副本数2-3
• Service: ClusterIP类型,内部服务间通信
• Ingress: 暴露API网关,统一入口
• ConfigMap: 存储配置文件
• Secret: 存储敏感信息(数据库密码、密钥)

资源限制:

• Request: CPU 500m、内存512Mi
• Limit: CPU 2000m、内存2Gi
• 根据实际负载动态调整

滚动更新:

• strategy: RollingUpdate
• maxSurge: 1 (最多额外启动1个Pod)
• maxUnavailable: 0 (保证服务不中断)

健康检查:

• Liveness Probe: 检查服务是否存活
• Readiness Probe: 检查服务是否就绪接收流量
• 探测路径: /actuator/health

13.9 监控与日志方案

Spring Boot Admin 服务监控

监控指标:

• JVM内存使用率、GC次数
• 线程池状态(活跃线程数、队列长度)
• HTTP请求量、响应时间
• 数据库连接池状态
• 缓存命中率

告警配置:

• 内存使用率>80%告警
• 响应时间>2秒告警
• 错误率>5%告警
• 发送通知: 邮件、钉钉、企业微信

ELK日志收集

日志采集:

• Logstash收集各微服务日志
• 日志格式统一JSON格式
• 包含: 时间戳、服务名、日志级别、TraceId、消息

日志存储:

• Elasticsearch存储,按天创建索引
• 保留周期: 最近30天
• 冷数据归档到OSS

日志查询:

• Kibana可视化查询
• 按TraceId追踪完整请求链路
• 错误日志聚合分析

SkyWalking 链路追踪

追踪范围:

• HTTP请求链路
• RPC调用(OpenFeign)
• 数据库查询
• Redis操作
• 消息队列

性能分析:

• 慢请求分析(>2秒)
• SQL慢查询定位
• 服务依赖拓扑图
• 接口性能趋势

十四、版本更新说明

v3.0 版本更新 (2025-10-27)

本次更新调整产品开发策略，去除APP开发，专注Flutter APP双平台开发。

核心调整内容

1. 去除APP开发

原因分析：

• 微信APP审核政策收紧，医疗护理类服务上架困难
• APP功能受限较多（后台定位、推送、支付方式等）
• 开发维护成本高，需要独立团队和技术栈

调整策略：

• 专注Flutter APP开发，提供完整功能体验
• iOS + Android双平台覆盖，无功能限制
• 统一技术栈，降低开发和维护成本

2. 团队配置优化

3. 开发周期调整

调整为两期开发模式：

优势：

• 一期聚焦MVP，快速上线验证市场
• 二期迭代优化，基于用户反馈调整
• 分阶段投入，降低初期风险

4. 产品架构调整

5. Flutter开发重点

一期开发（12周）：

• Week 1-2: Flutter项目搭建、基础组件库
• Week 3-5: 用户端APP核心功能
• Week 6-8: 护理师端APP核心功能
• Week 9-10: 两端联调、财务功能
• Week 11-12: 测试优化、双平台发布

二期开发（8周）：

• Week 13-14: 护理套餐系统
• Week 15-16: 积分与会员系统
• Week 17-18: 健康管理功能
• Week 19-20: 运营与数据分析
• Week 21-22: 性能优化与体验提升

6. 功能覆盖

去除APP后，所有功能通过APP实现：

• 用户端APP：173个功能点（完整功能）
• 护理师端APP：70个功能点（完整功能）
• 管理后台：32个功能点

无功能损失，体验更优：

• 无平台限制，功能更完整
• 性能更好，体验更流畅
• 开发效率更高，维护成本更低

技术优势

统一技术栈：

• 前端统一使用Flutter 3.x
• 代码复用率高，开发效率提升30%
• 一套代码，双平台发布

完整功能支持：

• 后台持续定位（护理师位置追踪）
• 极光推送（订单通知随时可达）
• 多种支付方式（微信、支付宝、余额）
• 生物识别（指纹、Face ID）
• 本地存储无限制
• 批量文件上传

性能优势：

• 原生性能，流畅度更好
• 内存占用更低
• 启动速度更快
• 离线功能支持

成本影响

人员成本：

• 减少1人（APP开发）
• 3个月节省人力成本

开发成本：

• 减少APP开发和维护成本
• 统一技术栈降低培训成本
• 代码复用提高开发效率

运维成本：

• 减少APP服务器和CDN成本
• 维护端数量减少，运维更简单

风险与应对

潜在风险：

1. iOS审核周期较长（7-14天）
2. Android应用商店需要软著
3. 用户需要下载安装（无APP即开即用优势）

应对措施：

1. 提前准备iOS审核资料，首次提审预留2周
2. 提前申请软件著作权（3-5个工作日加急）
3. 通过二维码、短链等方式引导用户下载
4. APP体验更好，留存率更高

市场策略

推广重点：

• 强调APP完整功能体验
• 突出专业医疗护理服务
• 主打O2O上门服务便利性

获客渠道：

• 社区地推（养老院、母婴店）
• 线上投放（小红书、抖音）
• 医院合作（护士兼职）
• 口碑传播（老带新奖励）

文档同步更新

已更新文档：

• ✅ APP产品开发方案.md（当前文档） → v3.0
• 待更新：[用户端APP功能清单.md] - 去除APP相关描述
• 待更新：API接口文档 - 去除APP专用接口

v2.0 版本更新 (2025-10-22)

本次更新结合《麦瓣健康项目规划》文档，对产品开发方案进行重大优化和增强。

核心更新内容

1. 服务类别体系重构

原有服务分类较为单一，v2.0引入5大服务类别，实现精细化运营：

（其他v2.0更新内容保持不变...）

文档版本: v3.0 最后更新: 2025-10-27 更新内容:

• 去除APP开发，专注Flutter APP双平台
• 优化团队配置为5人（去除APP开发岗位）
• 调整开发排期为一期（12周）和二期（8周）
• 统一技术栈，提升开发效率
• 完整功能支持，无平台限制 维护者: 麦瓣健康产品团队