🏗️ 7 архитектурных паттернов, которые должен знать каждый программист

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

Если вы читаете эту статью, я думаю, вы знаете, что такое современные шаблоны (или паттерны) архитектурного проектирования. Для менее опытных читателей поясню, что архитектурные паттерны проектирования нужны для легкого масштабирования, даже если происходит замена в штате разработчиков.

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

Теперь вопрос: как разработчики решают эти проблемы? Один из способов — следовать зарекомендовавшим себя паттернам архитектурного проектирования.

1. Паттерн автоматического выключения (Circuit Breaker)

Книга Майкла Найгарда Release It! способствовала популяризации паттерна Circuit Breaker, который может предотвратить постоянные попытки приложения выполнить действие, которое, скорее всего, не будет выполнено, позволяя ему продолжить работу без ожидания устранения проблемы или траты тактов процессора на определение длительности ошибки.

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

Паттерн Circuit Breaker служит для иной цели, чем паттерн Retry. Retry позволяет приложению повторить операцию в надежде, что в следующий раз она будет успешной.

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

Данное изображение и все остальные взяты отсюда.

2. Паттерн источника событий (Event sourcing)

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

Event Sourcing определяет метод обработки действий с данными, которые запускаются серией событий, каждое из которых записывается в хранилище только для добавления. Код приложения доставляет серию событий в хранилище событий, происходит их сохранение, описывается каждое действие, которое произошло с данными. Каждое событие содержит описание набора изменений данных (например, AddedItemToOrder).

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

3. Паттерн SideCar

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

Дополнительный сервис не всегда является частью приложения, но связан с ним. Он следует за родительским приложением повсюду. Sidecars — это процедуры или службы, которые доставляются вместе с основным приложением. Коляска на мотоцикле сцеплена с одним мотоциклом, и у каждого мотоцикла может быть своя коляска. Подобным образом вспомогательная служба повторяет судьбу своего родительского приложения. Экземпляр sidecar развертывается и размещается вместе с каждым экземпляром приложения.

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

4. CQRS

CQRS расшифровывается как Command and Query Responsibility Segregation, паттерн, который изолирует процессы чтения и обновления хранилища данных. Внедрение CQRS в ваше приложение может повысить его производительность, масштабируемость и безопасность. Гибкость, полученная при переходе на CQRS, позволяет системе развиваться более эффективно с течением времени и предотвращает запуск инструкций по обновлению конфликтов слияния на уровне домена.

Отдельные модели запросов и обновлений упрощают проектирование и внедрение, хотя код CQRS не может быть автоматически сгенерирован из схемы базы данных с использованием методов формирования шаблонов, таких как инструменты O/RM (хотя вы можете добавить свои настройки поверх сгенерированного кода).

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

5. Паттерн Rate Limiting

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

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

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

Для ограничения службы с течением времени могут использоваться различные меры, в том числе:

— количество действий (например, 60 запросов);

— объем данных (например, 50 ГБ в минуту);

— относительная стоимость операций (например, 42 000 RU в секунду).

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

6. Strangler Fig

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

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

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

7. Паттерн Health Endpoint Monitoring

Паттерн Health Endpoint Monitoring можно использовать для обеспечения правильной работы программ и служб. Этот шаблон описывает, как функциональные проверки должны использоваться в приложении. Через открытые конечные точки внешние инструменты имеют регулярный доступ к этим проверкам.

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

Обычно проверка работоспособности сочетает в себе два элемента:

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

Схема видна на следующем рисунке.

Ничего не понял, но интересно. Нужна пояснительная бригада!

😃 Да, это не базовые концепции Python, которые осваиваются за несколько месяцев. Если появилось желание копнуть глубже, залетайте на наш курс «Архитектуры и шаблоны проектирования».

В течение 11 занятий вместе с преподавателем-практиком вы разберётесь в архитектурах приложений и паттернах, научитесь планировать архитектуру будущей системы. Выйдете на новый уровень в разработке ПО.

Программа курса полностью авторская, разработанная преподавателем Евгением Тюменцевым (В прошлом занимался профессионально разработкой многопоточных кросс-платформенных приложений на С++. Код, написанный 14 лет назад, до сих пор работает в составе IBM Watson. Один из результатов – успешная разработка технически сложного коммерческого проекта командой из 7 студентов), который будет сопровождать вас на протяжении всех занятий, а также проверять домашнее задание.

Доступ бессрочный. Длительность каждого урока: от 1 до 2-х часов. Дедлайнов нет, проходить можно в любое свободное время.

Материалы по теме

• 🐍 3 классических паттерна проектирования в Python: синглтон, декоратор и итератор
• 4 must-have паттерна проектирования в Python
  
• 📊 8 паттернов проектирования, которые должен знать каждый ML-разработчик
  

Источники

• https://web3usecase.co/7-architecture-design-patterns-you-wish-you-knew-before-interview-e9806bc01b6f