部署架构的“场景适配”：我们为什么在部分核心服务中选择了物理机？

2026年初，在优化立达标讯政策数据推理服务时，团队内部展开了一场关于“部署架构”的讨论。

一方认为：“必须用Docker！环境一致！弹性伸缩！云原生趋势！”
另一方提出：“我们的部分服务是计算密集型、对性能极度敏感的场景，是否可以考虑物理机部署？”

这不是一场“谁替代谁”的争论，而是一次关于场景适配的技术探讨。最终，我们在部分核心服务中采用了物理机部署的方案。半年后，回顾这个决定，我们对其适用边界有了更清晰的认识。

两种方案的场景分析

Docker的典型适用场景

• 需要环境一致性，避免“在我机器上能跑”问题。

• 需要弹性伸缩，快速扩缩容。

• 微服务架构，服务数量多，需要统一编排。

物理机的典型适用场景

• 计算密集型服务（如NLP推理、视频转码），对CPU和内存的稳定性要求极高。

• 对网络延迟和I/O性能有极致要求。

• 团队规模小，运维能力有限，希望简化架构。

我们的判断：这不是“二选一”的问题，而是“如何组合”的问题。

我们的实践：混合部署架构

场景一：核心NLP推理服务 → 物理机

我们的核心服务是计算密集型的NLP推理，对CPU和内存的稳定性要求极高。在Docker中，由于CPU限流（Cgroup限制） 和网络Overlay开销，推理延迟波动极大。迁回物理机后，我们获得了100%的CPU独占，P99延迟下降了约40%。

场景二：管理后台与工具服务 → Docker

对于管理后台和内部工具这类服务，我们继续使用Docker。这类场景的特点是：

• 环境一致性要求高。

• 需要快速部署和扩缩容。

• 服务数量多，需要统一编排。

场景三：混合部署 → 物理机 + Docker

对于部分复杂链路，我们采用了混合部署架构：

• 核心计算密集型服务使用物理机，保证性能和稳定性。

• 管理后台和工具服务使用Docker，保证环境一致性和弹性。

• 通过统一的监控和日志系统，实现两边服务的可观测性。

效果量化：混合部署的收益

关键启示：技术选型的本质是场景适配

这次实践让我们深刻认识到：没有“最好”的技术，只有“最合适”的场景适配。

• Docker在环境一致性、弹性伸缩、微服务编排场景下具有不可替代的优势。

• 物理机在计算密集型、性能敏感、架构极简优先的场景下具有显著优势。

• 混合架构可以兼顾两者优势，但需要处理好监控和运维的一致性。

这和我们在立达标讯上处理招标信息的逻辑是一致的：面对每天20万+条的招标信息平台数据，我们不会盲目追求单一技术方案，而是根据数据特征（结构化程度、更新频率、查询模式）选择最合适的处理方式。

在部署架构选型中，你更看重？
A. 环境一致性与弹性伸缩（如Docker），选择“确定性”。
B. 极致性能与架构极简（如物理机），拥抱“专精”。
C. 混合架构，根据场景适配。
欢迎在评论区留下你的选择（A、B或C）和理由。我将根据大家的反馈，在后续文章中分享我们处理混合部署监控和运维的具体实践。