AIwelink 技术方案

本文说明第一阶段的 Web、业务 API、数据存储、文件存储、部署和基础监控方案。

AI 助手的模型供应商、对话编排方式和后台任务方案列为后续技术决定。本文先约定接口和职责，具体实现等业务流程确定后再选。

1. 总体方案

第一阶段使用模块清楚、可以逐步扩展的架构：

Web 页面和业务 API 分开部署；
Web 和 API 通过一个域名对外提供服务，API 统一使用 /api/v1 路径；
PostgreSQL 保存需要事务保证的数据，并使用 JSONB、全文搜索和 pgvector；
Redis 处理缓存、限流和异步任务；
阿里云 OSS 保存简历、作品、报告和项目附件；
Web、API 和任务程序都运行在 Docker 容器中；
第一阶段使用自有 ECS 和 Docker Compose，规模增长后再迁移到 Kubernetes；
用户身份、个人资料、项目行为和授权记录按敏感程度分开保存；
初期用 Uptime Kuma 检查网站和 API 是否可访问。

2. 已确定的技术选型

领域	当前选择
Web 前端	Next.js + React + TypeScript
业务 API	NestJS + Fastify Adapter
API 形式	REST API，路径前缀 `/api/v1`
数据访问	Drizzle ORM；复杂查询使用参数化原生 SQL
主数据库	PostgreSQL
向量检索	PostgreSQL 的 `pgvector` 扩展
缓存和任务队列	Redis
文件存储	阿里云 OSS
运行环境	Docker
第一阶段部署	自有 ECS + Docker Compose
后续部署	Kubernetes
身份系统	API 内部的 `Identity` 模块
初期监控	Uptime Kuma

3. 服务怎样连接

浏览器
  |
  v
Nginx 或其他入口代理
  |-- /              -> Next.js Web 容器
  |-- /api/v1/*      -> NestJS + Fastify API 容器
                              |
                      Drizzle / SQL Repository
                              |
                    PostgreSQL + pgvector
                              |
                            Redis
                              |
                          阿里云 OSS

Next.js 负责页面和交互。 NestJS 负责业务规则和 REST API。浏览器通过同一个域名下的 /api/v1/... 路径调用 API。

4. API 内部模块

API 按业务模块组织，第一阶段至少包含：

Identity：微信登录、邮箱绑定、会话和登录记录；
Users：基础资料、学校、专业和年级；
Profiles：个人画像、公开画像和画像版本；
Consents：画像共享授权、撤销和授权记录；
Projects：竞赛、项目、队伍、成员和申请；
Invitations：邀请链接、接受记录和邀请关系；
Points：积分流水、任务和兑换权益；
Commerce：课程、API 权益、订单和退款记录；
Recommendations：推荐内容、推荐理由和用户反馈；
Operations：内容审核、举报、活动和运营配置。

AI 助手先通过独立接口接入。模型、任务队列和报告生成流程确定后，再决定服务是否单独部署。

5. 数据怎样分层

数据按业务含义和敏感程度安排存储位置：

身份信息和联系方式；
原始测评回答；
AI 生成的个人画像；
真实项目行为和合作证据；
用户主动公开的画像；
授权记录和审计记录。

大表先使用合理的表结构、索引和归档策略。数据量和查询方式出现明确需求后，再评估 PostgreSQL 分区或其他存储方式。

6. 文件和媒体

简历、作品、报告和项目附件保存到阿里云 OSS，流程如下：

API 创建临时上传凭证；
浏览器直接上传 OSS；
API 接收上传完成通知；
PostgreSQL 保存文件信息和权限关系；
后台任务按需解析、审核或建立搜索索引。

应用服务器只处理上传授权和文件信息，不承担大文件的长期保存。

7. 部署和后续扩展

第一阶段用 Docker Compose 管理这些服务：

Web 容器；
API 容器；
Worker 容器，用于异步任务；
PostgreSQL；
Redis。

生产环境逐步把应用容器和 PostgreSQL、Redis 分开部署，或改用托管服务。同时设置备份、恢复和升级流程。

迁移 Kubernetes 时，应用服务保持无状态。配置通过环境变量或 Secret 注入，文件继续放在 OSS，数据库迁移单独执行。

8. 监控和测试

Uptime Kuma 负责基础可用性检查：

首页是否能打开；
/api/v1/health/live 是否返回进程存活；
/api/v1/health/ready 是否确认 PostgreSQL、Redis 和必要配置可用；
HTTPS 证书和端口是否正常。

测试单独建设，至少覆盖 TypeScript 类型检查、Lint、API 测试和关键流程端到端测试。发布前还要检查数据库迁移。核心流程包括登录、授权、邀请、项目申请和积分流水。

9. 第一阶段的工作重点

先完成用户登录、个人资料、自我认知、机会浏览、邀请共享、项目申请和积分记录。再根据真实使用数据决定以下能力的时间：

微服务拆分；
Kubernetes 生产部署；
独立向量数据库；
Elasticsearch 或 OpenSearch；
ClickHouse；
MongoDB；
复杂机器学习推荐服务；
专门的 AI 助手编排框架。

这些能力都保留后续空间。当前开发围绕用户找到机会、组成队伍并完成项目展开。

5.4 KiB Raw Blame History Unescape Escape