XAP (In-Memory Computing platform)

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 21:02, 30 января 2019.
GigaSpaces eXtreme Application Platform (XAP)
Logo-xap-color-small.png
Разработчики: GigaSpaces
Постоянный выпуск: 14.0
Написана на: Java
Операционная система: Linux, Windows, macOS
Платформа: .NET
Локализация: Английский
Лицензия: Apache License
Веб-сайт www.gigaspaces.com/product/xap

GigaSpaces eXtreme Application Platform (XAP) - распределенная сеть данных в памяти подходящая для высокопроизводительной обработки с низкой задержкой так же, как и в случаях использования методов аналитики в режиме реального времени.

Обзор

Особенности

GigaSpaces XAP - это платформа, которая масштабирует приложения с поддержкой состояния в высокопроизводительных средах с низкой задержкой. Она предназначена для поддержки транзакционных приложений eXtreme, таких как OMS (системы управления заказами), предоплаченные системы, торговые и рыночные данные; и аналитические приложения в режиме реального времени, такие как анализ прибылей и убытков, сверка и Value at Risk. XAP основан на платформе Open Spaces Framework от GigaSpaces в качестве основной среды разработки и использует среду выполнения GigaSpaces для создания основных компонентов промежуточного программного обеспечения: обмен сообщениями, кэширование данных и распараллеливание. Приложения, запущенные на XAP, можно масштабировать линейно, поскольку XAP использует пространственную архитектуру (SBA) в качестве основного шаблона проектирования. С SBA приложения создаются из набора самодостаточных устройств, называемых модулями обработки (PU). Эти блоки полностью независимы друг от друга, так что приложение может масштабироваться неограниченно без увеличения сложности, просто добавляя больше единиц. SBA основывается на парадигме Tuple Space; он следует многим принципам сервис-ориентированной архитектуры и архитектуры, управляемой событиями, а также элементам grid-вычислений..

Производительность XAP достигается за счет максимального использования ОЗУ и SSD в качестве основного хранилища данных. Он обычно используется для ускорения производительности и масштабируемости существующей базы данных и включает встроенную синхронизацию с RDBS, такую ​​как MySQL, а также MongoDB, Cassandra и т. д. XAP была разработан, чтобы служить в качестве системы записи для данных, которые она поддерживает. Таким образом, он поддерживает все функции баз данных, такие как сложные запросы, поддержка транзакций и т. д. Среди его основных функций - поддержка широкого спектра моделей данных, начиная с простого ключа, API значения для продвижения агрегации, поддержки объектов и поддержки SQL..[Источник 1].

  • Поддержка XAP SSD

Flash обеспечивает высокоскоростное хранилище данных. XAP использует комбинацию RAM и Flash для оптимизации как скорости, так и требования к стоимости. Поддержка Flash известна как XAP MemoryXtend и обеспечивает в 50 раз больше емкости, чем RAM для того же количества компьютеров.

  • XAP в сравнении с простым кэшированием, таким как Memcache

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

  • XAP vs NoSQL

Большинство новых решений NoSQL используются в качестве альтернативной базы данных для традиционных СУБД. Базы данных NoSQL используют комбинацию возможной согласованности и масштабируемости для обработки их масштабируемости и производительности. XAP, с другой стороны, был разработан для решения проблемы масштабируемости и производительности существующей базы данных, обращаясь к базе данных с хранилищем данных в памяти. Хранилище данных в памяти обеспечивает высокоскоростной доступ к данным для той части данных, которая в ней нуждается. Она включает встроенную синхронизацию с базами данных типа NoSQL и RDBMS для загрузки данных после восстановления и синхронизации базы данных при обновлении данных. С точки зрения архитектуры существует много общего между XAP и другими базами данных NoSQL. Оба используют масштабируемую модель для обеспечения ее масштабируемости. В отличие от NoSQL, XAP использует высоконадежный и транзакционный доступ к данным и, следовательно, может служить высокоскоростным транзакционным интерфейсом для баз данных BackSquare NoSQL.

