2025-11-14T05:07:10.818918

MLOps with Microservices: A Case Study on the Maritime Domain

Ferreira, Trapmann, Heuvel
This case study describes challenges and lessons learned on building Ocean Guard: a Machine Learning-Enabled System (MLES) for anomaly detection in the maritime domain. First, the paper presents the system's specification, and architecture. Ocean Guard was designed with a microservices' architecture to enable multiple teams to work on the project in parallel. Then, the paper discusses how the developers adapted contract-based design to MLOps for achieving that goal. As a MLES, Ocean Guard employs code, model, and data contracts to establish guidelines between its services. This case study hopes to inspire software engineers, machine learning engineers, and data scientists to leverage similar approaches for their systems.
academic

MLOps with Microservices: A Case Study on the Maritime Domain

基本信息

  • 论文ID: 2506.06202
  • 标题: MLOps with Microservices: A Case Study on the Maritime Domain
  • 作者: Renato Cordeiro Ferreira, Rowanne Trapmann, Willem-Jan van den Heuvel
  • 机构: Jheronimus Academy of Data Science (JADS), Eindhoven University of Technology (TUe), Tilburg University (TiU)
  • 分类: cs.SE cs.AI cs.LG
  • 发表时间: arXiv:2506.06202v2 cs.SE 11 Aug 2025
  • 论文链接: https://arxiv.org/abs/2506.06202

摘要

本案例研究描述了构建Ocean Guard系统的挑战和经验教训：这是一个用于海事领域异常检测的机器学习使能系统(MLES)。论文首先介绍了系统规范和架构。Ocean Guard采用微服务架构设计，使多个团队能够并行工作。然后讨论了开发者如何将基于合同的设计适应MLOps以实现这一目标。作为MLES，Ocean Guard采用代码、模型和数据合同来建立服务间的指导原则。

研究背景与动机

问题背景

  1. 海事数字化转型加速：根据国际海事组织(IMO)，现代船舶已成为"浮动数据中心"，配备数百个传感器，产生大量异构数据
  2. 复杂的运营环境：海事领域具有跨国界持续移动、多样化监管框架、易受天气影响等特点
  3. 数据处理挑战：需要系统能够大规模摄取、处理和分析不同数据流，同时在连接性和条件快速变化的环境中保持运营可靠性

研究动机

  1. 技术融合需求：将MLOps最佳实践与微服务架构结合，应对海事领域的预测分析、异常检测和路线优化需求
  2. 多团队协作：需要支持软件工程师、数据科学家和机器学习工程师等多专业团队并行开发
  3. 系统可扩展性：微服务架构特别适合海事领域的模块化、可扩展性和弹性需求

核心贡献

  1. 提出了适用于MLES的合同驱动设计方法：将微服务中的代码合同概念扩展到数据合同和模型合同
  2. 构建了完整的海事异常检测系统架构：基于微服务的Ocean Guard系统，支持多团队并行开发
  3. 验证了DDD在MLOps中的应用：通过领域驱动设计创建统一语言，改善跨专业团队沟通
  4. 提供了MLES开发的实践经验：识别并解决了耦合、对齐和沟通三大挑战

方法详解

系统规范

功能需求

调查员(Investigator)功能：

  • I1-I6：地理位置显示、过滤、对象类型识别、多数据源检索、元数据查看、轨迹追踪
  • I7-I9：异常高亮显示、异常过滤、异常解释查看

异常检测器(Anomaly Detector)功能：

  • A1-A3：异常检测、异常列举、异常解释

非功能需求

  1. 可解释性：使用可解释模型或黑盒解释技术(SHAP、LIME)
  2. 兼容性：遵循EU标准，支持与其他系统快速集成
  3. 弹性：处理高容量、高速度数据源
  4. 合规性：符合GDPR和AI Act等欧洲法规

系统架构

五大子系统设计

  1. 数据获取(Data Acquisition)
    • 第三方提供商(1)、物理传感器(2)、数据爬虫(3)
    • 标签存储(A)和原始数据存储(B)
  2. 持续训练(Continuous Training)
    • 合成数据生成管道(I)、数据增强管道(II)
    • 基于规则的训练管道(III)、基于ML的训练管道(IV)
    • 元数据存储(F)和模型注册表(G)
  3. 服务(Serving)
    • 批量预测管道(VIII)和API预测服务(8)
    • 预测存储(H)
  4. 监控(Monitoring)
    • 治理应用(7)和遥测存储(I)
  5. 持续交付(Continuous Delivery)
    • CI管道(V)、CD管道(VI)、CD4ML管道(VII)
    • 工件注册表(D)

API架构设计

采用六边形架构(Hexagonal Architecture)：

  1. 核心(Core)：实现业务逻辑，遵循DDD模式
    • 实体(Entities)、值对象(Value Objects)
    • 聚合(Aggregates)、服务(Services)
  2. 端口(Ports)：建立核心与适配器间的合同
    • 数据库仓库、依赖注入、安全机制、Web路由器
  3. 适配器(Adapters)：与外部依赖通信
    • 读取适配器：模型、第三方API、存储、数据库、配置
    • 输出适配器：Web、缓存

团队配置与工作流

团队职责组件
研究团队前沿技术探索实验和训练管道
创新团队实践技术探索实验和训练管道
核心开发团队后端开发和基础设施API、数据库、模型仓库
UI开发团队前端开发和界面设计Web应用

