面向大数据/海事运营的实用DevOps

用例描述

Posidonia Operations 是一款高度可定制化的集成港口运营管理系统，它允许港口优化其与港口服务区内船舶流量相关的海事运营活动，整合所有相关利益方和计算机系统。
从技术角度来看，Posidonia Operations 是一个实时、数据密集型平台，能够连接到 AIS（自动识别系统）、VTS（船舶交通管理系统）或雷达，并自动检测船舶运营事件，例如港口到达、泊位、离泊、加燃料操作、拖船操作等。

Posidonia Operations 是一款商业软件解决方案，目前正在跟踪西班牙、意大利、葡萄牙、摩洛哥和突尼斯的航运交通，从而为不同的港口当局和码头提供服务。

创建这个案例研究的目标是采用更结构化的开发策略（DevOps），降低开发/部署成本，并提高软件开发流程的质量。

在用例中，考虑了以下场景：考虑不同参数的Posidonia Operations云部署、支持不同的船舶交通量强度、添加新的业务规则（高CPU需求）、运行模拟场景以评估性能和质量指标。

业务目标

为Posidonia Operations用例确定了三个主要业务目标。

降低部署和运营成本。

Posidonia Operations 提供两种部署和运营模式：本地部署和虚拟私有云部署。本地部署时，使用一种方法和工具来简化部署流程将缩短产品发布时间，从而节省成本和资源。对于虚拟私有云部署，预计对我们当前解决方案进行监控、分析和迭代改进将导致更好的硬件需求规格，最终转化为更低的运营成本。

降低开发成本

Posidonia Operations 被定义为海事运营的“全球本地”解决方案。 “全球本地”是指它提供了一种全球性的海事交通处理和分析解决方案，可以根据本地需求进行配置、定制和集成。此外，该解决方案实时运行，使测试、集成、发布等任务更加关键。通过应用本书中解释的方法，预计这些任务将在开发过程中得到改进，从而缩短开发周期，降低开发成本。

提高服务质量

已经考虑了几个对 Posidonia Operations 用例感兴趣的质量和性能指标。监控、预测分析或确保连续版本之间的可靠性将最终迭代地提高我们当前客户的服务质量。

用例架构

Posidonia Operations 是一个集成的港口运营管理系统。它的任务是实时“全球本地”监控船舶位置，以改进和自动化港口当局的运营。下图显示了 Posidonia Operations 的总体架构。该架构基于独立的 Java 进程，它们通过中间件层相互通信，该中间件层支持消息队列、发布和订阅 API 以及一组主题，用于在组件之间交换数据。

Posidonia Operations 的主要组件概述如下

位于港口服务区内的船舶将包含其位置和其他元数据的 AIS 消息发送到中央站。（这超出了架构图的范围）
AIS 接收器（一个 spout）接收这些消息，并通过流式通道（通常是 TCP 连接）发出这些消息。
AIS 解析器（一个 bolt）连接到流式通道，将 AIS 消息解析为中间件主题并发布到消息队列。
其他组件（bolt）订阅消息队列以接收消息以供进一步处理。例如，复杂事件处理引擎接收 AIS 消息以检测模式并将事件发送到不同的消息队列。
Posidonia Operation 客户端“Web”允许港口员工拥有一个可视化工具，该工具允许他们实时控制船舶的位置。该网站在地图上显示了在港口影响区域内的不同船舶，以及正在进行的操作列表。

用例场景

存在不同的常见场景，其中 Posidonia Operations 开发生命周期可以从本书中解释的知识中受益。这些场景只是可能场景中的一小部分，但它们代表了有趣的情况，并且基于我们目前向港口当局和码头交付数据密集型应用程序的经验。

部署场景

目前，Posidonia Operations 可以通过两种方式部署

本地部署：港口当局提供自己的基础设施，并在 Linux 虚拟机上部署该平台

云部署：Posidonia Operations 也作为 SaaS 为港口码头提供服务。在这种情况下，我们使用 Amazon Virtual Private Cloud (VPC) 部署 Posidonia Operations 的实例，为不同的港口码头提供支持。

