Когда микросервисная архитектура встречается с серводвигателями: эти маленькие головные боли

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

Вы всегда чувствуете, что реакция определенной службы немного медленная? Когда данные передаются между разными модулями, некоторые ключевые параметры иногда теряются? Или если быть более прямым — при тестировании одного сервиса всё нормально, но при его внедрении в реальную производственную среду мотор периодически трясётся, как в судороге, останавливается на полсекунды, а потом продолжает работать как никто другой?

Это не галлюцинации. В микросервисной архитектуре действительно есть некоторые уникальные сбои при взаимодействии с оборудованием.

В чем проблема? Несколько распространенных «подводных камней»

Задержки связи стали недостатком. Микросервисы полагаются на сетевые вызовы, и каждый вызов требует запроса и ответа. Для такого оборудования, как серводвигатели, которым требуются инструкции в реальном времени, даже задержка в десятки миллисекунд может вызвать отклонения в траектории движения. Представьте себе прецизионную сборочную линию. Если сервопривод останавливается на 0,1 секунды в ожидании данных – точность всей партии продуктов может снизиться.

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

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

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

Как с этим справиться? Идея на самом деле может быть очень «механической».

Интересно, что способ решения этих проблем иногда требует вдохновения от аппаратного мышления.

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

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

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

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

мощностьПрактика: Превращение проблем в функции

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

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

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

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

Итак, стоит ли нам использовать микросервисы?

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

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

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

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