需求分析与架构设计：功能需求拆解、非功能需求、微服务 vs 单体
好，咱们进入第二章。说实话，很多做自动报价系统的团队，一上来就撸代码，结果做到一半发现性能扛不住，或者改个需求要动整个系统。我见过太多这样的案例了。所以这一章，咱们把地基打牢——先搞清楚到底要做什么，再决定怎么做。
功能需求拆解：报价引擎到底要干哪些活？
先别急着想技术选型。我个人习惯，第一步永远是画功能边界。一个自动报价引擎，核心功能其实就这几块：
- 产品配置管理：支持不同产品线、不同定价模型的配置。说白了，就是能动态调整报价规则，而不是写死在代码里。
- 询价请求处理：接收外部系统（比如CRM、电商平台）发来的询价请求，解析参数，校验合法性。
- 定价计算引擎：这是心脏。根据配置的规则、历史数据、实时市场行情，算出最终报价。
- 报价结果输出：把计算结果格式化返回，同时记录日志和审计信息。
- 缓存与预热：高频查询的报价结果，不能每次都重新算一遍。嗯，这里要注意缓存失效策略。
我在项目中遇到过，有人把产品配置和定价逻辑混在一起，结果每次改价都要重新部署。这其实是个大坑。所以功能拆解时，一定要把「配置」和「计算」解耦。
非功能需求：延迟与吞吐量，鱼和熊掌怎么兼得？
功能需求是「做什么」，非功能需求是「做到什么程度」。对于报价引擎，最核心的两个指标就是延迟和吞吐量。
| 指标 | 典型要求 | 我的经验值 |
|---|---|---|
| P99 延迟 | < 200ms | 实际项目中，金融级报价要求 < 50ms |
| 吞吐量 | 1000 QPS | 双11场景下，峰值可达 5000+ QPS |
| 可用性 | 99.99% | 每宕机1分钟，损失可能上百万 |
| 一致性 | 最终一致性 | 报价场景下，强一致性反而会拖垮性能 |
你想想看，如果每次报价都要查数据库、算折扣、调外部接口，200ms 根本不够用。所以必须引入缓存和预计算。我曾经在一个项目中，把热点报价的缓存命中率从 60% 提升到 95%，P99 延迟直接从 800ms 降到了 80ms。
核心原则：延迟和吞吐量是 trade-off。要低延迟，就得牺牲一点吞吐量（比如加锁）；要高吞吐，就得接受稍高的延迟（比如异步批处理）。关键是要找到业务能接受的平衡点。
微服务 vs 单体架构：别盲目跟风
现在一说架构，很多人就想到微服务。但说实话，不是所有场景都适合。我见过一个团队，就三个人的小项目，硬拆了八个微服务，结果维护成本比开发成本还高。
咱们来对比一下：
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 开发速度 | 初期快，后期慢 | 初期慢，后期快 |
| 部署复杂度 | 低，一个包搞定 | 高，需要容器编排、服务发现 |
| 扩展性 | 只能整体扩 | 按需扩，比如只扩定价计算服务 |
| 故障隔离 | 一个模块挂了，整个系统挂 | 一个服务挂了，不影响其他服务 |
| 团队规模 | 适合 5 人以下 | 适合 10 人以上 |
我的建议是：先单体，后拆分。一开始用单体快速验证业务，等流量上来了，再把定价计算、缓存、日志这些热点模块拆成独立的微服务。别一上来就搞分布式，否则你连问题出在哪都找不到。
避坑指南：我曾经在一个项目中，为了「微服务而微服务」，把报价引擎拆成了 12 个服务。结果每次联调都要启动 12 个容器，开发效率直接腰斩。后来我们合并成 4 个核心服务，反而跑得更顺了。
架构选型决策树
为了帮你快速决策，我画了一张流程图。你可以根据团队规模和业务复杂度，找到最适合的路径。
重要提醒：架构选型没有银弹。我见过用单体架构支撑 5000 QPS 的案例，也见过微服务架构连 500 QPS 都跑不稳的。关键不在于选什么，而在于你清不清楚自己的瓶颈在哪。
小结：先想清楚，再动手
这一章咱们聊了功能需求拆解、非功能需求指标，以及架构选型的权衡。说白了，就是一句话：别为了技术而技术，一切以业务价值为导向。
我个人习惯，每次做架构设计前，都会先问自己三个问题：
- 这个系统最核心的 3 个功能是什么？
- 如果系统挂了，业务能接受多久的恢复时间？
- 团队现在有多少人，未来半年会扩张到多少人？
想清楚这些，架构选型自然就清晰了。