проектирование хранилища данных микросервисов

Пусть микросервисное хранилище данных больше не будет лабиринтом: поговорим о том, как сделать поток данных более плавным

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

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

В чем разница между данными в микросервисах?

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

• Владение данными рассредоточено: Служба заказов управляет данными заказа, а служба пользователей управляет данными пользователя. У них есть свои базы данных и даже могут быть разные типы хранения данных.
• Формы данных более разнообразны: Некоторые сервисы используют реляционные базы данных, а некоторые — базы данных документов, и структуры данных больше не являются единообразными.
• Изменения происходят быстрее: Обновление службы не всегда должно требовать выхода из строя всей архитектуры хранилища данных.

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

Не просто переезд: новые потоки данных для совместной работы

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

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

Еще есть система отслеживания измененных данных (CDC). Если служба не использует механизм событий, CDC является мощным дополнением. Это похоже на специальный регистратор, который постоянно отслеживает журнал изменений (binlog) базы данных. Как только данные добавляются, удаляются или изменяются, они незаметно фиксируют изменения и передают их нижестоящему потоку. Это гарантирует синхронизацию данных, «копируя» почти каждое действие в источнике.

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

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

От хаоса к ясности: создание «карт» надежных данных

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

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

Этот процесс, особенно построение промежуточных слоев детализации, немного похож на рисование стандартизированной карты. Независимо от того, поступают ли данные заказа из MySQL или PostgreSQL, или портрет пользователя — из MongoDB или еще откуда-то, на этом уровне все они преобразуются в единый и стандартизированный «язык» и «координаты». Таким образом, независимо от того, хотите ли вы проанализировать пути покупок пользователей или рассчитать бизнес-показатели в реальном времени, вы получите четкие и достоверные данные, и вам больше не придется беспокоиться о несоответствиях и противоречиях данных.

Здесь может возникнуть практический вопрос: а что, если при передаче данных возникнут ошибки? Или я хочу отслеживать, как шаг за шагом рассчитывается определенный ключевой номер. Могу ли я это сделать? Это приводит к двум важнейшим основам: мониторингу качества данных и отслеживанию происхождения данных.

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

Варианты и соображения по реализации дизайна

Увидев это, вы можете подумать: звучит хорошо, но как это сделать? Каковы невидимые препятствия?

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

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

Кстати говоря, какова конечная цель всего этого? Разве это не просто пробуждение данных, спящих в распределенных сервисах, чтобы их можно было легко и точно использовать для ответа на вопросы и принятия решений? Будь то просмотр операционных информационных панелей в режиме реального времени, обучение рекомендациям или проведение углубленного бизнес-анализа, правильно спроектированное хранилище данных является наиболее прочной основой.

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

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

Основанная в 2005 году,мощностьбыла посвящена профессиональному производителю компактных приводов со штаб-квартирой в Дунгуане, провинция Гуандун, Китай. Используя инновации в технологии модульных приводов,мощностьобъединяет высокопроизводительные двигатели, прецизионные редукторы и многопротокольные системы управления, обеспечивая эффективные и индивидуальные решения для интеллектуальных систем привода. Kpower предоставила профессиональные решения в области приводных систем более чем 500 корпоративным клиентам по всему миру, предлагая продукты, охватывающие различные области, такие как системы «умный дом», автоматическая электроника, робототехника, точное земледелие, дроны и промышленная автоматизация.