Разработка подсистемы распределенных вычислений для экосистемы научных исследований



В данной статье предметом исследования является проектирования микросервисной архитектуры в подсистемы распределенных вычислений. Эта архитектура представляет собой ключевой компонент, обеспечивающий эффективное выполнение вычислительных задач в распределенных системах.

Распределенные системы, в данном контексте, играют важную роль, позволяя объединить вычислительные ресурсы из различных источников. Эти системы обеспечивают балансировку нагрузки и отказоустойчивость, что необходимо для обработки больших объемов данных и выполнения сложных вычислений.

В микросервисной архитектуре важно соблюдать ACID-свойства (Atomicity, Consistency, Isolation, Durability). Эти свойства гарантируют, что взаимодействие между микросервисами и операции с данными выполняются надежно и согласованно. Это является ключевым аспектом, где целостность данных и точность результатов играют важную роль. Таким образом, сочетание Микросервисной архитектуры, распределенных систем и соблюдение ACID-свойств в подсистеме распределенных вычислений становится фундаментом для успешной и надежной работы системы.

Ключевые слова: распределенные вычисления, ACID, повествование, база данных, модель повествований для подсистемы распределенных вычислений.

Введение. Распределенные вычисления — это способ решения трудозатрат вычислительных задач с использованием нескольких серверов или компьютеров, объединённых в параллельную вычислительную систему.

Задача разработки распределенных систем является одной из наиболее сложных задач, которые стоят перед информатикой и программной инженерией.

Сложность обусловлена не только такими очевидными свойствами, как большие размеры вычислительных машин, возможное географическое удаление серверов друг от друга, ненадежные каналы связи между компьютерами, параллельные процессы, асинхронное взаимодействие, сложные схемы синхронизации, поддержка глобального времени. Сложность обуславливается тем, что на сегодняшний день нет ясной и общепринятой систематизации характеристик функциональности распределенных систем.

Проблемы согласованности данных в распределенных системах могут возникнуть из-за нескольких факторов. Вот некоторые из них:

— Гонки данных (Race Conditions): Если несколько серверов пытаются изменить одни и те же данные одновременно, может возникнуть гонка данных, что приведет к непредсказуемым результатам.

— Потеря данных (Data Loss): Иногда данные могут быть потеряны при передаче между узлами из-за сетевых сбоев или других проблем.

— Дублирование данных (Data Duplication): В некоторых случаях данные могут быть дублированы, что приведет к избыточным или неправильным записям.

— Неопределенность при сбоях (Uncertainty During Failures): При сбоях на серверах может быть непонятно, были ли какие-то операции успешно завершены или нет.

— Отсутствие гарантированного упорядочивания (Lack of Total Ordering): В распределенных системах может быть сложно обеспечить определенный порядок, в котором происходят операции.

— Проблемы с распределенными транзакциями (Distributed Transaction Issues): Необходимо гарантировать целостность, согласованность, изолированность и устойчивость в распределенных транзакциях. Конфликты при репликации данных (Data Replication Conflicts): Если данные реплицируются на несколько серверов, могут возникнуть конфликты при попытке обновления.

— Проблемы синхронизации данных (Data Synchronization Issues): Сервера должны синхронизироваться одновременно иначе они не смогут корректно обновить данные

Решение этих проблем включает в себя использование подходящих алгоритмов синхронизации данных, применение моделей согласованности, таких как ACID или BASE, и правильное проектирование архитектуры распределенной системы.

Модели и методы для обеспечения принципов ACID в распределенных высоконагруженных системах. Распределенные транзакции представляют собой сложные операции, включающие изменения данных, выполняемые в нескольких распределенных компьютерных системах или базах данных. Эти операции становятся важными в контексте распределенных вычислений и управления данными, когда информация и ресурсы разбросаны по разным узлам и серверам. Рассмотрим основные аспекты распределенных транзакций:

Атомарность (Atomicity): Это ключевое свойство, обеспечивающее, что все действия в рамках распределенной транзакции выполняются как единое целое. Если хоть одна часть операции не может быть завершена успешно, все изменения, связанные с транзакцией, отменяются, возвращая данные к их исходному состоянию. Это гарантирует целостность данных.

Консистентность (Consistency): Это свойство гарантирует, что после успешного завершения распределенной транзакции данные находятся в состоянии, соответствующем бизнес-правилам и целостности информация. Если какие-либо изменения нарушают эту целостность, транзакция откатывается.

Изоляция (Isolation): Этот аспект предотвращает конфликты между параллельно выполняемыми распределенными транзакциями. Он определяет, как каждая транзакция видит изменения, производимые другими транзакциями, чтобы избежать некорректных результатов.

Долговечность (Durability): Это свойство обеспечивает, что успешно завершенные распределенные транзакции сохраняют свои изменения даже в случае сбоев системы. Данные остаются надежными и доступными после восстановления системы.

Координация (Coordination): Реализация распределенных транзакций требует механизмов координации для обеспечения выполнения всех вышеуказанных свойств. Это может включать использование методов, таких как двухфазное фиксирование (2PC), распределенные блокировки и другие техники согласования.

