Современные шаблоны проектирования архитектуры программного обеспечения для пр?
Перевод: Modern-Day Architecture Design Patterns for Software Professionals
Многие современные приложения необходимо создавать для предприятия, а иногда даже глобально для всего Интернета. Каждое приложение должно соответствовать требованиям масштабируемости, доступности, безопасности, надежности и отказоустойчивости. В этой статье я расскажу о некоторых шаблонах проектирования, которые помогают реализовать вышеупомянутые возможности. Я буду говорить о каждом шаблоне, о том, как использовать этот шаблон в облачной среде, и когда стоит использовать его, а когда нет. Некоторые из этих шаблонов не новы, но очень полезны в нынешнем облачном мире.
Вот список шаблонов, которые будут рассмотрены в этой статье:
- Circuit Breaker
- Command and Query Responsibility Segregation (CQRS)
- Event Sourcing
- Sidecar
- Backend-for-Frontend
- Strangler
Итак, приступим.
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 предлагает использовать разные модели данных для операций чтения и записи. Некоторые варианты также предлагают использовать отдельные хранилища данных для этих моделей.
Примечание: Большинство PaaS-баз данных в наши дни предоставляют возможность создавать реплики для чтения (Google Cloud SQL, Azure SQL DB, Amazon RDS и т. д.) хранилищ данных, что помогает значительно упростить репликацию данных.
Многие корпоративные базы данных также предоставляют эту возможность, если вы имеете дело с локальными базами данных.
Примечание: в наши дни некоторые люди также предпочитают реализовывать реплики чтения как быстрые и производительные базы данных NoSQL, такие как MongoDB и Elasticsearch.
Когда использовать
- Когда вы смотрите на масштабирование приложения, ожидающего огромное количество операций чтения и записи
- Если вы хотите настроить производительность операций чтения и записи отдельно
- Когда ваши операции чтения в порядке, выполняются в реальном времени или, в конечном итоге, согласованы.
Когда не использовать
- Когда вы создаете обычное приложение CRUD, которое не ожидает большого количества операций чтения и записи одновременно.
Event Sourcing
Event Sourcing – это интересный шаблон проектирования, в котором последовательность событий домена хранится в виде журнала, а агрегированное представление журнала дает текущее состояние приложения.
Этот шаблон обычно используется для систем, которые не могут позволить себе блокировку хранилища данных и которым необходимо вести аудит и историю событий – например, такие приложения, как бронирование отелей / конференций / мест.
На пример в системе бронирования номеров в отелях, ожидается, что пользователи будут бронировать или отменять бронирование. Здесь вам нужно сохранить бронирования и отмены как серию событий. Перед каждым бронированием в сводном представлении отображаются доступные номера в журналах событий.
Примечание. Большинство поставщиков облачных сервисов поддерживают сервисы обмена сообщениями, такие как Google Pub / Sub, Azure Service Bus, AWS SQS и т. д. Эти сервисы в сочетании с надежными согласованными хранилищами данных могут использоваться для реализации этого шаблона.
Когда использовать
- Когда обычных операций CRUD недостаточно для удовлетворения требований
- Хорошо подходит для систем бронирования мест – таких как автобус, поезд, конференции, кинозалы и т. д. – или систем электронной коммерции, которые состоят из событий, таких как операции с тележкой, платежи и т. д.
- Когда требуется строгий аудит и воспроизведение событий для создания текущего и прошлого состояния приложений.
Когда не использовать
- Когда регулярные операции CRUD достаточно хороши для удовлетворения требований пользователя.
Sidecar
Паттерн Sidecar стал популярным с появлением микросервисов. В этом шаблоне вы развертываете компонент приложения в отдельный процесс или контейнер. Это помогает добиться абстракции и инкапсуляции.
Envoy Proxy – один из самых популярных и широко используемых дополнительных прокси. Это поможет вам сохранить основные функции приложения отдельно, используя сопроводительный элемент для изоляции общих функций, таких как сеть, наблюдаемость и безопасность.
Такие коляски могут помочь абстрагироваться от типа общения L4 / L7. Sidecars, такие как Envoy Proxies, даже помогают достичь более высокой безопасности за счет реализации взаимного TLS.
Вы можете использовать это в сочетании со служебной сеткой для улучшения связи и безопасности между различными микросервисами.
Когда использовать
- Когда вы имеете дело с несколькими и разнородными микросервисами в объеме продукта
- Когда вы имеете дело с устаревшими приложениями, которые обычно не справляются с проблемами связи и безопасности нового поколения
Когда не использовать
- Когда вы имеете дело с ограниченным количеством служб, которым необходимо взаимодействовать друг с другом
- Небольшие приложения, развертывание которых может быть неэкономичным или удобным для эксплуатации.
Backend-for-Frontend (BFF)
В типичном цикле разработки продукта бэкенд-инженеры отвечают за создание сервисов, которые взаимодействуют с хранилищами данных, а фронтенд-инженеры заботятся о создании пользовательских интерфейсов. В наши дни приложения необходимо создавать с учетом использования мобильных устройств и компьютеров.
Несмотря на то, что разрыв между мобильными и настольными устройствами с точки зрения аппаратного обеспечения стремительно сокращается, подключение и использование мобильных устройств по-прежнему остаются проблематичными.
В таких сценариях паттерн BFF становятся весьма удобным. В рамках него вы должны создавать / настраивать серверные службы для конкретного интерфейса.
Чтобы оптимизировать производительность мобильных клиентов, вы можете создать отдельную внутреннюю службу, которая будет отвечать облегченными ответами с разбивкой на страницы.
Вы также можете использовать этот шаблон для агрегирования различных сервисов, чтобы уменьшить нагрузку на общение между сервисами и не превращать ее в подобие чата.
Примечание: Если вы используете шлюз API, шаблон BFF можно легко реализовать в самом шлюзе, и вам не нужно поддерживать отдельные службы.
Когда использовать
- Если вы хотите чтобы ваш продукт / услуга был доступен для разных клиентов, например для настольных и мобильных устройств.
- Если вы хотите оптимизировать ответ для определенного типа клиента.
- Когда вы хотите уменьшить общение между мобильными клиентами и различными сервисами.
Когда не использовать
- Когда ожидается, что пользователи приложения будут использовать единый пользовательский интерфейс.
- Когда ожидается, что мобильные и настольные приложения будут предоставлять аналогичную информацию и обеспечивать аналогичные функции.
Strangler
Если вы работаете в организации, которая находится на пути к модернизации приложений, то шаблон проектирования Strangler просто необходим. Он рекомендует создать фасад поверх вашего унаследованного и нового приложения, предоставляя потребителям абстрактное представление.
Этот шаблон отделяет потребителей от действий по миграции.
Примечание: В типичной ИТ-организации, если вы переходите с одной ERP-системы на другую, этот тип шаблона чрезвычайно полезен. Если вы используете шлюз API, становится еще проще реализовать это в самом прокси-сервере шлюза.
Вам нужно только решить, хотите ли вы сохранить фасад в конце миграции или удалить его.
Когда использовать
- Когда вы переносите или модернизируете сложное, с большим количеством зависимостей приложение, такое как ERP-система.
Когда не использовать
- Когда миграция проста, и прямая замена – лучший вариант.