шаблоны проектирования микросервисов с примерами

Когда серводвигатель тоже начинает «болтать»: Поговорим о микросервисном дизайне

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

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

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

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

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

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

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

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

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

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

Более того, это техническая свобода. Различные микросервисы могут быть созданы на основе того стека технологий, для которого они лучше всего подходят. Модуль, выполняющий множество математических вычислений, может использовать C++; внешний шлюз, отвечающий за веб-взаимодействие, может использовать Go или Python. существоватьмощность, мы знаем, насколько важно подобрать наиболее подходящую технологию привода для двигателей с различными требованиями к производительности, и то же самое касается выбора архитектуры программного обеспечения.

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

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

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