Распределенные транзакции представляют сложную инженерную задачу, так как они должны учитывать сетевые задержки, сбои в работе узлов и обеспечивать надежность операций. Они находят широкое применение в областях, таких как финансовые услуги, электронная коммерция и облачные вычисления, где данных и ресурсы могут быть разделены по различным серверам и местоположениям [1, ст. 63].

Рассмотрим управление распределенными транзакциями поддерживающие ACID включает различные протоколы и стандарты, включая XA и другие. Вот несколько из них:

— XA (eXtended Architecture): XA — это стандарт, разработанный для управления распределенными транзакциями в среде, где используются реляционные базы данных. Он предоставляет интерфейс для координации транзакций между несколькими базами данных, обеспечивая их атомарность и согласованность. XA используется в Java в рамках Java Transaction API (JTA).

— WS-AtomicTransaction: Этот стандарт определен в рамках веб-сервисов (Web Services) и предоставляет механизм для управления транзакциями в распределенных веб-сервисах. Он обеспечивает атомарность и согласованность операций между различными участниками веб-сервиса.

— JTA (Java Transaction API): — это API для управления транзакциями в Java-приложениях. Он предоставляет программистам средства для управления распределенными транзакциями с использованием XA и других протоколов.

— Saga — это паттерн проектирования для управления долгоживущими транзакциями в распределенных системах. Вместо атомарной транзакции, сага разделяет долгую транзакцию на несколько маленьких, которые могут быть компенсированы, если что-то идет не так.

Стандарты и спецификации предоставляют средства для реализации ACID-транзакций в различных системах и языках программирования, обеспечивая тем самым надежность и целостность данных в распределенных средах. Транзакции позволяют разным системам участвовать в распределенных транзакциях, гарантируя их согласованность через XA-интерфейс.Но некоторые системы обмена сообщениями, такие как Apache ActiveMQ или IBM MQ, также поддерживают XA-транзакции. Это позволяет включать отправку и получение сообщений в распределенные транзакции, что полезно для интеграции разных компонентов системы.

Некоторые веб-серверы и серверы приложений предоставляют средства для управления распределенными транзакциями с использованием XA-спецификаций. Например, Java EE использует JTA для выполнения распределенных транзакций. Это позволяет веб-приложениям взаимодействовать с несколькими сервисами одновременно и обеспечивать согласованность между ними.

Несмотря на преимущества, распределенные транзакции имеют свои проблемы. Некоторые современные технологии, такие как NoSQL базы данных (MongoDB, Cassandra) и некоторые брокеры сообщений (RabbitMQ, Apache Kafka), не поддерживают их. Также, такие транзакции могут ухудшать доступность системы, и это связано с CAP-теоремой, которая указывает на ограничения в согласованности, доступности и устойчивости к разделению данных в распределенных системах.

Для более эффективной работы с микросервисной архитектурой и обеспечения согласованности данных, рекомендуется использовать более гибкие и асинхронные механизмы, такие как слабо связанные асинхронные сервисы и повествования (event-driven architecture). Эти подходы могут помочь преодолеть ограничения, связанные с распределенными транзакциями, и обеспечить более высокую доступность и устойчивость системы.

Шаблон «Повествование» — это архитектурный подход, который обеспечивает согласованность данных в распределенных системах. Он основан на идее использования асинхронных сообщений для обновления данных в различных сервисах [2].

Когда какое-то действие должно изменить данные, вместо непосредственного обновления данные публикуются как сообщение в систему сообщений или очередь. Затем другие сервисы, подписанные на эти сообщения, получают уведомление и выполняют необходимые изменения в своих данных.

Этот подход помогает избежать непосредственной зависимости между сервисами и делает систему более гибкой и масштабируемой, сохраняя при этом согласованность данных [3].

Проектирование подсистемы распределенных вычислений для экосистемы научных исследований . Модель повествований для подсистемы распределенных вычислений для обработки событий(рис.1)., предназначен для написания как оркестрантов, так и участников повествований.

Модель повествований для подсистемы распределенных вычислений необходима для разработки микросервисных приложений, предоставляющая инструменты для управления и обработки саг (saga) в распределенных системах. Он использует возможности транзакционного обмена сообщениями, встроенные в Eventuate Tram [4].

Модель повествований для подсистемы распределенных вычислений обеспечивает следующие возможности:

— Определение саги: Можно определить сагу, описывая последовательность шагов (компенсирующих и подтверждающих операций), которые должны быть выполнены в случае сбоя.

— Обработка саги: Предоставляет инструменты для выполнения саги, обработки шагов, и обеспечивает атомарность операций в рамках саги.

— Управление сагой: Позволяет отслеживать состояние саги и управлять ею, включая возможность приостановки, отката и перезапуска саги в случае сбоев.

— Интеграция с Eventuate Tram: Модель повествований для подсистемы распределенных вычислений интегрируется с другими компонентами Eventuate Tram, такими как Eventuate Tram Command, для обеспечения согласованности данных и команд в распределенной системе.

