Что наиболее важно знать разработчикам, когда речь заходит о разработке приложений для микросервисов? Многие организации переходят на микросервисы по одной причине: гибкость. Способность быстро создавать и изменять компоненты таким образом, чтобы обеспечить максимальную отдачу для бизнеса, имеет решающее значение в мире, где ваши конкуренты находятся на расстоянии одного клика, а время выхода на рынок – это все. Однако вы, разработчик в своей организации, также знаете, что производительность ваших операционных систем имеет значение, и независимо от того, насколько гибкими микросервисы позволяют быть вашей команде, перед вами стоит задача как быстрой доставки, так и обеспечения работоспособности операционной системы при пиковой нагрузке. Для достижения гибкости и производительности многие команды разработчиков используют микросервисы, управляемые событиями. Итак, что вам нужно знать, чтобы добиться успеха?
В двух словах, вам нужно знать:
- Основы обмена сообщениями – его преимущества и различные модели общения
- Распространенные ложные предположения о распределенных вычислениях, которые делают разработчики
- Как архитектура, управляемая событиями, может помочь вам
- Почему для ваших микросервисов стоит выбрать хореографию, а не оркестровку
- Почему вы должны принять конечную последовательность
- Фреймворки, поддерживающие разработку микросервисов, управляемых событиями
- Инструменты для визуализации и хореографии ваших микросервисов
Примечание: Это сообщение в блоге было недавно обновлено 7 июля 2020 года
1. Основы обмена сообщениями
Использование преимуществ разработки приложений для микросервисов на вашем предприятии требует более широкого понимания шаблонов обмена сообщениями для микросервисов, управляемых событиями и когда их использовать.
Использование обмена сообщениями для обмена данными между микросервисами позволяет вам реализовать эти преимущества:
- Простое, масштабируемое подключение
- Простота и высокая доступность
- Простая масштабируемость производителя/потребителя
- Возможность публикации/подписки, фильтрации сообщений, маршрутизации и распространения
- Разделение ваших производителей и потребителей
Чтобы узнать более подробную информацию об этих преимуществах, я предлагаю вам прочитать это сообщение в блоге .
2. Ложные предположения о распределенных вычислениях
Прошло более 20 лет с тех пор, как Питер Дойч и Джеймс Гослинг разработали 8 заблуждений распределенных вычислений , но эти восемь ложных предположений все еще делаются сегодня разработчиками, новичками в распределенных приложениях.
Все восемь ошибок актуальны, но я выделил жирным шрифтом те, которые особенно важны в мире разработки приложений для микросервисов, потому что чем меньше вы делаете каждый микросервис, тем больше количество ваших сервисов и чем больше количество сервисов, тем больше эти ошибки повлияют на вашу стабильность и пользовательский опыт/производительность системы.
- Сеть надежна
- Задержка равна нулю
- Пропускная способность бесконечна
- Сеть защищена
- Топология не меняется
- Есть один администратор
- Транспортные расходы равны нулю
- Сеть однородна
Проблема заключается в том, что микросервисы требуют подключения/данных для выполнения своих функций и обеспечения бизнес-ценности, а сбор/передача данных в значительной степени игнорируются, настолько, что инструментарий сильно отстает. Например, продукты управления API/шлюза поддерживают только синхронные шаблоны обмена запросами/ответами, что в сочетании с ошибками, отмеченными выше, усугубляет проблемы распределенных вычислений. Многие из этих проблем можно свести к минимуму, правильно внедрив архитектуру, управляемую событиями.
3. Преимущество архитектуры приложений, управляемой событиями
В отличие от сервис-ориентированного дизайна, который является синхронным и блокирующим, дизайн, основанный на событиях, неблокирующий и использует множество обратных вызовов . Событийно-ориентированный дизайн не является новой концепцией, и вы даже можете быть знакомы с ним по использованию шаблонов программирования, таких как шаблон реактора или шаблон observer/| . Концепции, используемые этими шаблонами программирования, могут быть применены к архитектуре микросервисов, управляемых событиями, с использованием архитектурных шаблонов, таких как публикация-подписка , для достижения разделения служб, независимой масштабируемости и двунаправленной связи “один ко многим”.
Первым шагом на пути к принятию мышления, основанного на событиях, является изменение вашего подхода к проектированию и архитектуре решений. Первоначально тенденция состоит в том, чтобы рассматривать все взаимодействия между службами как серию в последовательности вызовов службы запроса/ответа. На самом деле, если вы или ваша команда используете терминологию “вызова”, “запроса” или “вызова”, то это верный признак того, что вы все еще мыслите в парадигме запроса/ответа.
Вместо этого попробуйте следующее: “Какие события должна обрабатывать моя служба?” и “Какие события будет выдавать моя служба?”
4. Преимущества хореографии в микросервисах
Как только вы примете мышление, основанное на событиях, вам нужно перейти от оркестровки к хореографии . Разработчикам свойственно мыслить в терминах “служба A вызовет службу B, которая вызовет службу C”, а затем реализует эту модель с помощью цепочки вызовов (a-> b> c) или путем создания службы orchestrator таким образом, что x-> a, затем x-> b, затем x-> c. Оба подхода приведут к хаосу, когда вступят в силу реалии распределенных вычислений, особенно когда вы начнете масштабироваться.
Оркестровка против Хореография, Источник: Thoughtworks
Альтернатива – следовать философии хореографии. Услуги должны реагировать на изменения в окружающей среде, и выгоды от этого огромны:
- Повышение гибкости : команды гибких разработчиков более независимы и значительно меньше подвержены влиянию изменений в других сервисах.
- Службы меньше/проще : от каждой службы не требуется сложной обработки ошибок при сбое нижестоящей службы или сети. Кому нравится писать обработку ошибок??? Только не я!
- Меньше связи с сервисом : Сервисы не знают о существовании других сервисов.
- Позволяет выполнять мелкозернистое масштабирование : Каждая услуга может быть независимо увеличена или уменьшена в зависимости от спроса. Это обеспечивает хороший пользовательский интерфейс и меньшую трату компьютерных ресурсов.
- Легко добавлять новые сервисы : Благодаря меньшему взаимодействию новая служба может подключаться к Сети, использовать события и внедрять новые функциональные возможности без изменений в какой-либо другой службе.
Этот список преимуществ не предоставляется бесплатно; здесь нет серебряной пули…
В этом случае в центре внимания становится согласованность состояния, поскольку временное отключение службы означает, что изменения состояния события могут быть обработаны не сразу. В принципе, как мы справляемся с этим негативным побочным эффектом?
5. Конечная согласованность в микросервисах
Конечная согласованность – это идея о том, что согласованность произойдет в будущем, и это означает принятие того, что в течение некоторого времени все может быть не синхронизировано. Это шаблон и концепция, которые позволяют разработчикам избегать использования неприятных транзакций XA. Задача платформы событий/обмена сообщениями заключается в том, чтобы гарантировать, что эти события изменения домена никогда не будут потеряны до того, как они будут надлежащим образом обработаны службой и подтверждены.
Некоторые считают, что единственным преимуществом конечной согласованности является производительность, но реальным преимуществом является разделение микросервисов, поскольку отдельные службы просто воздействуют на события, которые их интересуют.
6. Платформы разработки Микросервисов, управляемых событиями
Как разработчик, вы хотите иметь возможность легко писать чистый код, который позволит вам быстрее предоставлять функциональные возможности. Таким образом, язык разработки и связанные с ним инструменты становятся важными. В то время как архитектуры, управляемые событиями, позволяют нам разделять наши микросервисы и выбирать различные технологии для реализации каждого из них, рекомендуется выбирать стандартный язык/фреймворк, который наилучшим образом соответствует набору навыков вашей команды, и отклоняться только при необходимости.
Для многих команд разработчиков их набор навыков обычно включает опыт использования Spring framework с Java (и другими языками на основе JVM, поддерживаемыми Spring). Этот опыт привел к тому, что Spring Boot стала самой популярной платформой для разработки приложений для микросервисов в организациях. Его внедрение продолжает расти, и, что самое приятное, он имеет встроенную поддержку управляемых событиями микросервисов через Spring Cloud Stream.
Spring Cloud Stream – это платформа для создания масштабируемых, управляемых событиями микросервисов, подключенных с помощью общих брокеров событий (связующее утешение доступно здесь . Помимо предоставления основы реализации, Spring Cloud Stream также определяет независимую от поставщика терминологию для сообщества, управляемого событиями, включая определение source и приемник приложений, которые отправляют или получают события по каналам .
Если вам интересно, я углублюсь в создание микросервисов с использованием Spring Cloud Stream и генератора кода Async API в this post и это видео .
7. Моделируйте и визуализируйте микросервисы в Вашем событийном процессе
Как обсуждалось ранее, одним из преимуществ хореографии ваших микросервисов с использованием архитектуры, управляемой событиями, является достижение меньшего взаимодействия служб. Но это преимущество само по себе создает некоторые проблемы. В частности, когда ваши производители и потребители не заботятся о существовании друг друга, это может затруднить моделирование вашей архитектуры во время разработки и еще труднее понять, какие события происходят во время выполнения.
Попытки решить эту проблему предпринимались многими различными организациями различными способами, но до недавнего времени не было всеобъемлющего решения, доступного для широких масс. Внедрение портала событий Solace PubSub + решает эти проблемы, позволяя вам визуализировать, управлять и управлять вашими микросервисами во время разработки и предоставляя функции, которые позволяют вам обнаруживать, проверять и защищать ваши среды выполнения.
Узнайте больше о Зачем разработчикам нужен портал событий , где я описываю шаги, которые я предпринял для создания согласованных и масштабируемых микросервисов в течение нескольких минут.
Вывод
Хотя поначалу микросервисы, управляемые событиями, могут показаться сложными, за ними будущее большинства микросервисов и ИТ-стратегий. Станьте ниндзя в их развитии, выполнив эти шаги, и сделайте свою жизнь проще и проще!
Сообщение Как разрабатывать микросервисы: 7 соображений, основанных на событиях появилось впервые на Solace .
Оригинал: “https://dev.to/solacedevs/how-to-develop-microservices-7-event-driven-considerations-3gkp”