Wang Xu

一、云函数合并 这个月还做过一部分云函数整理。 原来有一些云函数比较分散，后面按功能合并成几个入口，也清理了一些无关函数。 这里主要是减少部署和维护成本。 环境变量也整理到 KMS，尽量让配置来源统一。 这个任务技术上没有特别复杂，更多是工程整理。 二、新应用部署 另一个 Serverless 任务是新应用部署。 大概是： SSR 前端 Node.js API SQLite NAS 登录认证 云函数普通 Node.js 运行时 这里踩的问题比较多。 三、Node.js 小版本 平台写的是 Node20。 但实际小版本是 20.10。 项目里前端依赖一开始要求 20.19+，所以构建会出问题。 后面为了兼容运行时，降级了 Vite / TanStack 相关依赖。 以后看到 Node20 也要确认小版本。 四、better-sqlite3 better-sqlite3 是 native 依赖。 它需要编译，和普通 JS 依赖不一样。 云函数在线层构建环境里，GCC 版本太旧，新版 better-sqlite3 编译失败。 后面降级了相关依赖，让它能在当前运行环境里编译。 这里要看： Node 版本 Python 版本 GCC 版本 系统环境 native 依赖版本 五、代码包和依赖层 一开始尝试把完整 node_modules 放进代码包。 包太大，云函数直传容易超时。 后面改用 OSS zip 部署。 ...

一、升级路径 MongoDB 迁移之后，还做了版本升级。 版本是从 3.6 升到 4.2。 这里不能直接跨过去，要按路径来： 1 3.6 -> 4.0 -> 4.2 数据库升级和普通依赖升级差别挺大。 普通依赖可能改个版本号，跑一下测试。MongoDB 这里还要看官方升级路径、replica set 状态、FCV、节点角色。 二、FCV FCV 是 Feature Compatibility Version。 我当时的理解是，它和 MongoDB 二进制版本属于两个概念。 二进制版本升上去了，集群功能兼容版本还要单独处理。 这里要区分： MongoDB 程序版本 数据文件兼容 replica set 节点状态 FCV FCV 调整时机要放在节点升级完成之后看，不能一开始就乱改。 三、滚动升级 升级时是 replica set。 所以走滚动升级。 大概顺序： 1 2 3 4 5 6 7 先升级 secondary 确认节点恢复 确认复制正常 primary step down 让其他节点接管 升级原 primary 再确认 replica set 状态 secondary 不承担当前写入入口，所以先从 secondary 开始。 ...

一、原来的结构 这次迁移的 MongoDB 原来是 sharded cluster。 简单理解： 1 应用 -> mongos -> 多个 shard 数据规模大概是近亿级文档，数十 GB，集合是百级。 目标是迁到无分片结构。这里就不能只看数据怎么搬，还要看迁移后的结构。 如果只是同结构迁移，主从同步可能可以考虑。但这次要去分片，最后还是走 mongodump 和 mongorestore。 二、为什么要停写 通过 mongos 路径 dump，当时没有合适的 oplog 增量兜底。 如果业务还在写入，dump 过程中数据会继续变化，后面很难确认导出的数据是否稳定。 所以正式迁移时，前端先进入维护状态，写入停掉。 停写以后再做迁移前指纹。 这个顺序要注意： 1 2 3 4 5 6 7 8 维护状态 停写 迁移前指纹 mongodump scp mongorestore 迁移后指纹 恢复访问 三、预演 正式迁移前，先做镜像和快照。 然后在隔离 VPC 里复刻一台测试机器。这里要处理 SSH、密钥、安全访问、MongoDB 二进制、keyFile、数据目录这些东西。 预演大概做了三次左右。 每次都尽量跑完整流程： 1 2 3 4 5 6 7 8 9 模拟停写 迁移前指纹 mongodump scp mongorestore 索引恢复 迁移后指纹 数量对比 抽样数据对比 预演主要看耗时。 ...

入职后第一个月，主要在处理 MongoDB 迁移。 数据量大概是近亿级文档，数十 GB 级别，dump 包十几 GB。这个规模对我来说挺大，刚开始压力也比较明显。 最担心的是丢数据。 数据迁移不像普通功能开发，改错了再发一版就行。生产数据库一旦出问题，影响会很直接。迁移过程中还要停写，前端进入维护状态，dump、scp、restore、校验都要在维护窗口里完成。 一、这个月接触的任务 这个月主要做了这些： MongoDB 去分片迁移 MongoDB 3.6 到 4.2 升级 云函数合并和清理 Serverless 新应用部署 支付链路和 webhook 排查 多语言 SEO 页面修复 主线还是 MongoDB。 原来的 MongoDB 是 sharded cluster，多分片。目标是迁到无分片结构。所以不能直接当成普通搬库处理。 后面用了： 1 2 mongodump mongorestore 配合停写、指纹校验、scp 传输、恢复后校验。 二、预演这块学到很多 leader 提醒先做镜像预演，VPC 隔离，不要直接上生产。 这个对我帮助很大。 我自己搭配 AI agent 做了环境复刻、脚本整理、预演、校验和执行。AI agent 主要用来处理命令整理、脚本草稿、步骤拆解这些比较繁琐的事情。 预演大概做了三次左右。 每次都尽量跑完整流程： 1 2 3 4 5 6 7 8 9 镜像/快照 隔离 VPC 启动测试机 模拟停写 迁移前指纹 mongodump scp 到新机器 mongorestore 迁移后指纹 数量和抽样数据对比 dump 大概是 20-25 分钟级别。restore、索引恢复、传输、校验也都要算进去。 ...

一、schema.ts 1 2 3 4 5 6 7 8 9 10 11 12 13 14 import { integer, sqliteTable, text } from 'drizzle-orm/sqlite-core'; import { createInsertSchema, createSelectSchema } from 'drizzle-zod'; export const rnlearnTodos = sqliteTable('rnlearn_todos', { id: integer('id', { mode: 'number' }).primaryKey({ autoIncrement: true }), content: text('content').notNull(), createdAt: integer('created_at', { mode: 'timestamp_ms' }).notNull(), }); export const insertRnlearnTodoSchema = createInsertSchema(rnlearnTodos); export const selectRnlearnTodoSchema = createSelectSchema(rnlearnTodos); export type RnlearnTodo = typeof rnlearnTodos.$inferSelect; export type NewRnlearnTodo = typeof rnlearnTodos.$inferInsert; 主角 drizzle-orm/sqlite-core drizzle-zod drizzle-orm/sqlite-core 是 Drizzle ORM 针对 SQLite 做的 core 包，类似于驱动。 drizzle-zod 是 Drizzle 做的辅助工具包，可以使用到 zod，专门为了对接 zod。 能生成 zod 校验规则，数据库 → 校验，保证单一数据规则来源。 sqliteTable sqliteTable：创建数据库表。 1 sqliteTable("数据库真实表名", { 字段配置 }) 字段配置就是类似对象。 通过 drizzle-orm/sqlite-core 给定的可以定义的类型，来给定结构。 ...