搜题服务为什么用 Fastify，而没有全部用 Python？

标准回答

这个项目把数据采集和在线查询分成了两条链路。Python 和 Scrapy 负责采集、离线处理与更新，Fastify 负责对外 API 和搜索编排，Elasticsearch 承担全文检索。

这套组合的合理性在于职责匹配。采集侧需要处理抓取和数据清洗，Python 的相关生态比较适合；在线 API 则主要接收请求、调用搜索与缓存并组织返回。检索成本更多由查询、索引和数据规模决定，不能只看 Web 框架名称。

因此我不会用“Node 一定比 Python 并发高”解释选型，也没有项目内同条件压测证明 Fastify 必然更快。在线服务等待 Elasticsearch 时可以利用异步 IO，但 CPU 密集的清洗和大规模文本处理，仍然不适合堵在请求处理的事件循环里。

分开技术栈带来了部署、日志和接口维护成本。如果两个环节的差异不大，统一语言可能更划算。我的项目可以说明这套职责组合能够支撑产品运行，但要证明它优于所有替代方案，还需要具体瓶颈和成本数据。

查询服务等待 Elasticsearch 时，可以使用异步请求；大规模清洗或耗时文本处理应在合适的后台链路完成，不应阻塞在线事件循环。

统一确实能减少维护成本，尤其是独立开发时。我目前的组合是采集处理与在线搜索分别承担不同职责，Python/Scrapy 与 Fastify 各自服务于对应链路。但这不意味着必须两种语言才能完成。如果重新设计，我会先看现有代码、开发效率和主要瓶颈；没有明显收益时，统一技术栈是合理甚至更好的选择。

我会把大规模清洗、解析等工作放到适合的后台处理进程或任务链中，限制并发并控制积压，避免占满在线服务资源。async 只能帮助组织异步等待，不能把 CPU 运算变成无成本。具体是否需要独立服务取决于规模，但在线请求的关键路径应尽量保持短且可预测。

不要回答“Node 一定比 Python 高并发”“Fastify 自动解决高并发”。未实测的性能比较不能作为项目结论。