Когда ваши сервоприводы начнут выходить из себя, попробуйте этот совет по развертыванию.

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

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

В чем проблема?

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

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

«Отладка подобна поиску пути в лабиринте».

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

Подумайте об этом по-другому: развертывайте свои сервисы как оборудование.

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

Эту идею также можно использовать при развертывании микросервисов — особенно если вам нужно, чтобы они были такими же надежными, как механические системы.

Первый шаг: сначала постройте «скелет», а затем наполните «мышцы».

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

Установите четкие протоколы связи и механизмы отказоустойчивости. Например, если услуга временно недоступна, будут ли потеряны сообщения? Будет ли механизм повтора? Эти основные правила определяют «телосложение» всей системы.

Шаг 2: Активируйте поэтапно и наблюдайте за реакцией

Затем активируйте службы одну за другой в соответствии с зависимостями. Сначала запустите те, которые не зависят от других служб, а затем запустите те, которые зависят от них. Каждый раз, когда вы его активируете, наблюдайте: нормальный ли журнал? Есть ли какие-либо аномалии в потреблении ресурсов? Сможет ли он корректно найти и вызвать службы, от которых зависит?

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

Шаг 3. Смоделируйте «сбой», чтобы увидеть, насколько он устойчив.

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

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

Сделайте само развертывание «гладким»

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

«Сине-зеленое развертывание» — хороший помощник

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

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

Отдельная конфигурация и код

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

Не забывайте, что «мониторинг» — это ваши глаза и уши.

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

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

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

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