《Journal of Cybersecurity and Privacy》：Embedded ONNX Versus Python Sidecar Inference for Anomaly-Aware Availability Response in Spring Boot Microservices: An Architectural Evaluation
编辑推荐：
可用性导向监控（Availability-oriented monitoring）可能需要低延迟异常推理（low-latency anomaly inference），但将轻量级模型（lightweight model）作为单独服务部署会增加进程、序列化和网络
可用性导向监控（Availability-oriented monitoring）可能需要低延迟异常推理（low-latency anomaly inference），但将轻量级模型（lightweight model）作为单独服务部署会增加进程、序列化和网络路径开销（network-path overhead）。本文评估了原型可用性响应循环（availability-response loop）所使用的推理路径架构；它不评估新型DoS/EDoS检测器的有效性，也不声称生产级攻击缓解。相同的伊索林森林模型（IsolationForest model）和遥测向量（telemetry vectors）通过外部Python/FastAPI sidecar以及嵌入在Spring Boot JVM中的ONNX运行时（ONNX Runtime）执行。原型还包括一个长短期记忆自动编码器（LSTM Autoencoder）和一个有界规则层（bounded rule layer），产生SCALE_UP、RETRY、FALLBACK或NONE。主要的Kubernetes基准测试（Kubernetes benchmark）使用Docker Desktop 4.73.1（Docker Engine 29.4.3）和Kubernetes v1.34.3在单节点集群上。嵌入式ONNX将平均请求-响应延迟（request-response latency）从26.090 ms降低到4.839 ms，P95从62.065 ms降低到5.367 ms，P99从76.487 ms降低到6.244 ms；计算出的顺序吞吐量（throughput）从38.3请求/秒增加到206.7请求/秒。附加检查涵盖了并发负载（concurrent load）、gRPC传输（gRPC transport）、冷启动（cold start）、内存占用（memory footprint）和有限的Kubernetes动作。在扩展比较中，使用每个活动配置进行15次950秒的运行，基于CPU的HPA（CPU-based HPA）、仅规则（rules-only）和AI+规则（AI+rules）产生了重叠的聚合SLA违规率（SLA-violation rates）；在测试的退化代理（degradation proxies）下，未观察到ML门控（ML gate）相对于仅规则的聚合优势。证据支持一个狭窄的架构结论：对于测试的轻量级模型，进程内ONNX（in-process ONNX）是更低延迟和更低占用空间的执行路径。检测质量（Detection quality）、相对于仅规则或已建立的自动扩缩机制的优越性，以及对真实对抗流量的有效性，仍然是开放的验证任务。
**论文解读：嵌入式ONNX与Python Sidecar推理在Spring Boot微服务中的架构评估**
**研究背景与问题**
在微服务架构中，Kubernetes（容器编排平台）的内置自动扩缩机制（如水平Pod自动扩缩器HPA）主要基于已观测资源状态（如CPU、内存）做出反应，无法预测未来故障。微服务失败往往始于延迟增加、错误率上升等渐变过程，而非即时崩溃。从安全视角看，服务弹性依赖可用性（Availability），而自动扩缩可能被操纵（如Yo-Yo攻击），导致经济拒绝可持续性（EDoS）效应。因此，低延迟异常监控与有界响应成为关键需求。然而，业务逻辑与可观测性常驻于Spring Boot（Java框架），而机器学习模型通常在Python中训练，并通过独立REST服务部署，这引入了额外的部署单元、API契约和故障域。ONNX运行时（ONNX Runtime）Java API提供了进程内推理替代方案，但缺乏受控的、同模型比较来量化Python/FastAPI sidecar与嵌入Spring Boot JVM的ONNX Runtime之间的架构成本。为此，研究人员开展了这项原型级架构评估，论文发表在《Journal of Cybersecurity and Privacy》。
**研究内容与结论**
研究人员构建了一个原型可用性响应循环，使用相同的伊索林森林模型（IsolationForest）和长短期记忆自动编码器（LSTM Autoencoder），通过两种推理路径执行：外部Python/FastAPI sidecar（同一Pod内localhost调用）和嵌入Spring Boot JVM的ONNX Runtime。在Kubernetes单节点集群上进行基准测试，测量请求-响应延迟、吞吐量、并发负载、gRPC传输、冷启动和内存占用。扩展比较中，在kind三节点集群上注入操作退化代理（延迟尖峰、错误率增加、资源耗尽、依赖失败），对比基于CPU的HPA、仅规则和AI+规则三种配置的聚合SLA违规率。结论：嵌入式ONNX显著降低了延迟和占用空间，但ML门控（ML gate）未在聚合可用性上优于仅规则或HPA。检测质量和攻击缓解有效性仍为开放任务。
**关键技术方法（不超过250字）**
研究人员使用scikit-learn的IsolationForest（n_estimators=100，contamination=0.05，random_state=42）训练于5000个合成遥测向量（4个float32特征：latency_ms、cpu_usage、error_rate、queue_size，来自均匀分布，经StandardScaler标准化）。模型导出为PKL和ONNX（opset 17）格式，并通过标签和分数校验确保数值一致性。主要比较两种推理路径：Python/FastAPI sidecar（同一Pod内localhost调用，使用uvicorn服务器）和嵌入Spring Boot JVM的ONNX Runtime（Java API）。Kubernetes环境：Docker Desktop 4.73.1（Docker Engine 29.4.3）、Kubernetes v1.34.3单节点集群。测试机器：Windows 11，AMD Ryzen 7 7700（8核/16线程），32 GB RAM。负载生成：同步单线程Python httpx客户端。主要基准：2000次顺序请求（10轮×200），记录端到端延迟，计算均值、P50、P95、P99和顺序吞吐量。附加测试：8并发客户端×500请求、gRPC本地协议、冷启动时间和内存占用。扩展多节点实验：kind集群三节点，注入故障窗（共6个，含延迟、错误、资源、依赖场景），比较CPU-based HPA（averageUtilization=80%，1-5副本）、仅规则、AI+规则，各15次950秒运行。注意：样本均为合成数据，无真实队列来源。
**研究结果**
**3.3. Kubernetes Latency Evaluation: REST Python Sidecar vs. ONNX JVM Embedded**
通过Kubernetes基准测试，对2000个顺序请求测量延迟。嵌入式ONNX平均延迟4.839 ms，P95为5.367 ms，P99为6.244 ms；而REST sidecar平均26.090 ms，P95为62.065 ms，P99为76.487 ms。顺序吞吐量从38.3请求/秒提升至206.7请求/秒。Mann-Whitney U检验显示显著差异（p<0.001），Cliff's δ=0.993，表明约99.7%的REST延迟超过ONNX延迟。嵌入式ONNX在尾延迟和稳定性上优势明显。
**3.4. Real-Time Anomaly Detection**
基于12节JVM指标（进程CPU、堆使用、线程数、请求延迟），每5秒收集一次，共72周期。注入50个顺序HTTP请求后，模型检测到延迟尖峰（526 ms），规则层产生SCALE_UP决策。但7次异常检测中，5次对应无害低延迟（1-7 ms），表明模型本身无法区分统计异常与操作风险，规则层起到了过滤作用。
**3.5. Descriptive Ablation of the Detector and Rule Layer**
对72周期轨迹进行消融分析：仅检测器（Detector only）将7个异常视为候选；仅规则（Rules only）应用阈值（如延迟>200 ms触发SCALE_UP）；组合（Combined）为原设计。结果显示，组合设计未在操作质量上优于仅规则，未见ML门控带来的决策改进。
**3.6. Repeated LSTM Autoencoder Experiments: Reproducibility Analysis**
对LSTM Autoencoder进行6次独立运行，每次稳定后注入50个请求，监测恢复时间。平均峰值MSE为0.000261（标准差0.000013），恢复周期为7.5个（标准差0.8）。运行间变异性有限，表明序列感知方法对短负载事件可重复反应，但未证明模型普适性。
**3.7. Detect–Decide–Scale Action Path**
通过63次独立运行，提交异常指标（延迟526 ms，CPU 85%，错误率0.01，队列大小80），验证完整检测-决策-扩缩路径。ONNX推理平均2 ms，全周期从请求到第二副本就绪平均5071 ms（P95=6104 ms），所有运行成功，证实技术可行性。
**3.8. Policy-Level Decision Semantics: An Illustrative, Non-Competitive HPA Comparison**
通过三个场景（A、B、C）对比原型决策层与CPU阈值HPA（averageUtilization=80%）。场景A：两者均触发SCALE_UP；场景B：HPA无反应，原型返回FALLBACK；场景C：HPA无反应，原型返回RETRY。表明原型可表达错误导向动作（如RETRY、FALLBACK），超出HPA语义，但非竞争性基准。
**3.9. Multi-Node Kubernetes Evaluation Under Controlled Availability-Degradation Proxies**
在kind三节点集群上，每活动配置进行15次950秒运行，注入6个故障窗（延迟、错误、资源耗尽、依赖失败）。AI+规则配置下，总请求34008个，P50=68.8 ms，P95=1298.6 ms，P99=2089.7 ms，平均SLA违规率40.7%。响应模式因故障类型而异：延迟窗以SCALE_UP为主，错误和资源耗尽窗以FALLBACK为主。与CPU-based HPA（39.4%违规率）和仅规则（37.1%违规率）相比，聚合SLA违规率重叠，无证据表明ML门控改善可用性。
**讨论与结论**
**讨论部分总结**：实验表明，对于同一轻量级IsolationForest模型，嵌入式ONNX相比REST sidecar显著降低推理路径延迟和部署占用空间。47个自动化测试验证了集成与回退行为，有限实验证明路径可连接至确定性决策和Kubernetes API动作。然而，决策质量证据薄弱：7次运行时异常判决中5次为无害低延迟，消融分析未发现组合设计优于仅规则；扩展多节点实验中，AI+规则的聚合SLA违规率与HPA和仅规则重叠，未体现ML门控优势。因此，研究贡献在于架构证据，而非检测器或编排优越性。有效性威胁包括单节点基准、非均衡资源预算、合成数据、缺乏真实对抗流量等。实践意义：对于轻量级模型，嵌入推理降低尾延迟并简化运维，但需权衡耦合、故障隔离和资源争用。生产使用需模式验证、推理截止时间、完整性检查模型版本和有界降级模式。
**研究结论部分翻译**：本文报告了一项狭窄的架构评估，而不是一个新的DoS/EDoS检测器或生产级可用性保护系统。它比较了通过Python/FastAPI sidecar和嵌入Spring Boot JVM的ONNX Runtime执行的相同轻量级异常模型，同时将两条路径连接到相同的有界响应逻辑。在主要的Kubernetes基准测试中，嵌入式ONNX将平均请求-响应延迟从26.090 ms降低到4.839 ms，P95从62.065 ms降低到5.367 ms，P99从76.487 ms降低到6.244 ms；计算出的顺序吞吐量从38.3请求/秒增加到206.7请求/秒。附加的环境特定实验发现嵌入式变体具有更高的并发吞吐量、更短的冷启动时间和更低的总内存占用。本地REST/gRPC实验是一个独立配置，仅支持运行内协议比较。次要实验确立了技术可行性，但未证明决策优越性。原型完成了63次受控的检测-决策-扩缩运行，扩展的多节点kind实验（每个活动配置15次950秒运行）在操作退化代理下产生了闭环信号，并在延迟、错误和资源导向的故障中表现出差异化响应。第3.8节中的三场景HPA比较是语义性的，而第3.9节中的扩展实验提供了HPA、仅规则和AI+规则在同一调度下的描述性定量比较。无论是短描述性消融还是扩展比较，均未证明ML门控的聚合结果优势。因此，本文不声称精度、召回率、攻击缓解、生产级自动扩缩稳定性或优于HPA、KEDA、Prometheus规则或服务网格机制。嵌入消除了进程和网络边界，但增加了进程内耦合以及模型崩溃、畸形输入、受损工件和JVM资源争用的影响。因此，生产使用需要模式验证、推理截止时间、完整性检查的模型版本、有界执行器、监控、回滚和确定性规则仅降级模式。贡献是关于一个架构变量（推理位置）的测量证据。下一步需要更大的本地Linux多节点研究，比较相等的资源预算、同Pod和远程模型服务、仅规则和AI+规则以及已建立的控制器，在标记的持续工作负载和真实攻击轨迹上进行。只有这样的证据才能支持关于编排或安全有效性的声明。
