6 сентября 2024 2432
Читайте про наиболее популярные шаблоны облачного проектирования: шаблон Bulkhead и шаблон Sidecar.

Облачные сервисы на сегодняшний день стали неотъемлемой частью ландшафта ИТ. Множество различных приложений размещаются и успешно функционируют в облаках. У облачных решений есть целый ряд преимуществ, например, мы можем легко масштабировать решение в случае, если увеличилась нагрузка. Также можем выполнить поэтапное обновление компонентов приложения, прозрачно для пользователей решения, благодаря использованию нескольких экземпляров сервиса.

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


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


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


Шаблон Sidecar

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


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


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


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

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


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


В примере ниже представлены два контейнера: Primary Application и Sidecar. Основная функциональность приложения реализована в Primary, а вот вспомогательные сервисы представлены в Sidecar. Между основным приложением и вспомогательным контейнером осуществляется постоянное двустороннее взаимодействие.



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


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


Шаблон Bulkhead

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


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


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


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


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



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


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


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

Последние статьи в блоге

Карьерный трек аналитика: от базы к экспертизе

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

27 июня 2025

Почему именно сейчас стоит учиться на бизнес-аналитика уровня Middle. «Руководство BABOK» в подарок участникам программы!

Вы в ИТ, вам за 30. Вроде бы всё хорошо — есть работа, скиллы, стабильность. Но в воздухе — тревожность. Проекты замораживаются. Бизнес урезает бюджеты. От ИТ ждут не просто задач, а конкретного влияния на прибыль.

25 июня 2025

Уничтожит ли ИИ-генератор кода профессию разработчика?

С появлением ИИ-инструментов, а также в связи недавним анонсом Canva Code, который генерирует код за пару кликов, многие задумались: не станут ли такие инструмент угрозой для разработчиков? Давайте разберемся, есть ли здесь реальные риски, или это все же преувеличения.

23 июня 2025

Проектное резюме консультанта 1С: карьерный инструмент, чтобы выделиться среди других кандидатов

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

Новости
19 июня 2025

Выбор карьеры: Менеджер бизнес-процессов или Бизнес-аналитик уровня Middle?

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

Новости
18 июня 2025

В Учебном центре IBS планируется запуск курсов по продуктам TData

Читайте о стратегическом соглашении TData и IBS и наших новых курсах

11 июня 2025

Компетенции бизнес-аналитиков: Junior и Middle в сравнении

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

Новости
05 июня 2025

Лимит на сбои. Как понять, что система перегружена, а не просто плохо сделана?

Оценить производительность системы непросто, а контролировать еще сложнее. Как сделать так, чтобы внедряемая или уже эксплуатируемая система справлялась с нагрузками? Можно ли в этом вопросе полностью положиться на разработчиков ПО или вендоров? И кто в итоге будет отвечать за все простои системы? Рассказывает Николай Марченко, директор отделения нагрузочного тестирования компании IBS. Начать следует с того, что разбираться с последствиями возможных сбоев в любом случае придется тем, кто работает непосредственно с системой. Поэтому о вопросах производительности лучше задуматься еще на этапе внедрения.

Новости
03 июня 2025

Кто такой аналитик 1С?

Аналитик 1С — это специалист, который занимается оптимизацией бизнес-процессов с использованием программного обеспечения 1С. Его задача — анализировать существующие процессы, выявлять недостатки и разрабатывать решения для повышения эффективности. Аналитик переводит бизнес-требования в технические задания для разработчиков, становясь мостом между пользователями и ИТ-отделом. Эта роль требует как технических знаний, так и навыков коммуникации, что позволяет вносить значительный вклад в развитие компании и улучшение её конкурентоспособности.

Новости
28 мая 2025

Разбор задачи: UML-диаграмма классов для системы регистрации на курсы

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

22 мая 2025

Бизнес-аналитик и системный аналитик в ИТ: кто есть кто и в чем разница

Современные ИТ-проекты — будь то корпоративные решения, мобильные приложения или интеграционные платформы — требуют точного понимания как бизнес-целей, так и технических ограничений. На пересечении этих задач появляются две ключевые роли: бизнес-аналитик (БА) и системный аналитик (СА). Несмотря на схожесть направлений деятельности, эти специалисты действуют на разных уровнях и выполняют разные функции. Рассмотрим, кто они, каковы их зоны ответственности, чем они похожи, а чем принципиально отличаются.

21 мая 2025

5 распространенных ошибок в работе системных аналитиков

Ошибки системных аналитиков редко видны сразу, но последствия могут быть весьма заметными. Срыв сроков, недовольство заказчика, бесконечные правки требований, ощущение, что проект «расползается» — это часто не проблема менеджмента, а не выявленные вовремя аналитические ошибки и риски. Мы регулярно анализируем дипломные проекты выпускников курса «Системный аналитик» — не ради оценок, а чтобы понять, какие трудности реально возникают на практике, и обозначить направления для дальнейшего развития навыков. Даже у мотивированных специалистов с практическим опытом есть «слепые» зоны. Где-то не хватает чёткости в декомпозиции, где-то — качества проработки связей между сущностями, понимания архитектуры. Даже отсутствие умения аргументировать выбор решений перед бизнесом может негативно повлиять на проект. Мы вместе с Екатериной Тихомировой — практикующим аналитиком с более чем десятилетним опытом — разобрали некоторые типичные ошибки и риски, и способы, как их предотвратить.

20 мая 2025

Итоги работы Центра сертификации IBS

Центр сертификации IBS начал свою работу в апреле 2023 года, поэтому мы традиционно подводим итоги работы в апреле-мае. Прошедший год стал для нас периодом важных изменений. В 2024 году произошло несколько знаковых событий: наша команда обновила программы сертификации системных аналитиков и Java-разработчиков, подготовила к запуску сертификацию бизнес-аналитиков, получила аккредитацию от АПКИТ и стала обладателем Гран-при премии «Смарт пирамида». Рассказываем подробнее, каких результатов мы достигли в уходящем году и как это отразилось на нашей работе.

Новости
19 мая 2025

Какой метод тестирования выбрать: черный, белый или серый ящики?

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

14 мая 2025

Удостоверение, диплом и сертификат: в чем разница и что выбрать

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

12 мая 2025

Выгодный май — на курсы залетай!

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

05 мая 2025

Кейс: кастомизация курса по Jira

Кейс по проведению кастомизированного курса «Основы Jira» для крупной российской компании, занимающейся производством цифровой техники.

05 мая 2025

Зачем специалистам по 1С изучать системный анализ и архитектуру ПО

Как системный анализ и архитектура ПО помогают эффективнее работать в 1С.

29 апреля 2025

Банка Nutella, IT, ESG — что общего?

Когда вы читали этикетку на продукте не из-за состава, а из-за ESG-маркировки?

25 апреля 2025

Каковы плюсы и минусы монолитной и микросервисной архитектуры при разработке ИТ-продуктов?

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

25 апреля 2025

Не нашли, что искали? — Просто напишите, и мы поможем

Корпоративное обучение Оценка персонала Сертификация О нас Стань тренером Блог
Пользователь только что записался на курс ""
Спасибо!
Форма отправлена успешно.