Когда ваша серверная система начинает «неуклюже»: история о REST API микросервисов

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

Проблема часто не в самом оборудовании

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

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

В это время вам, возможно, придется передумать и взглянуть на проблему.

Микросервисы и REST API: разбиение больших систем на небольшие гибкие команды

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

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

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

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

Но «демонтаж» — это не цель, а «лучшее сотрудничество».

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

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

Хороший дизайн API немного похож на разработку эффективного протокола связи для команды. должно:

• Интуитивно понятный и простой для понимания: Увидев адрес интерфейса и методы, можно догадаться, что он делает. например/api/мотор/статусИспользуется для получения статуса двигателя,ПОСТ/API/задачаИспользуется для выдачи новых задач.
• Стабильный и последовательный: Сегодня и завтра он ведет себя одинаково. Формат возвращаемых данных и значение кода ошибки остаются унифицированными, что обеспечивает спокойствие вызывающему абоненту.
• Передавайте только необходимую информацию: Ни больше, ни меньше, ровно столько, чтобы удовлетворить потребности сотрудничества. Избегайте перемещения больших объемов избыточных данных между службами, что увеличивает нагрузку на сеть и затраты на анализ.
• Иметь хорошую «отказоустойчивость»: сеть время от времени отключается, и определенная служба временно не отвечает. Хороший дизайн API может помочь системе плавно ухудшиться или быстро восстановиться, а не напрямую сбой.

От концепции к практике: некоторые неизбежные конкретные мысли

На чем бы мы сосредоточили внимание при построении такой системы?

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

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

В-третьих, мониторинг и понимание. Как узнать, работоспособна ли вся система после того, как система разобрана? Требуется единый механизм регистрации, мониторинга и отслеживания ссылок. Когда время обработки определенной детали истекает, вы можете быстро отследить, какая служба (например, служба планирования пути) отвечает медленно, вместо того, чтобы слепо проверять все оборудование.

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

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

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

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

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

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

Все начинается с четкого понимания того, как вести диалог.

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