18
当前服务
作品集、简历、AI 对话与档案、日常工具、视觉实验、论文检索与两个股票研究服务。
Outcome
结果先于过程
从当前服务与运行方式出发，展示多站点项目的职责与边界。
8
静态前端站点
www、resume、ai-projects、tools、llm-test、finance-evaluation、blog 与 md-view 各自生成 HTML 与资源，由 Nginx 按域名直接提供，生产不依赖常驻 Bun SSR。
10
独立后端服务
paper-search、stock-sentiment、stock、ai-chat、analytics、live-better、app-market、cook、friend-connect 与 copy-paste 均使用 Bun，分别处理任务、数据、对话、流量查询、指南与菜谱检索、应用需求、成员连接或跨设备分享。
main
可回滚交付
VM 拉取经过验证的 main，按真实依赖构建受影响服务；静态发布无需重启进程，后端变化重启所属服务。产物指针保留恢复路径。
Architecture decision
按运行职责拆分，而不是按技术偏好。
八个前端站点在构建时生成 HTML，由 Nginx 直接提供。十个服务保留独立后端，处理任务、数据、对话、流量查询、指南与菜谱检索、应用需求、成员连接或跨设备分享。共享 Bun SSR 用于本地开发预览。
*.leikunx.com
│
▼
Nginx :443
├─ 8 static sites → dist/client
├─ paper-search → Bun :3001
├─ stock-sentiment → Bun :3010
├─ stock → Bun :3011
├─ ai-chat → Bun :3012
├─ analytics → Bun :3013
├─ live-better → Bun :3014
├─ app-market → Bun :3015
├─ cook → Bun :3016
├─ friend-connect → Bun :3017
└─ copy-paste → Bun :3018查看路由与部署清单 ↗Tradeoffs & evolution
简单架构的收益与边界。
- 静态站点保留首屏内容和 SEO，减少常驻进程；内容变化需要重新构建发布
- 独立后端缩小代码变更影响范围；同一 VM 仍共享 CPU、内存与宿主故障风险
- 共享库降低重复维护成本；库的变化必须沿真实依赖识别受影响消费者
- 单 VM 便于维护但存在单点故障；可用性与负载要求提高时再评估独立计算资源
- 产物指针可回退前端与后端发布；源码修复在 main 发布，应用数据另行管理
Execution loop
状态、最小动作、客观门禁
DISCOVER
建立权威清单
以当前项目的服务目录和部署清单核对入口、运行时、资源与数据边界，再确定本次变化影响哪些服务。
Service inventoryDependency graphDeployment map
STAGE
在切换入口前完成质量门禁
完成类型、格式、测试与构建检查；验证预渲染内容、已知路由、资源 MIME 与变化涉及的后端接口，成功后才切换产物指针。
Build gatesNginx syntaxHost routing
DEPLOY
按变化范围发布
VM 拉取经过验证的 main，按服务记录与依赖图选择构建和重启。静态页面直接发布；路由、证书与 systemd 配置作为独立运维变化处理。
Main commitSelective buildsRollback copies
VERIFY
用真实交互证明结果
从受影响的页面与用户流程出发，检查桌面、移动端、键盘交互、资源和控制台；共享组件、路由或 API 变化时沿依赖扩展验证。
Browser DOMInteractionsConsole gateLink/MIME audit
Operating model
把质量与运行边界写进交付方式。
这些是仓库中的设计与校验规则。生产运行结果仍需要对应环境的检查与记录。
EDGERepository design
入口、缓存与失败语义
Nginx 配置统一 HTTPS 与响应头；静态 HTML 保留已知路由和 noindex 404，哈希资源长期缓存。源码、构建渲染器和凭据位于公开资源目录之外。
RUNTIMEBounded
为任务服务限定资源边界
独立后端监听 loopback。论文检索入口配置请求体上限与写请求限流，后台 worker 与 timer 保留自己的生命周期；动态接口与静态资源采用不同缓存语义。
QUALITYScoped gates
让验证遵循变化的影响范围
类型检查、格式、函数长度与构建产物校验形成基础门禁。浏览器验证从变化所属的页面出发，只有共享组件、路由或真实依赖变化时才扩展覆盖范围。
Failure modes
先定义失败边界，再设计恢复路径。
这是当前交付机制的恢复设计，不把代码中的保护逻辑等同于已完成的生产灾备演练。
BUILDFailure boundary
构建失败时保留已发布版本
服务先生成暂存产物，成功后才切换 dist 指针。失败的构建不应覆盖公开目录；服务成功记录用于下一次影响识别。
DEPLOYRecovery path
重启失败时恢复选中的状态
部署脚本为受影响服务保存产物指针、运行状态与发布记录。后端重启或就绪检查失败时恢复所选状态；未变化的服务与 timer 保持运行。
STATEExplicit limits
把产物、源码与数据分开恢复
产物回退恢复前端与不可变后端源码指针、发布记录和运行状态；定时任务的 checkout 源码、依赖、配置与持久化数据需要单独恢复。
What this demonstrates
架构的价值，在于让下一次变化更可控。
这套系统把静态交付、任务执行、共享能力与发布边界放在同一张设计图中。 当前实现展示了如何做取舍与缩小变更范围；下一阶段将用公开评测、故障注入和可观测数据验证 Agent 系统的质量与恢复能力。