микросервисы программного обеспечения Reindeer

Олень превращается в экспресс: когда серверное ПО встречается с микросервисами

Представьте себе этот сценарий.

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

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

Где выход?

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

От «бардака» к «четкому движению»

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

Что это дает?

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

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

Разум и поэзия: Стабильность – не вопрос удачи

Конечно, если разобрать систему, люди спросят: станет ли она более уязвимой? Разве при большем количестве точек подключения не увеличится ли вероятность отказа?

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

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

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

Как начать эту «гибкую эволюцию»?

Вы можете подумать: звучит здорово, но не будет ли переход от существующей модели «оленей» огромной задачей?

Его не обязательно изобретать заново. Более прагматичный путь – это «постепенная реконструкция». Вы можете начать так:

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

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

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

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

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

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