В наши дни XAP используется для комплексной обработки событий и бизнес-аналитики реального времени для больших данных. С помощью XAP вы можете реплицировать данные в реляционную базу данных или нереляционную базу данных NoSQL, позволяя репликацию данных на удаленных сайтах через WAN, для восстановления после сбоев и также cloud-ready.[Источник 2]

Архитектура

GigaSpaces XAP построен из следующих подсистем:

Открытый интерфейсный слой

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

  • Стандартная поддержка API: Memcached, SQL, JPA, Spring, REST, стандартный API карт и многое другое.
  • Многоязычная совместимость: Java, .Net и C++
  • Поддержка нескольких платформ: любая ОС, физическая или виртуальная
  • API Mashup: легко использовать современные API вместе с существующими стандартными API-интерфейсами - позволяет вам использовать правильный инструмент для работы.

Core API

Основной пакет OpenSpaces предоставляет API для прямого доступа к сетке данных, внутренне называемой «Пространством». Основным интерфейсом является GigaSpace, который позволяет осуществлять базовое взаимодействие с сетью данных. Основные компоненты включают базовую инфраструктурную поддержку, такую как Space Java version | .Net, упрощенное API с использованием интерфейса GigaSpace, включая версию управления транзакциями Java version | .Net и декларативная поддержка транзакций. Основные компоненты также включают поддержку построения Map / Cache и упрощенного API с использованием GigaMap.

События

Пакет событий построен поверх основного пакета и предоставляет простые объектно-ориентированные компоненты обработки событий через контейнеры событий, что делает его примерно эквивалентным компонентам Java EE, управляемым сообщениями. (Основные отличия вне семантики API лежат в основе критериев выбора OpenSpaces и маршрутизации.) Пакет событий позволяет просто создавать приложения, управляемые событиями. Другой альтернативой событиям является использование JMS 1.1 поверх GigaSpaces, который поддерживается в продукте, и рекомендуется для клиентских приложений, интегрируемых с приложениями SBA. Модуль событий включает компоненты для упрощенной разработки EDA / Service Bus. Эти компоненты позволяют унифицировать обработку событий и предоставляют два механизма генерации событий: версия Java Polling Container | .Net использует опросы полученных операций против пространства и версию Java Notify Container | .Net, которая использует встроенную поддержку уведомлений в пространстве.

Space Based Remoting

Версия Remoting Java | .Net версия предоставляет клиентам доступ к удаленным службам. Remoting в GigaSpaces XAP реализуется поверх модели кластеризации сетки данных, которая обеспечивает прозрачность местоположения, отказоустойчивость и производительность для удаленных вызовов служб. XAP реализует удаленный доступ, используя пространство как транспортный уровень, аналогично другим компонентам Remoting Spring. Remoting можно рассматривать как альтернативу Java EE Session Beans или Java RMI, поскольку он предоставляет все свои возможности, а также поддерживает синхронные и асинхронные вызовы и динамические языки сценариев - позволяет использовать Groovy или Ruby в вашем пространстве Приложения.

Единые in-memory службы

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

  • Скорость в памяти: обеспечение непревзойденной производительности путем удаления всех физических узких мест ввода-вывода из потока выполнения
  • Масштабируемость: Интеллектуальное распространение любых данных и обмен сообщениями по всем доступным ресурсам
  • Емкость: поддержка терабайт данных приложения
  • Высокая доступность: Встроенная функция горячего резервного копирования и самовосстановления для нулевого времени простоя. * Консистенция. Поддерживайте целостность данных при обработке транзакций на 100%.

В качестве платформы приложений GigaSpaces XAP обеспечивает интегрированные возможности выполнения на основе памяти.

Контейнер для эластичных приложений

