В этой статье я познакомлю вас с понятием Data Grid , его свойствами, предлагаемыми услугами и, наконец, с тем, как разработать масштабируемую Data Grid для ваших нужд.
Что такое таблица данных?
Сетка данных — это набор сервисов, которые предоставляют общую систему управления данными, в которой гетерогенные данные из различных приложений и сервисов будут доступны посредством формирования сеткообразной структуры. Это возможно при использовании мощных промежуточных приложений и сервисов, которые поддерживают ввод / запрос данных из различных запросов приложений.
Доступ к данным в сетке осуществляется через API (предпочтительно REST и в формате JSON). Данные могут быть сохранены на диск или могут быть сохранены в другой базе данных. Сетка должна быть очень эластичной по своей природе (горизонтально масштабируемой) и должна поддерживать практически любой объем данных. Несколько сервисов могут сохранять данные в формате JSON в этой сетке и отправлять запросы в миллисекундах (аналогично кешу).
Ниже приведены свойства Data Grid:
- Доступ к данным из сетки осуществляется с использованием API — на основе REST в формате JSON.
- Действительно эластичный по своей природе — может быть масштабирован горизонтально без верхних границ.
- Долговечность — выдерживает простои и сбои системы.
- Предлагает ответы с низкой задержкой.
Необязательные (хорошо иметь) свойства:
- Учитывая важность данных, каждый запрос данных из сетки может быть разрешен
- Решения, такие как JWT , проверка клиента TSL и т. Д.
- Возможность очистить данные и освободить место для более актуальных данных.
- Возможность сохранения данных на диск.
- Возможность горячей загрузки данных из других источников данных, таких как хранилища RDBMS или NoSQL.
Вам также могут понравиться:
Примеры гридов данных, вычислительных гридов, сервисных гридов и выполнение запросов SQL .
Использование сетки данных
В истинном мире архитектуры микросервисов, где каждый сервис имеет свою собственную частную базу данных (база данных на модель сервиса), сложно, если какой-либо из сервисов требуется извлекать данные из нескольких сервисов. Первоочередной задачей может быть обработка ответов от этих служб в различных форматах, таких как JSON, XML или двоичный формат. Некоторые запросы могут быть по HTTP (S) с использованием стандартов REST , некоторые с использованием SOAP, некоторые с использованием RPC и т. Д.
Это не технические проблемы, а довольно громоздкие для реализации в микросервисе для таких сценариев, как: обработка сбоев, таких как исключения безопасности, проверка данных, квитирование, сеть, анализ данных и т. Д. Хотя можно с уверенностью предположить, что это наиболее используемый подход, фактор высокой зависимости вводится. Любое изменение в любой из услуг производителя может изменить структуру ответа, и потребителю может также потребоваться учесть это изменение. Это может быть неэффективным, если потребительские сервисы только запрашивают данные (и не запрашивают какие-либо результаты вычислений) из других сервисов.
Чтобы решить вышеупомянутую проблему, мы представляем подход Data Grid, который предлагает практически любой объем настраиваемого хранилища данных с низкими задержками ответов, которые легко масштабируемы и просты в обслуживании. Мы можем использовать Apache Ignite (именуемый Ignite в будущем) в качестве одного из основных компонентов нашей системы Data Grid, которая предлагает надежную, гибкую и распределенную платформу в памяти. Ignite предлагает множество вариантов кэширования, возможность подключения к хранилищам RDBMS и NoSQL и вычислительные сервисы.
Определения данных
Как правило, для построения Data Grid для вашей инфраструктуры все микросервисы должны публиковать формат данных, которые они записывают в сетку. Например, служба пользователя (служба для управления всеми пользователями системы) должна публиковать всю информацию о пользователях для всех операций загрузки и удаления. Пользовательская служба должна опубликовать определение данных структуры пользовательских данных. Это определение данных должно поддерживать управление версиями, чтобы любая новая служба могла запрашивать определенную / последнюю версию. Все зависимые потребительские сервисы могут запросить определение данных из таблицы данных и начать создание функциональности сервиса. Ниже приведен пример опубликованной структуры пользовательских данных (версия 1).
https: // <хост> / grid / datadefinition & type = user & version = 1 .
JSON
1
{
2
"user": {
3
"description": "Structure of a user data.",
4
"owner": "user_service",
5
"version": 1,
6
"fields": [
7
{ "name": "id", "type": "uuid", "description": "Unique identifier for this user." },
8
{ "name": "email", "type": "string", "required": true },
9
{ "name": "mobile", "type": "string", "required": true },
10
{ "name": "name", "type": "string", "description": "Firstname of the user." },
11
{ "name": "zipcode", "type": "string", "description": "Zipcode of the user location." },
12
{ "name": "status", "type": "string", "required": true, "values": ["registered", "inactive", "deleted"]}
13
]
14
}
15
}
Для версии 2 определения пользовательских данных запрос может быть следующим: https: // <хост> / grid / datadefinition & type = user & version = 2 .
JSON
xxxxxxxxxx
1
{
2
"user": {
3
"description": "Structure of a user data.",
4
"owner": "user_service",
5
"version": 2,
6
"fields": [
7
{ "name": "id", "type": "uuid", "description": "Unique identifier for this user." },
8
{ "name": "salutation", "type": "string", "description": "Salution for the user.", "required": true, "values": ["Mr.", "Ms.", "Mrs.", "Dr."]},
9
{ "name": "lastLogin", "type": "dateTime", "description": "Last login time of the user."},
10
{ "name": "email", "type": "string", "required": true },
11
{ "name": "mobile", "type": "string", "required": true },
12
{ "name": "name", "type": "string", "description": "Firstname of the user." },
13
{ "name": "zipcode", "type": "string", "description": "Zipcode of the user location." },
14
{ "name": "status", "type": "string", "required": true, "values": ["registered", "inactive", "deleted"]}
15
]
16
}
17
}
Дизайн высокого уровня
Дизайн системы для Data Grid может быть объяснен на примере интернет-магазина покупок. Торговый сайт создается с использованием различных микросервисов, таких как служба пользователя, служба заказа, служба каталога продукции и другие службы, которые помогают в размещении заказа на продукт из различных каталогов и, наконец, доставке его покупателю.
Компонент Услуги
Уровень данных
Это сердце Data Grid, где развернута установка Apache Ignite (режим сервера). Эта настройка формирует «Ignite Server Cluster». Ниже перечислены некоторые функции, которые Ignite предлагает для построения масштабируемой сетки:
- Кэширование в памяти — для ответов с низкой задержкой.
- Распределенное и долговечное хранение.
- Эластичность (горизонтальное масштабирование путем добавления узлов).
- Отказоустойчивость (репликация данных и автоматическая балансировка нагрузки при сбое узла).
- Репликация и сохранение данных (на диск или в базу данных).
Ignite также работает на архитектуре без хозяина, а раскрутка дополнительных узлов только добавляет дополнительное пространство кэша в памяти в группу кластеров. Ignite также предлагает различные конфигурации кеша; в зависимости от ваших потребностей, это может быть настроено и улучшено. Конфигурации включают параметры сохранения данных, политики удаления кэша, репликацию данных и т. Д.
Data Grid API Gateway
Это шлюз для маршрутизации запросов на соответствующие серверы. В шлюзе можно зарегистрировать несколько служб, чтобы запросы можно было обрабатывать и масштабировать в соответствии с нагрузкой.
Службы запросов и службы обновлений
Это множество серверов приложений, предназначенных либо для запроса данных, либо для обновления / добавления данных на уровень данных. Эти службы запрашивают / обновляют данные из / в «Ignite Server Cluster» (см. Изображение выше для визуализации уровня данных).
Службы запросов классифицируют службы, которые ТОЛЬКО запрашивают данные. Службы в этой настройке используют клиентскую библиотеку Ignite (настроенную как режим клиента) для подключения к кластеру серверов Ignite и становятся частью топологии кластера Ignite. Если эти службы не предназначены для присоединения к топологии кластера в качестве клиентских узлов Ignite, то мы можем использовать тонкие клиенты Ignite (например, тонкий клиент Java или тонкий клиент Node.js ) для подключения к кластеру Ignite Server и выполнения операций кэширования. Каждая из служб может обновлять 1 или более кэшей в кластере серверов Ignite.
Передача данных в таблицу данных может быть сопряжена с дополнительными затратами , но это можно преодолеть с помощью асинхронных механизмов или путем помещения данных в какую-то тему Kafka, где данные будут использоваться службой обновления сетки данных, которая отправляет их в Ignite. Кластер серверов.
Примечание . Службы приложений используют клиентские библиотеки Ignite для операций кэширования. По умолчанию они также участвуют в кэшировании, присоединяясь к топологии кластера Ignite Server для работы в качестве узлов сервера. Это не обязательно; флаг режима клиента (установлен в true) должен быть включен в файле конфигурации Ignite, или аналогичный Ignite API должен вызываться при инициализации службы приложения. Смотрите эту ссылку для получения дополнительной информации о настройке клиента и сервера Ignite.
Использование Data Grid в примере
На приведенной выше диаграмме компоненты в самой левой части представляют собой микросервисы, где каждый сервис имеет свою собственную базу данных. В подходе, не связанном с сеткой данных, службе заказа может потребоваться запросить у службы пользователя информацию, относящуюся к пользователю (например, электронную почту, адрес и т. Д.). В определенные периоды, такие как рождественские или благодарственные распродажи, служба заказа может столкнуться с большими объемами транзакций. В таких случаях службе заказа может потребоваться вызвать службу пользователя для получения информации, связанной с пользователем (например, адрес электронной почты, адрес и т. Д.), Пропорциональной количеству транзакций заказа.
При желании служба заказа может кэшировать информацию о пользователе, чтобы избежать нескольких сетевых вызовов. Или, чтобы удовлетворить растущую нагрузку на службу пользователя, нам может потребоваться добавить больше узлов службы пользователя в кластер для обработки запросов на чтение. Аналогичным образом, другие службы также могут нуждаться в расширении, до которого приходится много трафика чтения. Это где Data Grid может быть представлен.
Всякий раз, когда происходит обновление данных в одном из микросервисов, эти данные будут отправляться в таблицу данных с помощью службы обновления сетки данных. Эта служба обновлений подключается к серверу Ignite и затем вставляет данные в кэш. Данные, вставленные в кеш, будут основаны на конфигурации кеша, развернутой в службе обновления. Это гарантирует, что любые данные, которые обновляются в любом микросервисе, будут также доступны в сетке данных. Кроме того, поскольку Ignite долговечен, мы можем добавить любое количество узлов для поддержки большого набора данных из различных служб. Кластер Ignite Server можно включить с собственным постоянством или подключить к базе данных, чтобы сохранить данные кэша.
Когда одному из микросервисов требуется доступ к конкретным данным, он запрашивает сетку данных, используя службу запросов к сетке данных , передавая необходимые параметры запроса. Служба запросов подключается к серверу Ignite и затем запрашивает данные из кэша. Если данные доступны в кэше, они будут отправлены в ответ. Если данные недоступны в кэше, Ignite может загрузить их из постоянного хранилища (если постоянство включено).
Возможен сценарий, когда данные недоступны в кеше, а также в постоянном хранилище. Служба запросов может иметь встроенную логику для перенаправления запроса в соответствующий микросервис, извлечения данных и вставки их в кэш. Тот же самый ответ может быть отправлен обратно в службу поддержки потребителей, которая запросила эти данные. При следующем запросе данные будут получены из самой таблицы данных.
Данные, вставленные в кеш, будут основаны на конфигурации кеша, развернутой в службе обновлений. Это гарантирует, что любые данные, которые обновляются в любом микросервисе, будут также доступны в сетке данных. Кроме того, поскольку Ignite долговечен, мы можем добавить любое количество узлов для поддержки большого набора данных из различных служб.
Резюме
В этой статье предпринята попытка решить проблему, в которой потребительские услуги могут быть отделены от услуг производителя. Это также дает пользователям возможность добавлять дополнительные услуги в полк микросервисов, создавать и развертывать новые наборы функций.