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

В двух словах, шаблоны проектирования архитектуры — это шаблоны проектирования для проектирования высокого уровня.

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

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

Шаблон автоматического выключателя

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

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

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

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

Шаблон источника событий

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

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

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

Боковой шаблон

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

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

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

CQRS

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

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

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

Шаблон ограничения скорости

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

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

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

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

— количество действий (например, 60 запросов).
— объем данных (например, 50 ГБ в минуту).
— относительная стоимость операций (например, 42 000 RU в секунду) ).

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

Душитель рис

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

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

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

Шаблон мониторинга работоспособности конечной точки

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

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

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

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

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

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

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

Продолжайте суетиться, продолжайте мечтать. \м/