XAP - это расширяемая масштабируемая среда исполнения с «эластичным развертыванием» для удовлетворения экстремальных требований к пропускной способности.

  • Линейная масштабируемость: Эластично развернуто / подготовлено, чтобы справляться с экстремальным спросом / пропускной способностью во время выполнения приложения без вмешательства человека
  • Гибкость: запуск различных типов модулей приложений, от простых веб-модулей до сложных модулей обработки событий
  • Упрощение перехода в производство:

     *Гладкое, безрисковое развертывание путем идентичной разработки и производства окружающая среда      *Более быстрое развертывание за счет исключения "силосов"(silos)      *Непрерывное развертывание без простоя Легкие контейнеры приложений обеспечивают среду выполнения бизнес-логики на уровне узла. Они также переводят семантику и сервисы SBA в соответствующую реализацию инфраструктуры контейнерного развития. Например, space-транзакции переводятся на spring-ранзакции, когда используется легкий spring-контейнер. Контейнер Grid Service (GSC) отвечает за предоставление возможностей Grid, тогда как облегченная реализация контейнера отвечает на одном уровне VM. Эти архитектуры очень эффективны, поскольку позволяют приложениям использовать знакомые модели и сервисы программирования на одном уровне VM и, кроме того, предоставляют сетевые возможности и сервисы. GigaSpaces XAP предоставляет несколько реализаций по умолчанию в составе продукта и дополнительный API-интерфейс плагина для обеспечения интеграции других технологий. Архитектура показана на рисунке 1

Рисунок 1 - Архитектура

Перспектива компонентов XAP

OpenSpaces

Open Spaces - основная платформа для разработки приложений в GigaSpaces. Open Spaces использует Spring в качестве инфраструктуры разработки, основанной на POJO, и добавляет компоненты времени выполнения и разработки для разработки приложений на основе EDA / SOA на основе POJO и масштабирует их просто через пул машин без зависимости от контейнера J2EE. Для достижения этих целей Open Spaces добавляет следующие компоненты в среду разработки Spring: Process Unit - основной блок работы. Инкапсулирует промежуточное ПО вместе с бизнес-логикой в ​​единое целое масштабирования и отказоустойчивости. SLA-Driven Container - легкий контейнер, который позволяет динамическое развертывание модулей обработки над пулом машин на основе доступности машины, использования процессора и других критериев аппаратного и программного обеспечения. In-Memory Data Grid - обеспечивает распределенное хранение данных в памяти. Контейнеры декларативных событий - для запуска событий из пространства в POJO в режиме pull или push. Remoting - использует пространство в качестве основного транспорта для вызова удаленных методов в службах POJO внутри модуля обработки. Такой подход позволяет клиенту вызывать методы на службе, даже если он изменяет физическое местоположение и позволяет перенаправлять запросы к доступным службам в случае перехода на другой ресурс. Декларативная поддержка транзакций для грид-данных GigaSpaces.

Core Middleware

XAP полагается на модель JavaSpaces (space-based) в качестве основного промежуточного программного обеспечения и предоставляет специализированные компоненты, реализованные в качестве оберточных фасадов поверх реализаций пространства, для доставки определенных данных или семантики сообщений. XAP предоставляет API JavaSpaces с различными вариантами, подходящими для сценария использования (SQLQuery для данных, FIFO для обмена сообщениями и т. Д.) И другими стандартными API-интерфейсами, такими как JCache / JDBC и JMS. Средства виртуализации промежуточного ПО XAP: Космическая кластеризация - предоставляет все услуги кластеризации, необходимые для приложений с поддержкой состояния. На основе кластерной реализации JavaSpaces. In-Memory Data Grid - обеспечивает семантику кэширования данных поверх базового промежуточного программного обеспечения GigaSpaces; рассматриваются ключевые проблемы распределения распределенного состояния. Поддерживает широкий набор API, включая JDBC для SQL / IMDB, хеш-таблицу через интерфейс Map / JCache и JavaSpaces. Поддерживаются все распространенные топологии кеширования, включая репликацию и разбиение данных.

Средства виртуализации промежуточного ПО XAP:'

  • Космическая кластеризация - предоставляет все услуги кластеризации, необходимые для приложений с поддержкой состояния на основе кластерной реализации JavaSpaces.
  • In-Memory Data Grid - обеспечивает семантику кэширования данных поверх базового промежуточного программного обеспечения GigaSpaces; рассматриваются ключевые проблемы распределения распределенного состояния. Поддерживает широкий набор API, включая JDBC для SQL / IMDB, хеш-таблицу через интерфейс Map / JCache и JavaSpaces. Поддерживаются все распространенные топологии кеширования, включая репликацию и разбиение данных.
  • Сетка сообщений - позволяет службам обмениваться информацией и обмениваться информацией через распределенную сетку данных в памяти. Поддерживает различные сценарии обмена сообщениями с использованием JavaSpaces или JMS API.
  • Параллельная обработка - обеспечивает параллельное выполнение транзакций с низкой задержкой и высокой пропускной способностью с использованием шаблона Master-Worker.

