Когда ваш проект микросервисов C++ сталкивается с проблемами управления: неофициальная ответная записка

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

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

Что мы обычно делаем, сталкиваясь с такой ситуацией?

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

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

Но, честно говоря, создание такой архитектуры в среде C++ похоже на расчистку пути в лесу в первые дни. Вам нужно подумать, что использовать для межпроцессного взаимодействия (gRPC? ZeroMQ? Simple TCP?), как обрабатывать сериализацию данных, как изолировать ошибки без их распространения, не говоря уже о базовом, но сложном вопросе управления ресурсами. Создание его с нуля заняло бы как минимум несколько недель и потребовало бы бесчисленных циклов отладки до поздней ночи.

Зачем вам нужна хорошая отправная точка?

Сказав это, я вспомнил эталонную реализацию с открытым исходным кодом, с которой я сталкивался раньше. В нем нет никаких уловок, он просто четко показывает, как может выглядеть приложение микросервисов на C++. Каждая служба имеет четкие обязанности. Например, служба, которая специально обрабатывает генерацию сигнала ШИМ, полностью отделена от службы, которая анализирует инструкции положения. Данные передаются между ними посредством облегченных сообщений. Даже если определенная служба временно не отвечает, вся система не зависнет.

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

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

На чем нам следует сосредоточиться?

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

Тогда есть наблюдаемость. Может ли каждый сервис независимо выводить значимые журналы и показатели состояния? Если в движении рулевого механизма наблюдается отклонение, можете ли вы быстро найти звено обработки данных, в котором возникла проблема? Хороший дизайн делает диагностику такой же интуитивной, как просмотр приборной панели.

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

Случайная мысль

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

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

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

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