技术创新点

合同驱动开发(Contract-Based Development)

1. 代码合同(Code Contracts)

  • 定义：文档化两个服务间通过HTTP协议的同步/异步交互行为
  • 应用场景：
    • 数据爬虫与外部数据源间的合同
    • API预测服务与Web应用间的合同

2. 数据合同(Data Contracts)

  • 定义：文档化数据存储中的预期格式，包括类型、格式、分布和读写协议
  • 应用场景：
    • 标签存储的生产者与消费者间合同
    • 原始数据存储的多方合同
    • 处理后数据的管道间合同

3. 模型合同(Model Contracts)

  • 定义：文档化模型的预期输入输出及存储格式
  • 应用场景：模型注册表中训练管道与预测服务间的合同

统一语言(Ubiquitous Language)

通过DDD创建跨团队共享词汇，改善：

  • 利益相关者与开发者理解
  • 团队间对齐
  • 数据和模型概念解释

实验设置

开发环境

  • 代码仓库：集中式源码管理
  • 开发工具：IDE(4)用于结构化软件工程，Notebooks(5)用于交互式原型和分析
  • CI/CD：持续集成管道、持续交付管道、ML持续交付管道

部署架构

  • 容器化：使用工件注册表管理版本化软件组件
  • 调度服务：协调各组件执行
  • 监控系统：治理应用监控模型和系统使用

挑战与解决方案

三大挑战

  1. 耦合(Coupling)
    • 问题：系统复杂性导致组件修改容易级联影响
    • 解决：通过合同驱动设计减少集成问题
  2. 对齐(Alignment)
    • 问题：四个专业团队并行工作的协调挑战
    • 解决：明确边界定义，CI/CD管道集成
  3. 沟通(Communication)
    • 问题：向不同技术背景的利益相关者解释系统演进
    • 解决：通过DDD建立统一语言

解决方案效果

技术方法解决的挑战具体效果
合同驱动设计耦合 + 对齐减少集成问题，改善系统内聚性
统一语言沟通 + 对齐深化理解，改善反馈质量

相关工作

MLOps领域发展

  • 2022年起：多个MLES参考架构被提出
  • SE4AI：软件工程技术适应AI系统创建的新兴领域
  • 系统组件化：MLES被描述为包含多个可跨服务分布的组件

微服务架构

  • 2015年起：微服务架构风格兴起，解决模块化、可扩展性和弹性挑战
  • 海事适用性：专业组件处理不同海事数据源和分析需求

结论与讨论

主要结论

  1. 架构有效性：微服务架构成功支持了多专业团队并行开发MLES
  2. 合同扩展：将微服务的代码合同概念成功扩展到数据和模型维度
  3. DDD适用性：领域驱动设计有效改善了跨专业团队的沟通和协调
  4. 挑战应对：合同驱动设计和统一语言有效解决了耦合、对齐和沟通挑战

局限性

  1. 敏感性限制：由于项目敏感性，论文未涉及具体的数据模型和异常检测技术
  2. 学术约束：研究和创新团队由学生组成，受学术截止日期限制
  3. 实施阶段：系统仍在开发中，缺乏生产环境的长期验证

未来方向

  1. 功能完善：继续开发以满足所有功能和非功能需求
  2. 技术探索：与研究和创新团队继续探索前沿和实践技术
  3. 架构演进：基于既定的合同方法和统一语言指导开发过程

深度评价

优点

  1. 实践价值高：提供了MLOps与微服务结合的完整案例研究
  2. 方法创新：将合同驱动设计扩展到数据和模型维度具有原创性
  3. 架构完整：系统架构设计全面，涵盖了MLES的各个方面
  4. 团队协作：成功解决了多专业团队并行开发的挑战
  5. 实用指导：为类似项目提供了可借鉴的经验和教训

不足

  1. 技术深度有限：由于敏感性限制，缺乏具体的ML算法和数据处理细节
  2. 评估不足：缺乏系统性能、可扩展性等定量评估
  3. 长期验证缺失：系统尚未在生产环境中长期运行验证
  4. 比较分析不足：缺乏与其他MLES架构方案的对比分析

影响力

  1. 领域贡献：为MLOps和微服务结合提供了重要的实践参考
  2. 方法论价值：合同驱动设计的扩展具有广泛适用性
  3. 工程实践：为复杂MLES的团队协作提供了有效模式
  4. 可复现性：架构设计和方法论具有良好的可复现性

适用场景

  1. 多团队MLES开发：需要多个专业团队并行开发的机器学习系统
  2. 复杂数据处理：涉及多源异构数据的系统架构设计
  3. 高合规要求：需要满足严格监管要求的行业应用
  4. 可扩展系统：需要高度模块化和可扩展的ML系统架构

参考文献

论文引用了17篇重要文献，涵盖：

  • 海事数字化转型相关研究
  • 微服务架构和MLOps最佳实践
  • 软件工程方法论(DDD、六边形架构)
  • 机器学习系统工程(SE4AI)

总结：本论文通过Ocean Guard案例研究，成功展示了微服务架构在MLOps中的应用，特别是合同驱动设计在多团队协作中的价值。虽然受敏感性限制未能深入技术细节，但其方法论贡献和实践指导价值显著，为类似复杂MLES项目提供了宝贵的架构设计和团队协作经验。