核心技术经验复盘：5 个稳定的系统开发默认选项

核心技术经验复盘：5 个稳定的系统开发默认选项

内容说明：本文用于讲解方案设计、实施步骤与验收方法。文中的企业、人物、工期、价格和成效数字如无公开来源，均为匿名化情境示例或验收指标示例，不代表经过公开证据核验的客户项目，也不构成效果承诺。实际结果以需求确认、测试数据和双方验收记录为准。

模拟需求或验收摘录（情境演示）

「为什么每个新项目都要重新选一遍技术栈?」—— 是的,核心技术经验自 2018 年起我们不再这样做了。

前阵子写了《给连锁门店做 ERP,核心技术经验自 2018 年起客户最常翻车的 5 个环节》(#527),聊的是「客户最常踩的坑」。这篇是它的姊妹篇:我们自己后来一致坚持的默认选项—— 当客户没有明确偏好时,我们直接默认给的这 5 个选项,以及为什么。

不是技术完美主义,是真正能跑稳、运维省心、出问题能定位的折中。

一、数据库:PostgreSQL 而不是 MySQL(如果允许选)

历史背景

早期我们从 MySQL 起家,早期项目 80% 用 MySQL。现在我们 PostgreSQL 比例反过来——非国产化项目默认 PostgreSQL。

为什么

• JSON 字段:很多管理系统的「扩展字段」需求(每个客户要的不一样),MySQL 5.7+ 也有 JSON,但 PG 的 jsonb + GIN 索引是真原生
• 全文搜索:客户经常让我们做「商品/订单/客户的全文搜索」,PG 的 tsvector 是开箱即用,MySQL 要么上 ES 要么 LIKE
• Window Function / CTE:报表类需求(「按月同比」「客户分层」),MySQL 8 才刚补齐,PG 用了 10 年
• 运维成本更低:PG 没有 MySQL 那套「主从延迟 / binlog 格式 / GTID」的复杂度,新人接手快

什么时候还是 MySQL

• 客户明确要求「国产化 / 信创」—— 那必须走 MySQL 或 OceanBase / 达梦
• 团队全是 MySQL 老手,不想换
• 单库极简,没有 JSON/全文/报表需求

二、ORM:Prisma / Drizzle( TypeScript 项目) 或 SQLAlchemy 2.x( Python 项目),而不是裸 SQL

我们的演变

• 第 1-3 年:Django ORM / Hibernate —— 重型 ORM,改 schema 痛苦
• 第 4-5 年:裸 SQL + 轻量查询构建器 —— 灵活但容易 SQL 注入、字段对不上
• 后期阶段:Prisma / SQLAlchemy 2.x —— schema-first,迁移可视化,类型安全

为什么

• 迁移管理:prisma migrate dev / alembic revision 自动生成,再没人手动改生产 schema
• 情境示例（非实测）： 类型安全:改了字段,前端 / 后端调用方编译时就报错,减少 90% 「字段不存在」线上 bug
• 新人友好:不熟 SQL 也能写出来大致正确的查询

什么时候还用裸 SQL

• 复杂报表查询(几百行 SQL),ORM 写起来反而绕
• 性能极致敏感的导出 / 批量更新

三、后台管理:RBAC + 多租户(id 隔离)而不是「每个客户一套部署」

早期的痛

第 2 年我们给 3 个连锁客户做 ERP,每个客户独立部署一套。结果:

• 一个客户要改字段,3 套代码都要改
• 情境示例（非实测）： 服务器成本 3 倍
• 客户报 bug 我们查 3 套环境
• 团队 3 个月后没人记得哪个是哪个分支

现在的默认

所有客户共用一套代码,共用一套部署,数据用 tenant_id 隔离。

• 代码分支只维护一份,新功能所有客户自动受益
• 服务器成本线性增长(数据库行数变多),不是客户数倍
• 报 bug 我们能直接查 production 数据,定位快

什么时候还是要单租户

• 客户行业有合规要求(金融 / 医疗有时不允许数据混部)
• 客户体量超大(单客户日订单 > 100 万,数据库必须独立)
• 客户要求「数据物理隔离」(这种情况我们用「共享数据库,独立 schema」折中)

四、缓存:Redis(不是 Memcached,不是「直接上 ES」)

选 Redis 的理由

• 数据结构丰富(String / Hash / List / Set / Sorted Set / Stream)
• 持久化(RDB / AOF),重启不丢
• Pub/Sub 做实时通知(WebSocket 后端常用)
• Lua 脚本做原子操作

什么时候不用 Redis

• 只做简单 KV 缓存,不需要持久化 → Memcached 更简单
• 全文搜索 → 上 Elasticsearch,别用 Redis 凑 (见过客户 5 万 SKU 用 Redis 做搜索,内存撑爆)
• 时序数据 → InfluxDB / TDengine

五、部署:Docker Compose(中小项目) 或 Kubernetes(年订单 > 500 万的项目)

中小项目(年订单 < 100 万)

Docker Compose + 一台云服务器。理由:

• 启动快,文档简单,客户运维也能学会
• 成本低,一年 ECS 费用 < 1 万
• 出问题排查直接 SSH 上去看日志

中型项目(年订单 100-500 万)

单机 Docker Compose + 自动备份 + 监控告警。理由:

• 还不到上 K8s 的复杂度,K8s 运维本身要一个专职
• 但要加:定时数据库备份、磁盘告警、慢查询监控

大项目(年订单 > 500 万)

Kubernetes + 多副本。理由:

• 7×24 不能停机,需要滚动更新
• 大促 / 活动时弹性扩缩
• 多区域部署

我们坚决不做的

• 不用 serverless 跑核心管理后台 —— 冷启动延迟 + 状态管理麻烦 + 客户内部网络限制
• 不用「全自动 DevOps」平台(如阿里云 EDAS 全家桶)—— 锁定厂商,迁移成本高

总结:5 个默认选项速记

这 5 个不是「最佳实践」,是「我们 核心技术经验自 2018 年起不再出大问题的实践」。您接的项目如果是类似规模(年订单 < 500 万),完全可以照抄。

常见问题

Q1:为什么不是 MongoDB?

管理系统本质是关系强(订单关联客户、客户关联门店、门店关联库存),MongoDB 写起来能跑,但后期报表、关联查询会痛苦。除非项目核心就是文档型(比如 CMS、知识库),否则不推荐。

Q2:为什么不上 GraphQL?

管理系统大多是内部使用,用户量小,数据查询模式相对固定,GraphQL 的好处(客户端灵活拼装)不明显。REST + Swagger 已经够用,团队学习成本低。

Q3:你们会主动给客户推技术选型吗?

会。客户大多不懂技术细节,你说「用 PostgreSQL」他们会问「为什么不是 MySQL」,这时候把上面这些理由简短说一下,客户基本都接受。关键是把「对他们业务有什么好处」翻译出来,不是炫技术词。

Q4:如果客户已经有现成技术栈,你们会坚持改吗?

不会。我们接需求,不改现有架构。强行推「更好方案」是乙方大忌——交付风险全在你这边,客户只看到「折腾半天」。除非客户主动问。

Q5:这套默认选项适合创业公司从 0 搭吗?

更适合。我们这套不是给大厂用的(大厂有专职架构师自己选),是给「3-5 人小团队接外部项目」用的——快速交付、运维简单、出问题能定位。

模拟需求或验收摘录（情境演示）

信任网络科技工作室 — 2018 年起积累的实践经验,做管理系统找我们就对了。
苏州工业园区,扫码加微信,聊您的具体场景 👇