связь Kafka между микросервисами

Той ночью на конвейере снова прозвучал сигнал тревоги.

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

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

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

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

И Кафка может помочь.

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

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

Каковы преимущества? Это очевидно.

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

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

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

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

Некоторые также спрашивают, увеличит ли это сложность системы?

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

Как начать его использовать?

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

Говоря об этом, можно подумать — это больше похоже на работу в ИТ-архитектуре, какое отношение это имеет к механическому управлению?

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

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

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

В конце концов, плавность движения робота зависит не только от того, насколько быстро вращается двигатель, но и от того, насколько стабильно передаются данные.

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

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