第5节：部署架构、性能预判与数据设计

AI编程企业级实战上一节第4节应用架构与代码组织本节第5节部署架构、性能预判与数据设计下一节待更新这一讲我们正式把视角从“代码怎么写”提升到“系统怎么跑”。很多工程师会觉得部署是上线前才需要考虑的事情。但实际上部署架构从第一天就会反过来影响你的设计缓存放在哪里、数据库怎么连接、服务之间怎么通信、未来怎么扩容这些都取决于你最初选择的部署形态。这些问题如果不提前想清楚后面大概率就要返工。当前部署架构50 人规模怎么设计这一节里我给 Claude Code 的问题是Hify 是模块化单体技术栈是 Spring Boot Vue MySQL Redis pgvector。目标是 50 人内部使用生产环境采用 Docker K8s 部署。请帮我设计当前阶段的部署架构有哪些组件、请求怎么流转、每个组件的职责是什么。Claude Code 给出的答案很标准一个模块化单体应用加上三个外部有状态服务。用户请求先经过 Nginx静态资源由 Nginx 直接返回。API 请求反向代理到 Spring Boot。Spring Boot 再按需访问 MySQL、Redis 和 pgvector。其中MySQL 负责业务数据。Redis 负责缓存和会话相关数据。pgvector 负责向量检索。K8s 在这个阶段主要承担的是“部署容器的外壳”角色并不引入服务网格、多副本调度、复杂服务治理这些高级能力。各组件职责当前阶段该做什么、暂时跳过什么这里我认为 Claude Code 最有价值的不只是画出了“现在的系统长什么样”而是帮我们清晰地划出了一条线哪些是当前阶段必须做的哪些是可以明确暂时不做的。而且每一个“先不做”的结论都有理由。不是偷懒而是因为一期确实还不需要。等到触发条件真的出现比如用户量上来、数据规模变大再逐步补上对应能力。这才是比较健康的架构演进方式。当然这一步依然离不开人的判断。因为当前这个部署架构相对简单Claude Code 给出的方案大多数时候都比较稳但如果进入更复杂的系统形态仍然需要我们自己去做调整和取舍。换句话说现阶段你不能指望 AI 无脑替你完整设计并落地一个复杂应用。这里我想额外强调一点我越来越觉得程序员未来真正的价值会更多地体现在思考能力、拆解能力和边界判断能力这些架构层面的事情上。说实话这个要求比以前高得多。性能瓶颈不要等出问题了再想大部分工程师不会在项目初期就主动思考性能瓶颈往往都是系统出了问题再回头抢救。但如果你是以“架构师”的视角在工作就应该在设计阶段对这些问题有基本预判。哪怕一期根本不处理也要心里有数。这一步其实特别适合交给 Claude Code 来帮你完成。比如我给它的问题是基于 Hify 当前的部署架构Nginx Spring Boot MySQL Redis pgvector 外部 LLM API帮我分析这个系统的性能瓶颈可能在哪。请按严重程度排序并给出每个瓶颈的触发条件以及一期是否需要处理。Claude Code 的结论很直接一期根本不需要为了性能去做任何额外优化。原因也很现实。50 人规模的内部系统真实压力非常小大多数所谓的“性能瓶颈”触发条件都远远超过当前规模。真正需要提前关注的反而不是性能而是外部 LLM API 带来的两个问题超时导致的稳定性风险。Token 消耗带来的成本失控。这一节真正的价值不是你当场解决了什么性能问题而是你脑子里从此多了一张系统的“软肋地图”。以后真出了性能问题你不需要再靠猜而是可以直接回到这张图里看问题最可能出在哪里、触发条件是什么、优先级应该怎么排。而且这张图不一定非得自己从零画。你把当前架构图和约束条件给 Claude Code它几分钟就能帮你做出第一版然后你再负责判断它说得对不对。扩展架构从 50 人走向几千人接下来我让 Claude Code 继续设计架构演进路径如果 Hify 要从 50 人扩展到几千人当前架构需要怎么演进请帮我设计一个分阶段的扩展路径每一步的触发条件是什么、要改什么、不改什么。这类问题很适合让 AI 来做第一轮拆解因为它特别擅长把“演进路径”讲清楚什么阶段会触发升级。升级时应该加什么能力。哪些东西暂时不动避免过早复杂化。这比我们一开始就把系统设计成“大厂终局形态”更有意义。因为真实项目最怕的往往不是简单而是过早复杂化。数据模型概览先定骨架不急着定细节除了部署架构系统的数据结构也要尽早有一个整体轮廓。但这里有一个很重要的原则先定核心表和关系不要一上来就把每个字段抠得特别细。因为字段设计会随着模块开发不断调整现在定得越细后面改动越大。所以我给 Claude Code 的问题是基于 Hify 的功能范围模型管理、Agent、对话、工作流、知识库、MCP 工具帮我梳理核心数据表和它们之间的关系。只需要表名和关系不展开字段。Claude Code 给出了一份比较完整的初稿我确认后定成了下面这套骨架模型管理model_provider 到 model一对多。一个 OpenAI 提供商下面可以挂多个具体模型。知识库knowledge_base 到 document 到 document_chunk是一条一对多链路。document_chunk 是向量化的最小单位最终存储在 pgvector 中。工具tool 独立成表存 MCP 工具定义。Agentagent 是关联最多的表。它会关联 model也会通过中间表和 knowledge_base、tool 建多对多关系。工作流workflow 到 workflow_node一对多。工作流中的 LLM 节点也会关联 model。对话conversation 到 message一对多。conversation 绑定 agent 或 workflow。message 再通过 message_reference 和 document_chunk 建立多对多关系用于 RAG 溯源。用户user 和 api_key 负责用户身份与 API 调用能力。这里我特别想强调一件事你要清楚地知道 AI 擅长什么你自己又该负责什么。AI 很适合做第一轮梳理、拆解、归纳和补漏而你负责确认边界、判断合理性、做最后拍板。我们和 AI 不是竞争关系更不是替代关系而是协作关系。真正重要的是学会怎么和它配合释放我们自己的效率并把这种效率最终转化成现实收益。数据库规范现在定下来后面一直受益表结构的细节可以后面再定但数据库层面的规范现在就应该先定下来。因为从这一刻开始Claude Code 后面每一次建表、每一次写查询都应该自动遵守这些规则。我给它的问题是Hify 使用 MySQL 8.x pgvector。请帮我定义数据库层面的性能规范覆盖索引设计原则、大表预判和应对策略、分页查询注意事项、通用字段约定。要求具体到 AI 建表时可以直接执行。Claude Code 给出了一份很详细的规范我逐块确认后定稿。通用字段约定所有业务表都必须带上这四个公共字段id BIGINT NOT NULL AUTO_INCREMENT PRIMARY KEY, created_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3), updated_at DATETIME(3) NOT NULL DEFAULT CURRENT_TIMESTAMP(3) ON UPDATE CURRENT_TIMESTAMP(3), deleted TINYINT(1) NOT NULL DEFAULT 0这里有几条硬规则主键统一使用自增 BIGINT禁止 UUID。业务表禁止使用 NULL空值统一用空字符串或 0 表示。金额和 Token 用量统一使用 BIGINT 存最小精度值不使用 DECIMAL。枚举字段统一使用 VARCHAR(32)不使用 MySQL ENUM。这些其实就是团队规范。你不提前写清楚AI 就不会主动替你遵守。索引设计原则Claude Code 这里给出的规则很实用基本可以直接沉淀进规范。第一逻辑删除字段必须进入索引。因为项目里绝大多数查询都会带 deleted 0。如果索引里没有它很多时候等于索引没建好-- ✅ 正确 INDEX idx_agent_user (user_id, deleted) -- ❌ 不够 INDEX idx_agent_user (user_id)第二组合索引等值列在前范围列在后。这是MySQL索引的基本原则但不提醒Claude Code它自己写查询时经常不遵守。INDEX idx_message_conv_time (conversation_id, created_at)第三多对多关联表两个方向都要索引。agent_tool表按agent_id查和按tool_id查都是高频操作只建一个方向的索引另一个方向就全表扫描。PRIMARY KEY (agent_id, knowledge_base_id), INDEX idx_kb_agent (knowledge_base_id) -- 反向查询索引第四唯一约束用UNIQUE INDEX不要只在代码层校验。并发场景下代码校验有竞态问题数据库约束才是最后防线。第五禁止在大文本字段建索引。content、prompt这类TEXT字段不能建索引需要全文搜索的场景后续引入ES。大表预判Hify中增长最快的两张表message 表每次对话产生2-N条记录50人每天几百到上千条。应对建好时间范围索引conversation_id created_at预留按时间归档的能力。一期建好索引够用半年。document_chunk 表知识库分块数据100篇文档可能产生5000行。应对向量数据存pgvectorMySQL只存元数据和vector_id指向pgvector的记录不在MySQL里存向量本身。其他表provider、agent、workflow都是配置数据增长慢不需要特别关注。分页查询规范-- ❌ 禁止 OFFSET 深分页百万行时极慢 SELECT * FROM message ORDER BY id DESC LIMIT 20 OFFSET 100000;-- ✅ 用游标分页SELECT * FROM message WHERE conversation_id ? AND id #{lastId} AND deleted 0 ORDER BY id DESC LIMIT 20;一期数据量小OFFSET够用。但规范先定好Claude Code知道用游标分页后面数据量上来了不用改代码。管理后台必须用OFFSET的场景限制最大页数超过10000条直接提示缩小查询范围。还有一条COUNT查询单独处理列表页只在第一页返回total翻页不重复查。这个细节Claude Code不说你很容易忽略但它对大表的查询性能影响很大。pgvector 规范向量数据单独存PostgreSQL和MySQL业务数据分离CREATE TABLE vector_chunk ( id BIGSERIAL PRIMARY KEY, chunk_id BIGINT NOT NULL, -- 对应 MySQL document_chunk.id embedding vector(1536) NOT NULL, created_at TIMESTAMPTZ NOT NULL DEFAULT NOW());-- 必须建 HNSW 索引否则全表扫描CREATE INDEX idx_embedding_hnswON vector_chunkUSING hnsw (embedding vector_cosine_ops)WITH (m 16, ef_construction 64);两条硬规矩必须建HNSW索引一期数据量小感知不到差异但数据量上来后没索引检索会从毫秒级变成秒级。检索时必须加LIMIT禁止不加LIMIT的向量查询全量排序会拖垮数据库。这些规范看起来是数据库基础知识但你不写进CLAUDE.mdClaude Code建表时就不会自动加deleted进索引、不会考虑分页性能、不会预判大表问题、不会给pgvector建HNSW索引。写了后面每一次建表、每一次写查询都自动遵守。如果有心你可以从上面的这个问题以及它的答案中知道设计数据库表应该注意什么。我觉得这就是我们这节课的价值。问了问题辨别答案学习答案——这才是把AI融入工作的核心思路。最后把它沉淀进 CLAUDE.md前面这些内容最终都应该落进你的项目规范里而不是只停留在一次对话中。### 部署架构 生产环境Docker K8s - 前端Nginx 托管静态文件 API 反向代理proxy_buffering off - 后端Spring BootK8s Deployment一期单副本 - 数据库MySQL 8.x外部服务 - 缓存Redis 7.x外部服务 - 向量库PostgreSQL pgvector外部服务 - 本地开发java -jar npm run devstart.sh 一键启动 ### 缓存策略 - Provider/Agent 配置Redis Cache-AsideTTL 30min - 对话上下文RedisTTL 2h - 对话消息、知识库文档不缓存走数据库 - LLM 响应不缓存 ### 数据库规范 通用字段 - 主键 id BIGINT 自增禁止 UUID - 时间字段 created_at / updated_atDATETIME(3) - 逻辑删除 deleted TINYINT(1) - 禁止 NULL空值用空字符串或 0 - 枚举用 VARCHAR(32)不用 MySQL ENUM 索引规则 - 命名 idx_{表名}_{字段名} - 逻辑删除字段必须加进组合索引 - 组合索引等值列在前范围列在后 - 多对多关联表两个方向都要索引 - 唯一约束用 UNIQUE INDEX不只在代码层校验 - 禁止在 TEXT/BLOB 字段建索引 - 不建数据库级外键约束应用层维护 分页规则 - 默认用游标分页WHERE id lastId ORDER BY id DESC LIMIT N - OFFSET 分页限制最大 10000 条 - COUNT 只在第一页查翻页不重复查 大表预判 - message增长最快必须建 (conversation_id, created_at) 索引 - document_chunkMySQL 只存元数据向量存 pgvector pgvector 规范 - 向量表建在 PostgreSQL维度固定 1536 - 必须建 HNSW 索引 - 检索必须加 LIMIT禁止全量排序 ### 扩展路径 一期单副本 → 多副本 主从分离500人 → MQ 异步 Qdrant2000人→ 微服务拆分 Redis 集群几千人总结这一讲我们做了四件事设计了当前阶段的部署架构。预判了系统的性能瓶颈。规划了未来的扩展路径。定义了数据模型骨架和数据库规范。如果只挑一个最有价值的点我会选“性能瓶颈预判”。因为大多数工程师不会在系统还没出问题的时候主动去画这张图但你作为架构师脑子里必须有这张地图瓶颈在哪、什么时候会触发、到时候应该先改什么。而这张地图不需要你一个人从零开始画。你完全可以先让 Claude Code 基于当前架构给出第一版分析再由你来判断它说得对不对。另一个很值得强调的点是数据库规范。索引原则、分页约束、大表预判这些对有经验的工程师来说可能是常识但对 Claude Code 来说不是。你不写它就不会稳定遵守你现在花 10 分钟定下来后面每一次建表、每一次写查询都会持续受益。上一讲解决的是“代码怎么组织”这一讲解决的是“系统怎么运行”。两讲合起来才是 Hify 一套完整的架构设计从模块划分到部署形态到扩展路径再到数据规范整条线才算真正打通。