Когда ваш механический проект начинает «работать изолированно»

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

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

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

Это звучит немного абстрактно? Давайте поговорим о чем-то конкретном

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

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

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

Как выглядит надежная платформа микросервисов?

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

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

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

Избегайте этих великолепных ловушек

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

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

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

Итак, как начинается история?

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

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

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

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

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

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