Модель повествований для подсистемы распределенных вычислений облегчает разработку и управление распределенными микросервисами, гарантируя целостность данных и обеспечивая отказоустойчивость при возникновении сбоев в системе.

Самая сложная часть данного паттерна — пакет saga orchestration. Он предоставляет SimpleSaga — базовый интерфейс для повествований и SagaManager — класс [5]

Рис. 1. Описания оркестраторов и участников повествований

Для создания экземпляров повествования и управления ими. SagaManager отвечает также за сохранение повествования, отправку командных сообщений, которые оно генерирует, подписку на ответные сообщения и вызов повествования для обработки ответов. На рис.2 показана последовательность событий, когда OrderService создает повествование. Она состоит из следующих шагов.

1. Сервис OrderService создает CreateOrderSagaState.
2. Он создает экземпляр повествования путем вызова SagaManager.
3. SagaManager выполняет первый этап из определения повествования.
4. Вызывается CreateOrderSagaState для генерации командного сообщения.
5. SagaManager шлет командное сообщение участнику повествования (сервису Consumer) [6].
6. SagaManager сохраняет экземпляр повествования в базе данных.

Рис. 2. Последовательность событий, когда OrderService создает повествование Create Order

На рис. 3 показана последовательность событий, когда SagaManager получает ответ от сервиса Consumer.

Рис. 3. Последовательность событий, когда SagaManager получает ответ от участника повествования

Последовательность событий выглядит так.

1. Eventuate Tram вызывает SagaManager с ответом, полученным от сервиса Consumer.
2. SagaManager извлекает экземпляр повествования из базы данных.
3. SagaManager выполняет следующий этап из определения повествования.
4. Вызывается CreateOrderSagaState, чтобы сгенерировать командное сообщение.
5. SagaManager шлет командное сообщение заданному участнику повествования (сервису Kitchen).
6. SagaManager сохраняет обновленный экземпляр повествования в базе данных.

Если участнику повествования не удастся выполнить команду, SagaManager вызовет компенсирующие транзакции в обратном порядке.

Еще одной частью паттерна Event является пакет saga partici pant. Он предоставляет классы SagaCommandHandlersBuilder и SagaCommandDispatcher для написания участников повествования. Эти классы направляют командные сообщения к методам-обработчикам, которые вызывают бизнес-логику участника и генерируют ответы [7].

Проектирование базы данных для подсистемы распределенных вычислений . Обычно команда службы должна создавать/обновлять/удалять агрегаты в базе данных и отправлять сообщения/события в брокер сообщений. Например, служба, участвующая в саге, должна обновлять бизнес-сущности и отправлять сообщения/события. Аналогично, служба, публикующая событие домена, должна обновить агрегат и опубликовать событие.

Команда должна атомарно обновлять базу данных и отправлять сообщения, чтобы избежать несогласованности данных и ошибок. Однако часто невозможно использовать традиционную распределенную транзакцию (2PC), которая охватывает базу данных и брокер сообщений. База данных и/или брокер сообщений могут не поддерживать 2PC. И даже если они поддерживают, часто нецелесообразно связывать службу с обеими: и базой данных, и брокером сообщений.

Но без использования 2PC отправка сообщения в середине транзакции не надежна. Нет гарантии, что транзакция завершится успешно. Точно так же, если служба отправляет сообщение после завершения транзакции, нет гарантии, что она не выйдет из строя до отправки сообщения.

Кроме того, сообщения должны отправляться в брокер сообщений в том порядке, в котором их отправляет служба. Они обычно должны доставляться каждому потребителю в том же порядке, хотя это выходит за рамки данного шаблона.

Заключение . Врезультате проектирования системы получаемМодель повествований для подсистемы распределенных вычислений. Эта модель необходима для управления распределенными транзакциями и событиями в микросервисных системах. Модель позволяет создавать устойчивые и координированные транзакции между разными сервисами, которые не связаны друг с другом, выполняют функции связующего звена между системами. Также использование модели повествований для подсистемы распределенных вычислений обеспечивает надежность, целостность и координацию распределенных транзакций в микросервисных приложениях, что является важным аспектом в современном разработке программного обеспечения [8].

Литература:

1. Карнелл Джон, Санчес Иллари Уайлупо, Д. «Микросервисы в действии». Изд-во:ДМК Пресс, 2022, 490 с. С. 63–80.
2. Ньюмен Сэм. Создание микросервисов. 2-е Изд-во: Питер, 2023. — 624 с. С.144–200.
3. «Микросервисы в действии (Microservices Patterns: With examples in Java)". Крис Ричардсон. Изд-во:Питер, 2020. 544 с. С. 146–184
4. Блейкли К. Искусство микросервисов. Москва: Диалектика, 2019.
5. Ньюман З. Построение микросервисной архитектуры. Москва: Диалектика, 2018.
6. Фаулер М. Микросервисы. Руководство по архитектуре приложений. Москва: Диалектика, 2017.
7. Джонс К., Вайкли Ф. Микросервисы: миф или реальность? Москва: Диалектика, 2020.
8. Реймерс, К. Практика микросервисной архитектуры. Москва: Диалектика, 2019.