Выбор архитектуры похож на ее сборку: микросервисы, монолит или SOA, что сделает ваш механический проект более гибким?

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

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

Давайте сначала поговорим об этом «большом железном куске»: монолитной архитектуре.

Некоторым людям нравится объединять все функции в одно целое. Как и в некоторых старомодных механических контроллерах первых лет, печатная плата, драйвер и логика находятся на одной плате. Каковы преимущества? Простой. Его легко разработать, просто добавьте пакет при развертывании, и он довольно стабилен при первом запуске.

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

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

Модульный семинар: SOA (сервис-ориентированная архитектура)

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

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

Сборка в стиле Лего: микросервисы

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

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

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

Итак, как выбрать?

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

Несколько советов помогут вам организовать свои мысли:

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

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

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

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