面向大資料/海事運營的實用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 通用架構

Posidonia Operations 的主要元件概述如下

• 位於港口服務區內的船舶將包含其位置和其他元資料的 AIS 訊息傳送到中央站。（這超出了架構圖的範圍）
• AIS 接收器（一個 spout）接收這些訊息，並透過流式通道（通常是 TCP 連線）發出這些訊息。
• AIS 解析器（一個 bolt）連線到流式通道，將 AIS 訊息解析為中介軟體主題併發布到訊息佇列。
• 其他元件（bolt）訂閱訊息佇列以接收訊息以供進一步處理。例如，複雜事件處理引擎接收 AIS 訊息以檢測模式並將事件傳送到不同的訊息佇列。
• Posidonia Operation 客戶端“Web”允許港口員工擁有一個視覺化工具，該工具允許他們即時控制船舶的位置。該網站在地圖上顯示了在港口影響區域內的不同船舶，以及正在進行的操作列表。

圖：Posidonia Operations 網路客戶端

用例場景

存在不同的常見場景，其中 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 正確檢測到的港口事件百分比表示）等。
• 部署自動化。更快的部署速度以及在不同雲提供商中部署的可能性。