客户案例挑战
旧应用还能用，但跑在老旧的 Rails 6.1 上，与自己的数据库共用一台服务器，还带着让经销商流失客户的问题：公开搜索的筛选器从来没生效，手机拍的照片可能显示为倒的。
之前
之后
之前: Rails 6.1 和 Ruby 3.1 跑在一台服务器上，应用与数据库共存
之后: 一个 Rust 二进制文件装在小体积容器里，运行在 Kubernetes 上，配托管的 PostgreSQL 18 和只读副本
之前: 从来没生效的公开搜索筛选器
之后: 能正常工作的搜索筛选器
之前: 重复的地址会打开另一辆车
之后: 地址唯一，由一次数据迁移修复，并在数据库层强制约束
之前: 手机照片可能显示为倒的，且保留了 GPS 位置
之后: 照片在上线前已转正方向、压缩尺寸并清除元数据
之前: 邮件服务商一出问题，联系表单就失效
之后: 消息在后台通过 Amazon SES 发送，并用 Cloudflare Turnstile 拦截垃圾信息
我们构建了什么
一次完整重写，保留业务依赖的一切，随后才是新的公开站点。用 Rust、axum 和 PostgreSQL 构建，部署在 Kubernetes 上。
相同的 URL、数据与登录账号
新应用读取同一个数据库、同一个照片存储和同一批密码哈希，因此链接、库存车和员工账号原样延续。
现代的公开站点
一个快速、移动优先的库存车网站，带 WhatsApp 按钮，在重写版本上线后重新设计。
3D 虚拟展厅
一个 three.js 车行，访客可以环看车辆、品牌和联系方式，只有访客打开时才会下载。
搜索与 AI 可见性
meta 标签、JSON-LD、站点地图、常见问题和 llms.txt 都从实时库存生成，让搜索引擎和 AI 助手能够描述这家经销商及其车辆。
照片直接用手机拍
后台会纠正方向、缩放到 1920 px、清除 GPS 等元数据，并逐张处理照片，所以员工只需一部手机。
隐私与安全
隐私和条款页面载有公司法律信息，分析统计仅在用户同意 cookie 后运行，公开表单和登录页都有 Turnstile，邮件以 DKIM、SPF 和 DMARC 签名。
工程成果
2026 年 9 月在代码中统计；内存于 2026 年 10 月在生产环境中测得。
78
每次改动都运行的自动化测试
11
修复的旧应用缺陷数
5
从重写完成到新公开站点上线的天数
~17 MB
空闲时占用内存
- 回滚只需改一次 DNS，旧服务器始终保持可用
- 切换前比对了新旧数据库的记录条数
- 没有复制任何照片：新应用使用同一个存储桶
- 公开页面由只读副本提供，必要时自动回退到主库
技术
- Rust
- axum
- PostgreSQL
- three.js
- Amazon SES
- Cloudflare Turnstile
- Kubernetes
- Honeybadger
