云原生技术、平台工程和AI的当前趋势

NGINX | 2025年10月13日

Karthik Krishnaswamy产品营销总监 | F5

我们对技术及其运作方式的理解正在多个方面发生根本性转变。为了解各组织如何应对这些变化，F5与专注于技术领域的知名市场研究公司SlashData合作，对来自全球不同地区和多个行业的数百名IT、安全和软件开发领域的负责人及从业人员开展了调查。

参与者包括NGINX开源项目、NGINX Open Source和F5 NGINX商业产品的用户。调研结果印证了相关组织的紧迫感：他们希望立即在容器化、安全、开发者平台和AI方面做出改变。以下是《2025年NGINX年度调查》的主要发现。

新兴趋势：智能体驱动的非CPU未来

F5 NGINX已成为AI基础设施广泛采用的默认入口。领先的AI硬件和软件提供商将其作为AI应用的主要或推荐反向代理和交付控制器。调查结果显示，NGINX用户乃至更广泛的应用交付社区正积极迈向AI驱动的未来。

图 1：F5 2025 年 NGINX 年度调查的大多数受访者目前正在使用或试用智能体 AI 任务，或有兴趣在未来使用此类任务。

图 1：F5 2025 NGINX 年度调查的大多数受访者目前正在使用或试用智能体 AI 任务，或有兴趣在未来使用此类任务。

AI智能体的使用：在被问及智能体AI任务的使用情况时（见图1），受访者表示，“配置NGINX”目前的采用率较高，为25%；紧随其后的是“网络流量优化和负载均衡”，采用率为24%。目前，23%的受访者正在使用“基础设施部署和扩展”以及“安全漏洞修复”。

综合参与度：综合统计目前正在使用和试用智能体AI的受访者反馈后，“日志分析和主动故障排除”以48%的比例居首。“配置NGINX”和“基础设施部署与扩展”均为46%，并列其后；“网络流量优化”为45%。

未来最感兴趣的领域：“配置漂移检测与纠正”最受关注，占33%；其次是“监控NGINX部署”，占32%；“事件告警与分诊”占31%。

图 2：60%的受访者表示使用虚拟机运行应用工作负载，29%使用平台即服务，25%使用GPU等专用硬件。

专用硬件：25%的受访者在GPU、TPU或FPGA上运行工作负载。对于传统上侧重通用计算的基础设施而言，这一比例值得关注（见图2）。我们预计，这一比例将继续上升，主要推动因素包括小型AI模型不断改进；在Docker和超大规模云服务商等云原生基础设施中运行小型AI模型更加便捷；以及将应用交付流程卸载到专用硬件（例如，将加密和SSL处理卸载到NPU和FPGA，并将AI推理部署到GPU和TPU等）。

主要障碍：调查受访者将安全问题（26%）和对准确性缺乏信任（24%）列为AI集成的主要障碍。集成复杂性、合规及监管限制，以及对智能体能力了解有限，所占比例均为17%。

云原生已无处不在，但仍在不断完善

云原生变革始于容器和Kubernetes。十多年过去了，这一趋势仍在加速发展。对于云原生的关键要素，即使采用已近乎普及，距离全面渗透仍有很长的路要走（见图3）。

图3：F5 2025 NGINX年度调查发现，本地服务器仍占应用部署的大多数，公有云和混合云紧随其后。

具体而言，我们的调查发现：

多环境现实已真正到来：66%的组织至少使用一种云选项，但本地部署仍以39%的占比位居各部署位置之首，公有云和混合部署的占比分别为38%和36%。这反映出现代基础设施复杂且分布式的特性，而非简单的“云迁移”叙事。
容器采用率仍有提升空间：仅42%的受访者在容器上运行工作负载，微服务采用率仅为31%。虚拟机以60%的占比居于主导地位，这表明许多组织仍处于云原生转型的早期阶段。
Kubernetes呈碎片化格局：自主管理的Kubernetes在容器编排中的采用率为24%，占比居前；Red Hat OpenShift的自主管理和完全托管模式合计占21%；Amazon Web Services（21%）、Microsoft Azure（17%）和Google Cloud Platform（17%）的托管服务也获得了广泛采用。

API和微服务安全管理存在巨大差距

过去十年间，许多技术组织已开始采用API，将其作为连接内部和外部运营的核心机制。在云原生架构中，API优先是一项核心设计原则。相应地，86%的受访者部署了API网关来管理其API基础设施（见图4）。

图4：86%的调查受访者使用由内部API和外部API共同组成的API组合。

尽管API已得到广泛采用，API网关也已普遍部署，但大多数组织的API安全实践仍不成熟（见图5）。虽然86%的组织使用API，但只有34%实施了API安全措施。这使现代应用基础设施面临巨大的风险敞口。

关注API流量分析（43%）和可观测性（38%）的受访者均不足半数，而这两项也是API安全的核心要素。这一差距可能表明，组织在全面观测和管理API方面面临挑战。事实上，23%的受访者表示，不同团队采用不同的API管理方法。这种碎片化现象可能源于难以推动整个组织遵循经典的API管理“黄金路径”。

图5：仅34%的受访者已实施API安全措施，43%的受访者会分析API流量，35%的受访者能够跟踪和观测其API。

平台工程虽已取得进展，但仍不成熟

平台工程已不再只是一个流行词，而是进入了主流。事实上，65%的受访者已开始落实平台工程能力和职责（见图6）。这些受访者既包括设有专门平台团队的大型组织，也包括仅由一名团队成员担任平台工程负责人的组织。约27%的组织设有小型专职平台工程团队，21%的组织在开发或运维团队中设有单独的平台工程岗位，另有13%的组织设有大型专职平台工程团队。显然，平台工程的价值主张已得到广泛传播和认可。

图6：随着平台工程角色的价值日益得到认可，65%的受访者已实施平台工程。

尽管如此，无论团队规模大小，关于平台挑战的调查结果都显示，各组织在早期阶段面临诸多困难。仅20%的受访者表示没有遇到重大挑战。其余受访者表示，各类平台工程挑战正对其组织产生实际影响，包括安全与合规问题（18%）、文档维护（16%）、技术更新（16%）以及资源限制（14%）。

调查确实发现，规模较大和较小的团队在服务交付和价值主张的优先事项上存在明显差异。不出所料，较大团队专注于更复杂的领域，而较小团队的关注重点则与传统DevOps相似。大型专职平台工程团队更有可能提供复杂的服务，例如数据库即服务（54%）、可观测性（52%）、API管理（51%）、防火墙配置与管理（54%），以及CI/CD流水线工具（50%）。