Шаблон отсеков

Azure

Шаблон "Переборка" — это тип структуры приложения, который терпим к сбою. В архитектуре переборки, также известной как архитектура на основе ячеек, элементы приложения изолированы в пулы, чтобы при сбое, остальные будут продолжать функционировать. Он называется в честь секционированных секций (переборки) корпуса корабля. Если корпус корабля будет поврежден, вода заполнит только один поврежденный отсек, и корабль останется на плаву.

Контекст и проблема

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

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

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

Решение

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

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

Такая схема предоставляет следующие преимущества:

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

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

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

Проблемы и рекомендации

• Проектируйте отсеки с учетом коммерческих и технических требований приложения.
• Если для проектирования микрослужб используется тактический DDD, границы секций должны соответствовать ограничивающим контекстам.
• Выбирая технологию разделения служб или потребителей, учитывайте доступный уровень изоляции и влияние этой технологии на стоимость решения, производительность и управляемость.
• Рассмотрите возможность объединить шаблон отсеков с шаблонами автоматического отключения и (или) регулирования, чтобы создать более сложный механизм обработки сбоев.
• Для распределения потребителей между отсеками попробуйте применить процессы, пулы потоков и семафоры. Проекты, такие как устойчивость4j и Polly , предлагают платформу для создания переборок потребителей.
• Для распределения служб между отсеками попробуйте применить отдельные виртуальные машины, контейнеры или процессы. Контейнеры — это компромиссное решение, обеспечивающее изоляцию ресурсов и низкие издержки.
• Службы, которые взаимодействуют с помощью асинхронных сообщений, можно разделить с помощью разных наборов очередей. Можно выделить для каждой очереди свой набор экземпляров, которые обрабатывают сообщения из нее, или определить специальный алгоритм для выборки и распределения сообщений в одной группе экземпляров.
• Определите уровень детализации для отсеков. Например, если вы хотите распределить клиенты между несколькими секциями, можно создать по одной секции для каждого клиента или поместить в одну секцию несколько клиентов.
• Отслеживайте производительность каждой секции и соглашение об уровне обслуживания.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

Этот шаблон может быть не подходит, если:

• Менее эффективное использование ресурсов может быть неприемлемым в проекте.
• Добавленная сложность не требуется

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон с массовой головой можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

Принцип	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя.	Стратегия изоляции сбоев, представленная посредством преднамеренной и полной сегментации между компонентами, пытается содержать ошибки только переборки, которая испытывает проблему, предотвращая влияние на другие переборки. - Критически важные потоки RE:02 - RE:07 Самосохранение
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Сегментация между компонентами помогает ограничить инциденты безопасности скомпрометированной переборкой. - Сегментация SE:04
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода.	Каждая переборка может быть масштабируемой по отдельности для эффективного удовлетворения потребностей задачи, которая инкапсулируется в переборке. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование

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

Пример

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

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

Следующие шаги

• Разработка надежных приложений Azure

Связанные ресурсы

• Шаблон размыкателя цепи
• Шаблон повтора
• Шаблон регулирования

Шаблон "Переборка" — это тип структуры приложения, который терпим к сбою. В архитектуре переборки, также известной как архитектура на основе ячеек, элементы приложения изолированы в пулы, чтобы при сбое, остальные будут продолжать функционировать. Он называется в честь секционированных секций (переборки) корпуса корабля. Если корпус корабля будет поврежден, вода заполнит только один поврежденный отсек, и корабль останется на плаву.

Контекст и проблема

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

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

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

Решение

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

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

Такая схема предоставляет следующие преимущества:

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

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

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

Проблемы и рекомендации

• Проектируйте отсеки с учетом коммерческих и технических требований приложения.
• Если для проектирования микрослужб используется тактический DDD, границы секций должны соответствовать ограничивающим контекстам.
• Выбирая технологию разделения служб или потребителей, учитывайте доступный уровень изоляции и влияние этой технологии на стоимость решения, производительность и управляемость.
• Рассмотрите возможность объединить шаблон отсеков с шаблонами автоматического отключения и (или) регулирования, чтобы создать более сложный механизм обработки сбоев.
• Для распределения потребителей между отсеками попробуйте применить процессы, пулы потоков и семафоры. Проекты, такие как устойчивость4j и Polly , предлагают платформу для создания переборок потребителей.
• Для распределения служб между отсеками попробуйте применить отдельные виртуальные машины, контейнеры или процессы. Контейнеры — это компромиссное решение, обеспечивающее изоляцию ресурсов и низкие издержки.
• Службы, которые взаимодействуют с помощью асинхронных сообщений, можно разделить с помощью разных наборов очередей. Можно выделить для каждой очереди свой набор экземпляров, которые обрабатывают сообщения из нее, или определить специальный алгоритм для выборки и распределения сообщений в одной группе экземпляров.
• Определите уровень детализации для отсеков. Например, если вы хотите распределить клиенты между несколькими секциями, можно создать по одной секции для каждого клиента или поместить в одну секцию несколько клиентов.
• Отслеживайте производительность каждой секции и соглашение об уровне обслуживания.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

Этот шаблон может быть не подходит, если:

• Менее эффективное использование ресурсов может быть неприемлемым в проекте.
• Добавленная сложность не требуется

Проектирование рабочей нагрузки

Архитектор должен оценить, как шаблон с массовой головой можно использовать в проектировании рабочей нагрузки для решения целей и принципов, описанных в основных принципах Платформы Azure Well-Architected Framework. Например:

Принцип	Как этот шаблон поддерживает цели основных компонентов
Решения по проектированию надежности помогают рабочей нагрузке стать устойчивой к сбоям и обеспечить восстановление до полнофункционального состояния после сбоя.	Стратегия изоляции сбоев, представленная посредством преднамеренной и полной сегментации между компонентами, пытается содержать ошибки только переборки, которая испытывает проблему, предотвращая влияние на другие переборки. - Критически важные потоки RE:02 - RE:07 Самосохранение
Решения по проектированию безопасности помогают обеспечить конфиденциальность, целостность и доступность данных и систем рабочей нагрузки.	Сегментация между компонентами помогает ограничить инциденты безопасности скомпрометированной переборкой. - Сегментация SE:04
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода.	Каждая переборка может быть масштабируемой по отдельности для эффективного удовлетворения потребностей задачи, которая инкапсулируется в переборке. - Планирование емкости PE:02 - Pe:05 Масштабирование и секционирование

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

Пример

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

apiVersion: v1
kind: Pod
metadata:
  name: drone-management
spec:
  containers:
  - name: drone-management-container
    image: drone-service
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "1"

Следующие шаги

• Разработка надежных приложений Azure

Связанные ресурсы

• Шаблон размыкателя цепи
• Шаблон повтора
• Шаблон регулирования