Что вы делаете, когда ваши данные начинают «разделяться»?

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

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

Возникает вопрос: как эти «разделенные» данные могут снова стать семьей, не влияя на их самостоятельную жизнь?

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

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

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

Дальше как сохранить. Планировка гостиной очень важна – ее нельзя ни загромождать, ни ограничивать всех сидящими прямо. Распространенным подходом является иерархический дизайн: после поступления исходных данных они сначала помещаются в «буфер» и остаются такими, какие есть; затем, после некоторой очистки и преобразования, он образует «средний слой» с четкой темой, который легко найти; он объединяется в «прикладной уровень» в соответствии с конкретными требованиями анализа или отчетности. Это все равно, что сложить ингредиенты в камеру хранения, переработать их в полуфабрикаты, а затем приготовить из них разные блюда по рецепту.

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

Почему это стоит попробовать?

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

Что важнее, так это скорость. Когда компания спрашивает: «Как прошла эта акция на прошлой неделе?» вам больше не придется собирать воедино данные из нескольких систем; ответ, вероятно, уже есть. Природа реального времени – это конкурентоспособность, когда необходимы быстрые решения.

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

Каковы ключевые шаги от идеи к реальности?

Если вы считаете, что этот путь стоит изучить, вы можете рассмотреть следующие направления при запуске:

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

На что обратить внимание при выборе техники? Инструментов много, но главное — соответствовать своему собственному ритму. Это зависит от того, легко ли интегрироваться с существующей базой данных и очередью сообщений, активно ли сообщество и может ли команда позволить себе затраты на обучение. нравитьсямощностьПри оказании помощи клиентам «простота использования» и «устойчивость в долгосрочной перспективе» часто оцениваются с одинаковой важностью.

Имеет ли значение дизайн схемы? Очень важно, но не переусердствуйте на ранних стадиях. Вы можете позаимствовать некоторые идеи из «библиотеки озера данных», чтобы сохранить исходную гибкость буфера и установить определенный контракт между средним уровнем и уровнем приложения. Главное – сохранить способность развиваться.

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

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

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

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