先回答一个问题：为什么不用一套技术栈搞定？
很多团队做系统，选一个主流框架，前端后端全用同一种语言、同一套技术。省事，维护方便。
我们也考虑过。但仔细想了一个问题：一个做BOM计算的高性能需求，和一个做表单录入的普通需求，用同一套技术，合适吗？
不合适。就像你不能用跑车拉货，也不能用卡车飙车。
所以我们选择了"混合技术栈"：该快的地方用C++，该灵活的地方用Python，该好用的地方用Vue。
今天把这套架构拆开了讲，不吹不黑，说说每个选择的背后逻辑。
一、微服务：为什么拆开，比合在一起好
我们系统有11个核心服务，按业务领域独立部署：
product-service— 产品管理bom-service— BOM管理route-service— 工艺管理document-service— 文档管理change-service— 变更管理- ……以及6个支撑服务
单体架构的问题，每个团队都踩过：改一个模块，全系统得重测；一个Bug，整个服务挂掉。微服务解决的就是这四个痛点：
| 问题 | 单体架构表现 | 微服务表现 |
|---|---|---|
| 发布 | 全系统一起发，周级 | 独立发布，小时级 |
| 扩展 | 整体扩容，浪费资源 | 只扩瓶颈服务 |
| 故障 | 一个Bug拖垮全局 | 单服务故障不影响其他 |
| 技术选型 | 全系统统一语言 | 每个服务选最合适的技术 |
二、C++引擎：为什么不用纯Python？
这是今天最核心的问题。Python开发快、生态好，为什么还要搞C++？
因为有些活，Python干不动。
BOM计算的痛点
一个复杂产品的BOM可能有几千个零部件，多层嵌套。计算总价、检查冲突、找相似结构，涉及大量递归遍历和数值计算。
Python的GIL（全局解释器锁）让多线程变成"伪并行"，大数据量的计算场景下，性能差距被成倍放大。
BOM结构计算：Python 2秒 → C++ 100毫秒（20倍提升）
相似BOM检测：Python 5秒 → C++ 200毫秒（25倍提升）
AI推理（分类）：500毫秒 → C++ 50毫秒（10倍提升）
批量数据处理：Python 10分钟 → C++ 30秒（20倍提升）
这不是"快一点"的区别，是"能不能用"的区别。用户等100毫秒没感觉，等2秒就会觉得系统卡。
AI推理引擎
我们的AI引擎也是C++写的，底层用ONNX Runtime做推理。原因很简单：
- 模型推理是纯计算密集型，C++的优势最大化
- ONNX Runtime原生C++ API，零额外开销
- 结果缓存层也在C++内部完成，减少网络往返
三、服务间怎么通信？
11个服务各跑各的，它们之间怎么说话？我们用了四种方式：
| 通信方式 | 用在哪 | 延迟 |
|---|---|---|
| gRPC | 服务间高频调用（核心通道） | <10ms |
| REST API | 外部API调用、前端对接 | <50ms |
| 消息队列 | 异步任务（通知推送、报表生成） | 秒级 |
| WebSocket | 实时通知、在线协作 | 实时 |
为什么选gRPC当主通道？三个理由：
- Protobuf序列化比JSON快5-10倍——同样的数据，体积更小
- HTTP/2多路复用——一个连接并发多条请求，不用建立新连接
- 强类型契约——编译期就能发现接口不一致的问题，不用等到运行时才报错
四、AI能力架构：12项AI怎么跑起来的
这不是"接个OpenAI API"那么简单。我们的AI全部是自有模型，部署在系统内部。
| AI功能 | 技术方案 | 响应时间 |
|---|---|---|
| 产品分类推荐 | BERT-base 文本分类 | <100ms |
| BOM结构优化 | 图神经网络 GNN | <500ms |
| 相似BOM检测 | 向量相似度搜索 | <200ms |
| 工艺路线推荐 | Transformer 序列推荐 | <300ms |
| 文档智能标签 | BERT 多标签分类 | <200ms |
| 变更风险预测 | XGBoost 风险评估 | <100ms |
| 语义搜索 | Sentence-BERT 向量检索 | <300ms |
架构分层很简单：Python服务层做业务逻辑和API暴露，gRPC调C++推理层做高性能计算，模型文件统一管理支持热更新。
五、数据库：为什么一个PostgreSQL就够
很多系统为了AI能力专门引入向量数据库（Milvus、Weaviate），再维护一套基础设施。
我们选了另一条路：PostgreSQL + pgvector扩展。
一个数据库，同时搞定：
- 关系型数据——产品、BOM、工艺等业务表，ACID保证
- 向量数据——产品向量512维、文档向量768维，相似度搜索<300ms
- 缓存层——Redis Cluster辅助，热点数据命中率85%
少维护一套数据库，运维成本直接降一大截。这就是"合适就好"的思路。
六、部署：K3s还是K8s？
K8s是行业标准，但我们选了K3s。为什么？
- K8s太重——光控制平面就要消耗几G内存
- 我们的规模——11个服务，中小规模部署，K3s足够了
- 兼容K8s生态——kubectl、Helm都能用，迁移无压力
可用性：目标99.9%，实际 99.95%
平均故障恢复时间：<2分钟
最长故障恢复时间：<5分钟
七、全套技术选型一览
| 层级 | 技术 | 一句话理由 |
|---|---|---|
| 前端 | Vue 3 + TypeScript | 类型安全，开发效率高 |
| 网关 | Traefik/Nginx | K3s原生，配置简单 |
| 后端 | Python 3.11 + FastAPI | 异步性能好，开发快 |
| 通信 | gRPC + REST | 内部高效，外部兼容 |
| 引擎 | C++17/20 | 高性能计算不妥协 |
| 数据库 | PostgreSQL 16 + pgvector | 关系+向量一体化 |
| 缓存 | Redis | 成熟稳定 |
| 部署 | K3s + Docker | 轻量高效 |
八、我们还知道自己不够好
这套架构有三个已知的局限，也是下一步要解决的问题：
- AI推理集中：所有AI请求走同一个AI服务，高并发时可能成为瓶颈。方向：客户端做轻量推理，减轻服务端压力。
- 向量维度固定：512/768/256维定死了，换模型要改结构。方向：引入专用向量数据库。
- C++维护门槛高：需要C++工程师，招人难。方向：评估WebAssembly方案，降低技术门槛。
架构不是一次成型就完美的，是不断迭代的。敢把自己的短板亮出来，才是真诚的技术分享。
最后
这套架构的核心思路就四个字：合适就好。
不用最贵的，不用最火的，用最合适的。每个技术栈都有自己的"为什么是它"。
如果你对这套架构有想法，或者想讨论你们的技术选型，欢迎来找我们聊聊。架构没有标准答案，但有最优解——对你们团队来说的那个。
© 2026 AiFLY Team. All rights reserved.
系统地址： https://plm.aifly.ren
关注动态： https://aifly.ren