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

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

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

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

Итак, мы начали искать и в конце концов представили Кафку.

Что такое Кафка? Думайте об этом как о высокоскоростной и умной сборочной линии.

Если вы используете знакомую сцену в качестве аналогии: Кафка похож на бесконечный конвейер на фабрике. Каждый микросервис можно рассматривать как рабочую станцию. Станция А ставит полуфабрикаты (сообщения) на конвейер, а станции Б и С забирают их на обработку в любой момент по мере необходимости. Сам конвейер продолжает работать. Даже если какую-то станцию ​​временно отремонтировать, полуфабрикаты не пропадут, а просто будут спокойно ждать на линии, пока станция не приступит к работе.

Это решает несколько головных болей:

• развязка: Услуги больше не «звонят» напрямую, а передаются по конвейеру. Отправитель бросает сообщение и уходит, не зная, кто и когда его обработает.
• буфер: Когда восходящий поток внезапно генерирует большой объем данных (например, внезапный высокочастотный сигнал от датчика), конвейерная лента может временно переносить его, а нисходящий поток может обрабатывать его в соответствии со своими возможностями, чтобы избежать перегрузки.
• надежность: Сообщения сохраняются на конвейере, и даже если некоторые службы будут перезапущены, данные не будут потеряны.
• последовательность: На конвейерной ленте порядок предметов фиксирован. Это критически важно для данных, чувствительных к последовательности, таких как инструкции управления двигателем.

Как мы его используем? Нелинейный эксперимент

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

Мы не начали с капитального ремонта. Вместо этого мы выбрали ссылку с наиболее очевидной болевой точкой, чтобы проверить почву — мониторинг состояния роботизированной руки. Оказывается, данные о состоянии передаются из одного сервиса в другой и часто теряются из-за дрожания сети, из-за чего панель мониторинга время от времени «фрагментируется». Мы просто создали тему Kafka (которую можно понимать как выделенный конвейер), позволили службе публикации статуса записывать сюда данные, а служба мониторинга подписывается на нее. Практически сразу проблема фрагментации исчезла. Потому что даже если служба мониторинга временно отключена, она все равно может прочитать все необработанные обновления статуса из точки останова после перезапуска.

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

Некоторые реальные фрагменты и чувства

Конечно, в этом процессе были некоторые исследования. Например, однажды мы задались вопросом: «На сколько конвейерных лент (Тем) следует разделить?» Позже мы обнаружили, что, как и в мастерской, все детали не будут смешиваться в одной линии, и разумнее управлять ими отдельно по предметности и срочности. Инструкции управления двигателем требуют малой задержки и отдельной высокоскоростной линии; Данные журналов и аудита имеют большой объем, но требуют небольших затрат в режиме реального времени, поэтому используйте другую линию с высокой пропускной способностью. Каждый идет своей дорогой, не мешая друг другу.

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

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

Давайте поговорим о выборе

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

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

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