интеграция микросервисов с API-шлюзом

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

В это время кто-то начал задаваться вопросом: могут ли эти данные «ходить» сами по себе?

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

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

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

Какая разница в этой интеграции?

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

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

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

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

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

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

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