Контейнер с SLA-Driven

Контейнеры с SLA-управлением (известные также как Grid Service Containers или GSC), позволяют развертывать модули обработки по динамическому пулу машин на основе определений SLA. Каждый контейнер представляет собой процесс Java, который обеспечивает среду хостинга для прикладных сервисов, входящих в состав модуля обработки. Контейнер виртуализирует основные вычислительные ресурсы и выполняет сопоставление между временем выполнения приложения и базовыми ресурсами на основе критериев SLA, таких как использование ЦП и памяти, аппаратная конфигурация и доступность программного обеспечения (JVM, DB и т. Д.). Он также обеспечивает возможности самовосстановления для обработки сбоев или масштабирования событий.

  • Сетка данных с поддержкой SLA

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

Runtime-перспектива

С точки зрения времени выполнения кластер XAP представляет собой кластер машин, каждый из которых запускает один или несколько экземпляров контейнеров с SLA-Driven. Контейнеры несут ответственность за предоставление аппаратных ресурсов приложениям XAP. Приложение, работающее с XAP, построено из нескольких модулей обработки. Единицы обработки упакованы как часть пакета; структура связки совместима с Spring / OSGI. Каждый комплект содержит дескриптор развертывания с именем pu.xml, файл контекста приложения Spring с расширениями компонентов Open Spaces. Этот файл содержит определение SLA модуля обработки, а также ассоциации между компонентами приложения, а именно POJO-сервисы, компоненты промежуточного программного обеспечения и, чаще всего, Data Grid. Приложение развертывается через GSM (Grid Service Manager), который выполняет сопоставление между определениями SLA обрабатывающего модуля приложения и доступными контейнерами, управляемыми SLA. Определения SLA включают количество экземпляров, которые необходимо развернуть, количество экземпляров, которые должны запускаться для каждого контейнера и по всей сети, и системные требования, такие как требуемая версия JVM или версия базы данных. Различные приложения могут иметь один или несколько экземпляров своих модулей обработки, работающих в одном и том же контейнере в одно и то же время. Несмотря на то, что приложения имеют один и тот же экземпляр JVM, они изолируются через загрузчики классов приложений.

SOA/EDA-перспектива

Космическая архитектура (SBA) может рассматриваться как частный случай SOA / EDA, разработанный специально для высокопроизводительных приложений с поддержкой состояния. Классическая SOA основана на модели Enterprise Service Bus (ESB), как показано на диаграмме выше. В этой модели услуги становятся слабо связанными с использованием шины обмена сообщениями. Масштабирование выполняется путем добавления дополнительных сервисов в шину и балансировки нагрузки между ними. Большинство реализаций этой модели полагаются на веб-службы для обработки потока сообщений между службами. Эти реализации не могут обрабатывать полноту предоставляемых услуг. Таким образом, хотя слабосвязанная концепция SOA может быть многообещающей для упрощения и масштабирования сервисов по сети, большинство существующих реализаций этой модели не подходят для обработки высокопроизводительных приложений, особенно не в контексте служб с сохранением состояния. С SBA аналогичная модель может быть реализована с использованием пространства. Пространство функционирует как шина обмена сообщениями в памяти - ESB для доставки и маршрутизации транзакций, но также как сетка данных в памяти, которая может поддерживать службы с сохранением состояния. Чтобы избежать накладных расходов ввода-вывода, связанных с взаимодействием этих служб с уровнем обмена сообщениями или уровнем данных, SBA вводит концепцию модуля обработки, который по существу является оптимизацией развертывания / выполнения. Вместо того, чтобы каждый компонент архитектуры был раздельным и удаленным, мы объединяем соответствующую очередь сообщений, связанные с ней службы и данные в единое целое: блок обработки, который всегда работает в одной виртуальной машине. В этом случае взаимодействие между службами обмена сообщениями, службами и уровнем данных выполняется как в процессе, так и в памяти, обеспечивая минимально возможную задержку. Услуги, которые находятся в модуле обработки, аналогичны любым другим службам в мире веб-сервисов. Их жизненный цикл можно управлять индивидуально, и их можно развернуть и обновить динамически, не сводя на нет весь блок обработки (при условии, что они реализованы как службы OSGI). К услугам также могут быть доступны любые другие службы, независимо от того, находятся ли они в одном процессоре или являются удаленными клиентами. В случае совмещенных сервисов взаимодействие очень эффективно, поскольку оно выполняется полностью в памяти. В случае с удаленными службами службы обработки могут быть доступны в различных формах, включая классическую топологию удаленного доступа. В следующем разделе описываются различные параметры взаимодействия и времени выполнения для клиентов, взаимодействующих с службами SBA Processing Unit.

