Содержание
За последние несколько лет в индустрии приложений наблюдался бурный рост внедрения архитектуры микросервисов. По мере того как предприятия все активнее вступают на путь микросервисов, понимание общих архитектурных паттернов приобретает первостепенное значение при разработке масштабного программного обеспечения.
Обещание оркестровки микросервисов обеспечить адаптивность, надежность и масштабируемость не должно стоить интеграции большей сложности или ощущения ”проприетарной системы” у команд разработчиков. Напротив, такая платформа, как Orkes Conductor, помогает разработчикам внедрять проверенные лучшие практики архитектуры микросервисов с использованием паттернов, сохраняя при этом свободу использования предпочтительных языков программирования.
В этом блоге представлен краткий обзор четырех значимых паттернов микросервисов, которые могут быть реализованы с помощью Orkes Conductor.
Паттерн CQRS с использованием источников событий
Command and Query Response Segregation (CQRS) - это паттерн проектирования микросервисов, который разделяет операции чтения и записи в приложении. Система CQRS состоит из 2 компонентов:
Команда - операция записи, которая изменяет внутреннее состояние объекта, но не возвращает ничего или только метаданные.
Запрос - операция чтения, которая возвращает информацию, но не изменяет внутреннее состояние.
С другой стороны, событийный сорсинг - это паттерн хранения данных, который фокусируется на хранении изменений в состоянии приложения в виде серии событий. Вместо того чтобы хранить текущее состояние, при сорсинге событий хранится и поддерживается журнал событий. Этот метод имеет ряд преимуществ, таких как согласованность данных, аудиторский след и т. д.
Согласованность данных - поскольку все изменения в приложении записываются в виде событий, вы можете гибко восстановить текущее состояние в любой момент, воспроизведя эти события. Это помогает обеспечить согласованность данных и устранить проблемы, которые могут возникнуть из-за одновременной записи.
Журнал аудита - поскольку в журнале событий фиксируется история всех действий в приложении, эти записи можно использовать для отладки, проверки соответствия и аудита.
Проще говоря, CQRS разделяет чтение и запись данных, а Event Sourcing сохраняет данные в виде серии событий для обеспечения согласованности данных и ведения журнала аудита всех действий в приложении. Эти два паттерна можно использовать вместе для создания надежных и масштабируемых архитектур микросервисов.
Паттерн Strangler
Преимущественное использование паттернов strangler в архитектуре микросервисов находит применение при переходе от монолитной архитектуры к архитектуре на основе микросервисов. Паттерн strangler помогает обновлять приложения с монолитных на микросервисы во время их работы в производстве.
Чтобы лучше понять концепцию, представьте, что ваш дом нуждается в капитальном ремонте. У вас есть два варианта: первый - полностью снести дом и построить новый с нуля, что займет несколько месяцев. Однако такой подход сопряжен со значительными неопределенностями. Вы не можете быть полностью уверены, что новый дом будет соответствовать вашим ожиданиям, и не сможете жить в нем в период реконструкции.
Второй вариант - поэтапная реконструкция, при которой вы можете обновлять по одному участку, убеждаясь, что каждый из них соответствует вашим ожиданиям, прежде чем переходить к следующему. Такой подход удобен тем, что вы можете продолжать жить в доме, пока проводите модернизацию. Кроме того, если ремонт не оправдает ваших ожиданий, исправить ситуацию будет гораздо проще, поскольку вы будете заниматься только одним участком за раз. Со временем вы получите полностью обновленный дом, который никогда не перестанет быть домом, и значительно снизите риски и перебои, связанные с полной перестройкой.
Когда дело доходит до миграции приложений, то есть если вы переносите свои приложения из монолита в микросервисы, вы можете адаптировать паттерн ”Душитель”. Здесь вместо того, чтобы полностью разбирать приложение и переписывать весь код, вы можете обновлять секции, не разрушая приложение. Продолжая этот процесс, вы можете в конечном итоге перенести все сервисы и компоненты для интеграции с новой прикладной системой, оставив прежнее приложение.
Паттерн Strangler Pattern необходим для модернизации, поскольку он позволяет организациям развивать свои старые монолитные системы без необходимости переписывать их полностью с нуля. Это очень важно для того, чтобы избежать рисков и ресурсоемкости полного переписывания.
Паттерн strangler имеет ряд преимуществ:
Снижает риск полного переписывания кода приложения. Помогает переносить микросервисную архитектуру шаг за шагом, не нарушая всей функциональности приложения. Экономически эффективен, поскольку постепенно модернизирует монолит, а не начинает с нуля. Максимально эффективное повторное использование существующего кода и ресурсов. Обеспечивает гибкость в выборе частей монолита для модернизации, позволяя компаниям в первую очередь сосредоточиться на наиболее важных областях.
Паттерн Strangler - это ценный подход к модернизации монолита.литических приложений при минимизации рисков и сбоев. Он позволяет организациям использовать пошаговый подход к переходу на более гибкую и масштабируемую архитектуру микросервисов, что делает его популярным выбором при модернизации.
Издатель / Подписчик
Паттерн Publisher / Subscriber, обычно называемый паттерном Pub / Sub, - это паттерн микросервисов, который обеспечивает свободное соединение между компонентами, что позволяет им взаимодействовать между собой. Для передачи сообщений между компонентами pub и sub используются брокеры сообщений.
В этом шаблоне издатели создают сообщения, а подписчики получают их и действуют в соответствии с ними без каких-либо прямых, явных связей между ними. Такой тип связи способствует масштабируемости, гибкости и развязке коммуникаций. Типичный шаблон pub/sub состоит из трех основных компонентов: издателя, подписчика и брокера сообщений.
Издатели производят события или сообщения, не зная, кто или что будет их потреблять. Подписчики проявляют интерес к определенным типам сообщений и реагируют на публикацию соответствующих сообщений. Асинхронный, событийный характер гарантирует, что микросервисы могут реагировать на события в реальном времени, не блокируя и не ожидая ответов.
Приложения для социальных сетей, которые вы используете ежедневно, являются отличным примером того, как паттерн Pub/Sub реализуется в реальном мире.
В приложениях для социальных сетей издатели отвечают за генерацию событий или сообщений. К таким событиям относятся загрузка фотографии, публикация обновления статуса и т. д. Каждое действие генерирует события, которые необходимо распространить среди заинтересованных людей. Роль издателя заключается в том, чтобы создавать эти события, не зная, кто или что будет их потреблять. Они отправляют события брокеру сообщений.
В приложениях для социальных сетей подписчиками являются пользователи и различные компоненты платформы, такие как система уведомлений, чат-сервисы и алгоритм подачи сообщений. Пользователи - это подписчики, которые проявляют интерес к определенным типам контента или пользователям, следуя за ними, ставя лайки или комментируя сообщения. Они реагируют на публикацию соответствующих событий. Например, когда вы следуете за пользователем, вы подписываетесь на его сообщения и получаете обновления, когда он публикует новый контент. Подписчики реагируют на события, отображая их в вашей ленте, отправляя уведомления или обновляя беседы в чате.
Брокеры сообщений выступают в роли посредников, которые направляют события от издателей к подписчикам. Они обеспечивают эффективную доставку событий нужным подписчикам. Социальные медиа включают в себя распространение событий среди подписчиков, отправку уведомлений пользователям и управление чатами в режиме реального времени. Брокеры сообщений помогают масштабировать систему, эффективно управляя распределением событий.
Паттерн Saga
Самый популярный паттерн микросервисов - паттерн saga, используемый для управления распределенными транзакциями и оркестровки сложных и длительных процессов. Он полезен для управления распределенными транзакциями в микросервисах, где традиционные ACID-транзакции сложно реализовать из-за распределенной и децентрализованной природы микросервисов.
Распределенные транзакции могут быть проблематичными в микросервисах из-за таких проблем, как двухфазная фиксация, что приводит к высокой задержке и потенциальным сбоям. Sagas разбивает большую транзакцию на более мелкие, отдельные транзакции внутри каждого микросервиса, гарантируя, что каждый сервис может выполнять свою часть самостоятельно, не требуя координации со стороны центрального органа.
Sagas помогают организовывать сложные и длительные процессы, определяя шаги и компенсирующие действия, чтобы мягко справляться со сбоями. Например, в приложении электронной коммерции Saga может управлять процессом размещения заказа, включающим службы инвентаризации, оплаты и доставки. Если на каком-то этапе произойдет сбой, может быть запущено компенсирующее действие, чтобы справиться с неудачей.
В своем предыдущем блоге о паттерне саги я подробно рассказывал о том, как вы можете реализовать паттерн саги с помощью Orkes Conductor в контексте приложения для заказа такси. Обратитесь к блогу для получения подробных примеров кода и примеров.
Заключение
В двух словах, в зависимости от сценария использования и требований бизнеса, вы можете реализовать любой паттерн микросервиса с помощью Orkes Conductor.
Conductor, созданный в Netflix и поддерживаемый Orkes, - это мощная платформа оркестровки с открытым исходным кодом для создания масштабируемых распределенных приложений в 10 раз быстрее. Conductor довольно гибок, и вы можете без проблем реализовать любой из паттернов микросервисов.
В Orkes мы предлагаем Orkes Cloud, корпоративную версию Conductor, на всех основных облачных платформах, включая AWS, Azure и GCP.
Начните работу с Orkes Playground и Orkes Cloud!
Кроме того, не забудьте оставить нам отзыв ⭐ о нашем репо Netflix Conductor.