Когда следует использовать микросервисную архитектуру? Послушайте истории из мира серводвигателей

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

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

Эта неприятная система «больших парней»

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

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

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

Микросервисы: думайте как механические модули

Когда вам следует рассмотреть эту архитектуру?

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

Вопросы и ответы в некоторых реальных сценариях

Вопрос: Усложнят ли микросервисы систему?

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

Вопрос: Когда микросервисы не подходят?

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

Вопрос: Как определить степень детализации разделения?

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

От идеи к реализации: некоторые нелинейные мысли

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

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

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

написано в

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

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

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

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