Перспектива удаленного клиента

Приложения, развернутые в XAP, распространяются на нескольких компьютерах. В подходах на основе классического уровня взаимодействия с удаленными клиентами были в основном основаны на RPC или, в некоторых случаях, на основе сообщений. Связь на основе RPC предполагает прямую ссылку на удаленный сервер. Такой подход не работает в приложениях на базе XAP, поскольку они охватывают несколько физических машин и меняют свое местоположение во время выполнения на основе SLA. Это приводит к требованию взаимодействия клиента с приложениями XAP с помощью виртуализованной удаленной ссылки, которая может отслеживать различные экземпляры приложения во время выполнения, а также направлять запросы клиентов в соответствующий экземпляр на основе типа запроса, его содержимого и т. д.

Режимы взаимодействия

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

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

В XAP этот способ взаимодействия может быть достигнут двумя способами:

  • Посредством непосредственного взаимодействия с пространственным интерфейсом. В этом случае операция записи в пространстве является эквивалентом update / put или insert; операция чтения является эквивалентом выбора; и операция уведомления является эквивалентом триггера.
  • Использование оберточных фасадов, предоставляемых GigaSpaces, таких как интерфейс JCache / Map или JDBC-драйвер, которые выполняют это сопоставление неявно.

Взаимодействие с сообщениями Взаимодействие с сообщениями является обычным для сценариев обработки транзакций и основано на шаблоне Command (также известном как шаблон Master-Worker). В этом шаблоне приложения взаимодействуют, отправляя командные сообщения; службы на стороне сервера ждут эти сообщения и будут вызваны их прибытием. Обычно бизнес-логика служб заключается в взаимодействии с IMDG для извлечения текущей информации о состоянии, для ссылки на данные и, наконец, для синхронизации состояния, чтобы обеспечить рабочий процесс с другими службами.

В XAP этот способ взаимодействия может быть достигнут двумя способами:

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

RPC-взаимодействие RPC (Remote Procedure Call) используется для вызова метода бизнес-логики на удаленном сервере. Он отличается от взаимодействия с сообщением в двух отношениях:

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

С дистанционным удалением пространства - удаленный заглушка, созданный для удаленной службы, с использованием динамических прокси. Когда метод вызывается в этом прокси, заглушка неявно отображает его в команде, которая записывается в это пространство и направляется на соответствующий экземпляр сервера. На стороне сервера общий делегат принимает эти команды и выполняет метод в конкретном экземпляре компонента, основываясь на имени метода и аргументах, представленных в команде. Результат также возвращается через пробел, принимается динамическим прокси и прозрачно возвращается клиенту в качестве возвращаемого значения метода.[Источник 3].

Компоненты GigaSpaces XAP можно увидеть на рисунке 2

Рисунок 2 - компонентный вид GigaSpaces XAP


Источники

  1. XAP Real Time Transaction Processing // GigaSpaces. [2019]. URL: https://www.gigaspaces.com/product/xap (дата обращения: 30.12.2018)
  2. GigaSpaces // Wikipedia. [2019]. Дата обновления: 26.01.2019. URL: https://en.wikipedia.org/wiki/GigaSpaces (дата обращения: 17.01.2019)
  3. Docs // GigaSpaces. [2019]. URL: https://docs.gigaspaces.com. (дата обращения: 17.01.2019)