Мысли вслух Разработка Управление проектами

Современные шаблоны проектирования архитектуры программного обеспечения для профессионалов

-
3 января, 2021

Перевод: Modern-Day Architecture Design Patterns for Software Professionals

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

Вот список шаблонов, которые будут рассмотрены в этой статье:

  1. Circuit Breaker
  2. Command and Query Responsibility Segregation (CQRS)
  3. Event Sourcing
  4. Sidecar
  5. Backend-for-Frontend
  6. Strangler

Итак, приступим.

Circuit Breaker

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

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

Примерная схема реализации паттерна Circuit Breaker

На приведенной выше диаграмме демонстрируется реализация паттерна Circuit Breaker, где, когда служба 1 понимает, что при вызове службы 2 существуют непрерывные сбои / тайм-ауты, вместо повторной попытки служба 1 отправляет вызовы службе 2 и возвращает отклик на резерв.

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

Если вы используете шлюзы API или дополнительные прокси-серверы, такие как Envoy, то этого можно достичь на уровне самого прокси.

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

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

Когда использовать

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

Когда не использовать

  • Когда вы имеете дело с локальными зависимостями, прерыватель цепи может создавать накладные расход

Command and Query Responsibility Segregation (CQRS)

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

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

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

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

Пример реализации паттерна CQRS

Примечание: Большинство PaaS-баз данных в наши дни предоставляют возможность создавать реплики для чтения (Google Cloud SQL, Azure SQL DB, Amazon RDS и т. д.) хранилищ данных, что помогает значительно упростить репликацию данных.

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

Примечание: в наши дни некоторые люди также предпочитают реализовывать реплики чтения как быстрые и производительные базы данных NoSQL, такие как MongoDB и Elasticsearch.

Когда использовать

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

Когда не использовать

  • Когда вы создаете обычное приложение CRUD, которое не ожидает большого количества операций чтения и записи одновременно.

Event Sourcing

Event Sourcing — это интересный шаблон проектирования, в котором последовательность событий домена хранится в виде журнала, а агрегированное представление журнала дает текущее состояние приложения.

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

Пример реализации паттерна Event Sourcing

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

Примечание. Большинство поставщиков облачных сервисов поддерживают сервисы обмена сообщениями, такие как Google Pub / Sub, Azure Service Bus, AWS SQS и т. д. Эти сервисы в сочетании с надежными согласованными хранилищами данных могут использоваться для реализации этого шаблона.

Когда использовать

  • Когда обычных операций CRUD недостаточно для удовлетворения требований
  • Хорошо подходит для систем бронирования мест — таких как автобус, поезд, конференции, кинозалы и т. д. — или систем электронной коммерции, которые состоят из событий, таких как операции с тележкой, платежи и т. д.
  • Когда требуется строгий аудит и воспроизведение событий для создания текущего и прошлого состояния приложений.

Когда не использовать

  • Когда регулярные операции CRUD достаточно хороши для удовлетворения требований пользователя.

Sidecar

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

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

Пример паттерна Sidecar

Такие коляски могут помочь абстрагироваться от типа общения L4 / L7. Sidecars, такие как Envoy Proxies, даже помогают достичь более высокой безопасности за счет реализации взаимного TLS.

Вы можете использовать это в сочетании со служебной сеткой для улучшения связи и безопасности между различными микросервисами.

Когда использовать

  • Когда вы имеете дело с несколькими и разнородными микросервисами в объеме продукта
  • Когда вы имеете дело с устаревшими приложениями, которые обычно не справляются с проблемами связи и безопасности нового поколения

Когда не использовать

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

Backend-for-Frontend (BFF)

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

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

В таких сценариях паттерн BFF становятся весьма удобным. В рамках него вы должны создавать / настраивать серверные службы для конкретного интерфейса.

Схема паттерна BFF

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

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

Примечание: Если вы используете шлюз API, шаблон BFF можно легко реализовать в самом шлюзе, и вам не нужно поддерживать отдельные службы.

Когда использовать

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

Когда не использовать

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

Strangler

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

Паттерн Strangler

Этот шаблон отделяет потребителей от действий по миграции.

Примечание: В типичной ИТ-организации, если вы переходите с одной ERP-системы на другую, этот тип шаблона чрезвычайно полезен. Если вы используете шлюз API, становится еще проще реализовать это в самом прокси-сервере шлюза.

Вам нужно только решить, хотите ли вы сохранить фасад в конце миграции или удалить его.

Когда использовать

  • Когда вы переносите или модернизируете сложное, с большим количеством зависимостей приложение, такое как ERP-система.

Когда не использовать

  • Когда миграция проста, и прямая замена — лучший вариант.
ТЕГИ
RELATED POSTS

ОСТАВИТЬ КОММЕНТАРИЙ

Николай Сарры
Харьков, Украина

Меня зовут Николай, и вот уже 5 лет я руководитель IT-проектов.Добро пожаловать в мой лофт с заметками, статьями, идеями и мыслями по управлению проектами, использованию гибких методологий разработки.Здесь собраны мои мысли, решения, заметки и статьи. В основном по управлению проектами, PHP-разработке и используемым инструментам, обзоры прочитанных статей, тезисы посещенных конференций.