Когда ваш проект застрял в дебатах «микросервисы или монолит»

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

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

Почему производительность оборудования должна влиять на ваши решения по программному обеспечению?

Кто-то спросил меня: «Мы используем микросервисы в серверной части. Следует ли также разделить часть управления двигателем на независимые модули?» На самом деле нет необходимости копировать его механически. Архитектура программного обеспечения решает проблемы масштабируемости и удобства обслуживания, а выбор оборудования фокусируется на точности, крутящем моменте и скорости отклика. Например, если вы проектируете автоматизированное устройство отображения, программное обеспечение можно часто итеративно обновлять, но рулевой механизм внутри работает точно с первого раза — у него нет шансов на «горячее обновление».

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

Так как же вырваться из этого круга?

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

Например, если вы создаете интерактивное устройство отображения:

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

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

Ответы на часто задаваемые вопросы

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

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

Невидимые детали, видимый результат

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

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

Итак, в следующий раз, когда у вас будет встреча…

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

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

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

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

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