Микросервисы, не позволяйте им стать «заклинившим соединением» вашей механической системы.

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

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

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

Когда .NET встречается с микросервисами: не любое разделение называется «развязкой».

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

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

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

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

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

мощностьПерспектива: спроектируйте архитектуру как трансмиссию.

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

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

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

«Тогда как нам «общаться» между сервисами самым быстрым и стабильным способом?» Это следующий вопрос, который мы часто слышим. Ответ не уникален. Иногда достаточно легковесного HTTP API, а иногда необходима высокопроизводительная платформа, такая как gRPC. Для доставки инструкций, требующей высокой надежности, можно ввести модель, управляемую событиями, чтобы гарантировать, что ключевые действия не будут потеряны. Это похоже на выбор разных муфт для разных нужд трансмиссии — жестких, эластичных или карданных, это зависит от конкретного сценария.

Избегайте ловушки: шитье хуже, чем механическое копирование

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

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

• Сначала разграничьте в соответствии с бизнес-возможностями, а затем рассмотрите техническое разделение.:Спросите себя, является ли этот функциональный модуль относительно независимым с точки зрения бизнес-логики? Отличается ли частота изменений от других частей? Если ответ положительный, это может быть кандидат на службу.
• Чем проще общение, тем лучше: Если его можно вызвать синхронно, он не обязательно должен быть асинхронным; если его можно передать напрямую, его не обязательно передавать через очередь сообщений. С каждым дополнительным уровнем возникают дополнительные точки задержки и сбоя.
• Разрешить соответствующую «избыточность» между службами: Не каждый сервис должен быть на 100% без сохранения состояния. Иногда, чтобы уменьшить количество обращений по сети, стоит разрешить службе кэшировать некоторые важные данные, при условии, что будут решены проблемы согласованности.

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

Написано: Надежность – единственное постоянное требование

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

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

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

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

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