монолитная микросервисная архитектура

Когда серводвигатель соответствует «монолитной» микросервисной архитектуре: почему простота надежнее?

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

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

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

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

Что именно? Проще говоря, это означает «когда дело дойдет до сотрудничества, оно будет совмещенным».

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

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

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

Какая разница?

• Реакция быстрая и уверенность высокая.Самое прямое ощущение, что система более «следящая». Время, первоначально затрачиваемое на сетевое взаимодействие и сериализацию/десериализацию, значительно сокращается. Для операций с несколькими серводвигателями, которые стремятся к максимальной синхронизации, такая эффективная внутренняя связь означает более точное управление траекторией и меньшую совокупную ошибку. Надежность больше не зависит слишком сильно от условий сети.
• Эксплуатация и обслуживание упрощены, и я чувствую себя более комфортно.Меньше объектов для развертывания, мониторинга и отладки. Вам больше не нужно управлять десятками или сотнями разбросанных экземпляров сервисов, а сосредоточить внимание на нескольких полнофункциональных «общих единицах». Когда что-то идет не так, масштаб расследования становится более целенаправленным. Это похоже на переход от управления сложной моделью, состоящей из бесчисленных частей, к поддержке нескольких основных функциональных модулей.
• Границы четкие, развитие плавное.Это заставляет вас тщательно подумать в начале проектирования: какие функции естественным образом должны сочетаться друг с другом? Это создает границы модулей, которые больше соответствуют характеру бизнеса, а не техническому удобству. Команды разработчиков могут работать над целостным, сплоченным функциональным подразделением, сокращая потери на координацию между командами.

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

Как решить, где его использовать?

Подходит не везде. Подумайте о своей системе:

• Есть ли несколько сервисов с чрезвычайно высокой частотой звонков и огромными объемами обмена данными?
• Должны ли они поддерживать строгую согласованность данных, как если бы они были неделимым целым?
• Всегда ли их неудачи и успехи связаны друг с другом: один процветает, а другой страдает?

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

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

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

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

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