Рекомендации по использованию данных для микрослужб

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

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

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

Сложности

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

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

Подходы к управлению данными

Ни один подход не работает для всех случаев. Рассмотрим следующие общие рекомендации по управлению данными в архитектуре микрослужб:

• Определите необходимый уровень согласованности для каждого компонента и по возможности предпочитайте конечную согласованность. Определите области в системе, где требуется надежная атомарность, согласованность, изоляция и устойчивость (ACID) транзакций. И определите области, в которых допустима итоговая согласованность. Дополнительные сведения см. в статье "Использование тактического проектирования на основе домена( DDD) для микрослужб.

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

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

• Храните только данные, необходимые службе. Службе может потребоваться только подмножество сведений об сущности домена. Например, в контексте, связанном с доставкой, необходимо знать, какой клиент связан с определенной доставкой. Но вам не нужен адрес выставления счетов клиента, так как ограниченный контекст, связанный с учетными записями, управляет этой информацией. Тщательный анализ домена и подход DDD могут применять этот принцип.

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

• Используйте стиль архитектуры на основе событий. В этом стиле архитектуры служба публикует событие, когда происходят изменения в её публичных моделях или сущностях. Другие службы могут подписаться на эти события. Например, другая служба может использовать события для создания материализованного представления данных, которые лучше подходят для запроса.

  • Опубликовать схему событий. Служба, которая владеет событиями, должна публиковать схему для автоматизации сериализации и десериализации событий. Этот подход позволяет избежать тесной связи между издателями и подписчиками. Рассмотрим схему JSON или платформу, например Protobuf или Avro.

  • Уменьшите узкие места в обработке событий на масштабируемом уровне. В большом масштабе события могут стать узким местом в системе. Рекомендуется использовать агрегирование или пакетную обработку, чтобы уменьшить общую нагрузку.

Пример. Выбор хранилищ данных для приложения доставки дронов

В предыдущих статьях этой серии описывается служба доставки дронов в качестве примера. Дополнительные сведения о сценарии и соответствующей архитектуре см. в разделе "Проектирование архитектуры микрослужб".

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

В различных внутренних службах используются различные части информации в запросе и имеются различные профили чтения и записи.

Служба доставки

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

Пользователи часто проверяют состояние доставки во время ожидания пакета. Поэтому для службы доставки требуется хранилище данных, которое подчеркивает пропускную способность (чтение и запись) в ущерб долгосрочному хранению. Служба доставки не выполняет сложные запросы или анализ. Он извлекает только самое последнее состояние для конкретной доставки. Команда службы доставки выбрала Azure Redis Managed Service за его высокую производительность чтения и записи. Сведения, хранящиеся в Управляемом Redis в Azure, являются кратковременными. После завершения доставки служба истории доставки становится системой учёта.

Служба журнала доставки

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

Первый сценарий объединяет данные для аналитики данных для оптимизации бизнеса или повышения качества обслуживания. Служба журнала доставки не выполняет фактический анализ данных. Он получает только данные и сохраняет их. В этом сценарии хранилище должно быть оптимизировано для анализа данных по большим наборам данных и использовать подход «schema-on-read» для обработки различных источников данных. Azure Data Lake Storage подходит для этого сценария, так как это файловая система Apache Hadoop, совместимая с распределенной файловой системой Hadoop (HDFS). Он также настраивается на производительность для сценариев аналитики данных.

Второй сценарий позволяет пользователям искать историю доставки после завершения доставки. Data Lake Storage не поддерживает этот сценарий. Для оптимальной производительности храните данные временных рядов в Data Lake Storage в папках, секционированных по дате. Но эта структура делает отдельные поиски на основе идентификаторов неэффективными. Если вы также не знаете метку времени, поиск идентификаторов требует проверки всей коллекции. Для решения этой проблемы служба журнала доставки также сохраняет подмножество исторических данных в Azure Cosmos DB для быстрого поиска. Записи не должны оставаться в Azure Cosmos DB на неопределенный срок. Вы можете архивировать старые поставки после определенного периода времени, например месяца, выполнив случайный пакетный процесс. Архивирование данных может снизить затраты на Azure Cosmos DB и обеспечить доступность данных для исторических отчетов из Data Lake Storage.

Дополнительные сведения см. в разделе "Настройка Data Lake Storage" для повышения производительности.

Служба пакетов

Служба пакетов хранит сведения обо всех пакетах. Хранилище данных для службы пакетов должно соответствовать следующим требованиям:

• Долговременное хранение
• Высокая пропускная способность записи для обработки большого объема пакетов
• Простые запросы по идентификатору пакета без сложных соединений или ограничений целостности ссылок

Данные пакета не реляционные, поэтому база данных, ориентированная на документ, хорошо работает. Azure DocumentDB может обеспечить высокую пропускную способность с помощью сегментированных коллекций. Команда службы пакетов знакома с стеком MongoDB, Express.js, AngularJS и Node.js (MEAN), поэтому они выбирают реализацию Azure DocumentDB. Этот выбор позволяет им использовать существующий интерфейс MongoDB, получая преимущества полностью управляемой высокопроизводительной службы Azure.

Связанные ресурсы

• Шаблоны проектирования микрослужб
• Использование анализа домена для моделирования микрослужб
• Проектирование архитектуры микрослужб
• Проектирование API для микрослужб
• Архитектура микрослужб