除此之外，配置还根据部署环境而异

在每个港口部署 Posidonia Operations 的硬件需求（节点数量、CPU、RAM、磁盘）基于团队经验。对于每次部署，工程师都会手动计算硬件需求，考虑对分析每条消息所应用的船舶数量和规则复杂性的估计。DICE 工具可以帮助自动调整每个部署的适当硬件需求。

Posidonia Operations 的部署和配置由系统管理员和开发人员完成，它会因港口当局而异。虽然部署和配置已记录在案，但 DICE 工具可以帮助采用 DevOps 方法，该方法可以对部署和配置进行建模，以便不仅让不同的利益相关者更好地了解系统，还可以自动化一些任务。

DevOps 方法还有助于提供测试和模拟环境，从而改善我们的开发生命周期。

支持给定港口的船舶交通量增加

Posidonia Operations 的核心功能基于分析表示船舶位置的实时消息流，以检测和发出在现实世界中发生的事件（泊位、锚地、加燃料等）。
不同的因素会导致港口的海事交通量增加（或减少），即

天气状况
一天中的时间
一年中的季节
当前港口占用率
等等

这意味着要分析的每秒消息数量是可变的，如果系统无法按到达顺序处理流式数据，则会影响事件检测的性能和可靠性。如果无法做到这一点，消息将被排队，这种情况必须避免。
我们目前有工具可以提高流式数据的速度，以验证系统在测试环境中的行为。但是，验证和调整系统以应对交通量增加的过程繁琐且耗时，DICE 工具可以帮助改进我们当前的解决方案。

为不同港口添加新的业务规则（CEP 规则）

流数据的分析由复杂事件处理引擎完成。该引擎可以被认为是“模式匹配器”。对于到达的每个船舶位置，它计算不同的条件，当这些条件满足时会产生一个事件。
应用于每条消息的规则数量（计算）会影响系统的整体性能。实际上，规则的数量和实现方式因部署而异。
DICE 工具可以帮助进行不同的质量和性能指标、模拟和预测分析、优化等，以便调整我们的当前解决方案。

在 Posidonia Operations 的云实例中为另一个港口提供支持

在 Posidonia Operations 的云实例中为另一个港口（或码头）提供支持通常意味着

提高流速（每秒更多消息）
增加计算量（每秒执行更多 CEP 规则）
部署和配置新的工件和/或节点

在这种情况下，DICE 工具还可以帮助 Posidonia Operations 估算在云实例中引入新港口的货币成本。

运行模拟以验证不同版本之间的性能和质量指标

CEP 规则（业务规则）在 Posidonia Operations 的不同版本之间不断发展。这意味着整个解决方案的性能和质量可能会受到不同版本之间这种情况的影响。一些我们目前（手动）执行的验证示例

性能：CEP 规则的新版本不会对系统引入性能损失
性能：CEP 规则的新版本不会产生队列
可靠性：CEP 规则的新版本提供与先前版本相同的输出（两者都检测到相同的事件）

当前情况的主要问题之一是，性能（系统性能和应用程序提供的数据质量）的测量是手动进行的，获得客观量化非常昂贵。通过使用 DICE 模拟工具，可以预测不同环境配置的性能和可靠性指标，从而确保高质量的版本和无回归。

DICE 工具

DICE 框架由多个工具（DICE 工具）组成：DICE IDE、DICE/UML 配置文件、部署设计（DICER）和部署服务，它们提供了创建和发布 DICE 应用程序的最小工具包。为了验证应用程序的质量，该框架包含涵盖广泛活动的工具，例如模拟、优化、验证、监控、异常检测、跟踪检查、迭代增强、质量测试、配置优化、故障注入和存储库管理。一些工具侧重于设计，而另一些则侧重于运行时。最后，有些工具既有设计方面也有运行时方面，并在生命周期开发过程的多个阶段使用。

一些 DICE 工具已在用例中使用，以实现为用例设定的业务目标。下表总结了在用例中使用的工具及其使用带来的好处。

