почему мы используем Kafka в микросервисах

Вы когда-нибудь пытались управлять большой группой серводвигателей так, чтобы они синхронизировались, как симфонический оркестр?

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

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

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

Приведите пример. Предположим, у вас есть три микросервиса: A принимает сигналы датчиков, B рассчитывает траектории движения, а C записывает логи работы. В традиционной архитектуре B ждет, пока A завершит обработку, прежде чем он сможет работать, а C должен ждать B. Но после использования Kafka A помещает исходные данные на «конвейер», и B и C могут получить к ним доступ одновременно и работать независимо. Даже если C временно замедлится, это не замедлит A и B.

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

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

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

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

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

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

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