Когда серверная система встречается с микросервисами: разделите эти вещи

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

Проекты мехатроники в рамках традиционной архитектуры часто сталкиваются с этой дилеммой.

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

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

Это не магия, это метод: что именно есть в микросервисе?

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

Первое ядро: независимо развернутые бизнес-подразделения.

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

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

Второе ядро: облегченный механизм связи.

Как сервисы «общаются» друг с другом? Обычно они взаимодействуют через четко определенные, легкие API (интерфейсы прикладного программирования), часто HTTP/REST или аналогичные очереди сообщений. В электромеханическом контексте это можно понимать как стандартизированный протокол связи с малой задержкой. Каждая служба предоставляет только необходимые «диалоговые окна», а внутренняя реализация скрыта. Безопасно и ясно.

Третье ядро: децентрализованное управление данными.

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

Четвертое ядро: автоматизация и эластичность.

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

Пятое ядро: возможности независимой эволюции.

Это одна из самых больших прелестей микросервисов. Команды могут самостоятельно разрабатывать и выпускать сервисы, за которые они несут ответственность, а скорость итерации очень высокая. Хотите попробовать новый фильтр для вашего сервопривода? Просто протестируйте и разверните его в независимом сервисе управления, не затрагивая другие функциональные модули.

От тесной связи к свободному сотрудничеству: как происходит переход?

Увидев это, вы можете подумать: «Звучит здорово, но как это поможет нашему конкретному проекту?»

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

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

Такое разделение снижает сложность и делает выбор технологий более гибким. Определенный сервис требует чрезвычайно высокой скорости вычислений и может быть написан на C++; другой сервис должен быстро подключаться к MES-системе верхнего уровня и может быть написан на Go или Python. Никаких проблем друг для друга.

Выбор и реализация: не достигнуто в одночасье

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

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

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

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

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