DICE 工具	对我们用例的益处
DICE IDE	DICE IDE 集成了建议平台的所有工具，并支持 DICE 方法。IDE 是一种基于 Eclipse 的 MDE 集成开发环境工具，设计人员可以使用它创建模型来描述数据密集型应用程序及其底层技术堆栈。DICE IDE 集成了不同工具的执行，以最大程度地减少学习曲线并简化采用。
DICER	DICER 工具允许我们从使用 DICE IDE 创建的 Posidonia 用例 DDSM 生成等效的 TOSCA 蓝图（部署配方）。该蓝图被部署服务用于自动部署 Posidonia 用例。使用此工具，您可以为用例的不同配置获得不同的蓝图。
部署服务	手动部署 Posidonia Operations 非常耗时且成本高昂。部署服务能够在几分钟内在云中部署 Posidonia Operations 用例的配置。最新版本的部署服务在 flexiant Cloud 编排器和 Amazon AWS 上运行。要使用部署服务部署解决方案，需要提供其 TOSCA 蓝图作为输入。该蓝图是使用 DICER 工具获得的。使用部署服务，部署速度更快（仅需几分钟），您可以部署解决方案的不同配置，并且不需要系统管理员专家，因为部署是自动化的。
监控平台	该工具允许我们获取正在运行的 Posidonia Operations 实例的实时指标：通用硬件性能指标（CPU 和内存消耗、磁盘使用情况等）和特定用例指标，例如检测到的事件数量、事件位置、每个规则的执行时间、每秒消息数等。监控平台提供的报告结果允许架构师和开发人员最终更新 DDSM 和/或 DPIM 模型以实现更好的性能。另一个有趣的地方是监控工具促进了与异常检测工具和跟踪检查工具的集成，因为这两个工具都使用存储在监控中的信息作为数据输入。
故障注入	DICE 故障注入工具 (FIT) 用于在虚拟机中生成故障。在 Posidonia 用例中，此工具有助于检查 CEP 组件在高 CPU 负载下的行为。为了观察系统的行为，我们使用包含系统负载的特定可视化的监控工具。虽然故障注入工具可以启动其他类型的故障，但对于 Posidonia 用例，只有高 CPU 故障与评估系统对此情况的响应相关。重要的是验证系统在高负载发生时继续工作且没有事件丢失。
异常检测	异常检测工具允许我们验证系统在当前规则以及添加新规则的情况下按预期工作。也就是说，没有事件丢失，没有给出误报，执行时间保持在合理范围内，或者检测到的事件顺序是足够的。
模拟工具	如果系统规模不足，特定港口的船舶流量增加会直接影响 Posidonia Operations 的性能。我们已经使用模拟工具和监控工具来定义系统的尺寸并在实时监控它。流数据的分析由复杂事件处理引擎完成。该引擎可以被认为是“模式匹配器”，对于到达的每个船舶位置，它计算不同的条件，当这些条件满足时会产生一个事件。应用于每条消息的规则数量（计算）会影响系统的整体性能。实际上，规则的数量和实现方式因部署而异。最近几个月，在提高用例的质量和验证方面付出了巨大的努力。

结论

我们断言，DICE 方法和 DICE 框架在海事运营用例中非常有用。它在开发用例时提高了生产力。将 DICE 工具应用于用例获得的结果可以概括为

评估软件或条件更改后的性能影响。我们可以在设计时预测软件更改（规则数量、CEP 数量）和/或条件（输入消息速率“模拟工具”、CPU 过载“故障注入工具”）的影响。此外，可以使用异常检测工具检测瓶颈和异常。
提高系统质量。我们可以使用异常检测工具检测瞬时性能问题，并可以检测 CEP 组件中的错误。检测丢失规则和错误规则检测以及与事件发生时的实时相比，规则检测的延迟。
自动提取相关 KPI。轻松计算应用程序执行指标（通用硬件指标，如 CPU、内存消耗、磁盘访问等）以及轻松计算与规则计算成本、每秒处理的消息数量、地图上的事件位置、应用程序性能量化相关的特定于应用程序的指标（以 CEP 正确检测到的港口事件百分比表示）等。
部署自动化。更快的部署速度以及在不同云提供商中部署的可能性。