Когда ваши механические проекты начинают «говорить»: строим будущее с помощью микросервисов Kafka

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

Этот вид «коммуникационного барьера» слишком распространен в сложных механических системах.

Что могут микросервисы? Это позволяет каждой части «делать свою работу».

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

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

Но снова возникает вопрос: как эти независимые небольшие комнаты могут гарантировать, что сообщение будет доставлено всем, кто в нем нуждается, вовремя и без потерь?

Представляем Kafka: не простая очередь сообщений, а магистраль данных

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

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

Почему это особенно важно для механических проектов?

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

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

Реальные затруднения, с которыми вы столкнетесь, и их решения

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

«Гарантируется ли производительность в реальном времени?» Это зависит от того, как вы проектируете поток данных. Сам Kafka поддерживает передачу с малой задержкой. Ключевым моментом является различие каналов с самыми высокими требованиями в реальном времени (например, инструкции управления с обратной связью) от других потоков аналитических данных (например, исторической статистики производительности). Пусть те, кому следует быть быстрыми, выбирают скоростную полосу, а те, кому следует быть медленными, выбирают медленную полосу.

«Было бы сложнее поддерживать?» Совсем наоборот. Когда возникает проблема с определенной функцией, обычно нужно только проверить соответствующий микросервис, а не искать иголку в стоге сена из десятков тысяч строк кода. Обновления и откаты также стали локализованными — Хотите обновить протокол связи? Активируется только служба связи, а служба управления двигателем может работать в обычном режиме.

От рисунка к реальности: возможный способ начать

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

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

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

Немного мысли

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

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

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

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

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