---
title: Микросервисы
questionDates:
  q-transfer-0333: '2026-10-01'
  q-transfer-0334: '2026-10-01'
seo:
  description: >-
    Тема «Микросервисы» для собеседования Systems Analyst. Знакомы ли вы с
    микросервисами? Что такое Хореография и Оркестрация?
  title: Микросервисы — Systems Analyst
---

[Все темы Systems Analyst](/prep/systems-analyst)

## <strong>Знакомы ли вы с микросервисами?</strong> [#q-14bee738d69b81eca609fa64565aba72]

Да, микросервисы — это подход к разработке программного обеспечения, при котором приложение строится как набор маленьких, автономных сервисов, каждый из которых решает конкретную бизнес-задачу. Основные характеристики микросервисной архитектуры&#58;

1. <strong>Независимость&#58;</strong> Каждый микросервис может быть разработан,
   развернут и масштабирован отдельно от других.

1. <strong>Гибкость и масштабируемость&#58;</strong> Изменение и масштабирование
   одного сервиса не влияет на работу других.

1. <strong>Легкость в развертывании и обновлении&#58;</strong> Благодаря
   отдельному развертыванию, обновления микросервисов проще и безопаснее.

1. <strong>Язык и технология&#58;</strong> Каждый микросервис может быть написан
   на разных языках программирования и использовать разные технологии.

1. Изоляция сбоев&#58; отдельный сервис может отказать независимо, но зависимые сервисы тоже могут пострадать. Таймауты, ограничения повторов и изоляция ресурсов уменьшают риск каскадных отказов.

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

:::note[Ссылки для изучения]

1. [Микросервисная архитектура: устройство, преимущества и сложности](https://learn.microsoft.com/ru-ru/azure/architecture/guide/architecture-styles/microservices)
   :::

---

## <strong>Что такое Хореография и Оркестрация?</strong> [#q-14bee738d69b818f916fff90b754d192]

Хореография и оркестрация — это два подхода к управлению взаимодействием микросервисов в распределённых системах&#58;

1. <strong>Хореография&#58;</strong> В этом подходе каждый микросервис знает о
   своих задачах и взаимодействует напрямую с другими сервисами по согласованным
   между ними правилам. Отсутствует централизованное управление, и вся логика
   распределена между участниками взаимодействия.

1. <strong>Оркестрация&#58;</strong> Здесь есть централизованный компонент,
   называемый оркестратором, который координирует действия микросервисов.
   Оркестратор управляет последовательностью вызовов и обеспечивает
   согласованное выполнение бизнес-процессов.

Различия&#58;

- <strong>Хореография</strong> подразумевает децентрализованный подход, где
  каждый сервис самостоятельно управляет своей логикой взаимодействия.

- <strong>Оркестрация</strong> предполагает централизованное управление
  оркестратором, который управляет и согласовывает действия сервисов.

:::note[Ссылки для изучения]

1. [Хореография и оркестрация взаимодействия сервисов — паттерн Saga](https://learn.microsoft.com/ru-ru/azure/architecture/patterns/saga)
   :::

---

## <strong>Какие достоинства и недостатки микросервисов вы знаете?</strong> [#q-14bee738d69b81dbad18f4684c7da402]

Микросервисы имеют ряд достоинств и недостатков&#58;

<strong>Достоинства</strong>
<strong>&#58;</strong>

1. <strong>Разделение на слабосвязанные компоненты&#58;</strong> Позволяет
   разрабатывать и поддерживать каждый сервис независимо.

1. <strong>Гибкость и масштабируемость&#58;</strong> Легкость в масштабировании
   отдельных сервисов в зависимости от нагрузки.

1. <strong>Технологическое разнообразие&#58;</strong> Разработчики могут
   выбирать технологии, наиболее подходящие для каждого сервиса.

1. <strong>Быстрая разработка и доставка&#58;</strong> Позволяют ускорить
   разработку новых функций и функциональных улучшений.

1. Изоляция сбоев&#58; отдельный сервис может отказать независимо, но зависимые сервисы тоже могут пострадать. Таймауты, ограничения повторов и изоляция ресурсов уменьшают риск каскадных отказов.

<strong>Недостатки</strong>
<strong>&#58;</strong>

1. <strong>Сложность управления&#58;</strong> Усложняется управление и
   мониторингом множества микросервисов.

1. <strong>Сетевая задержка&#58;</strong> Взаимодействие между сервисами через
   сеть может вызвать задержки.

1. <strong>Сложность тестирования&#58;</strong> Необходимость интеграционного
   тестирования между микросервисами.

1. <strong>Потребление ресурсов&#58;</strong> Для работы множества микросервисов
   требуются дополнительные ресурсы.

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

:::note[Ссылки для изучения]

1. [Микросервисы: преимущества и сложности распределённой архитектуры](https://learn.microsoft.com/ru-ru/azure/architecture/guide/architecture-styles/microservices)
   :::

---

## <strong>Расскажите про токен-авторизацию в микросервисах.</strong> [#q-14bee738d69b81d69ad6ef548379a2a5]

Токен-авторизация в микросервисах является методом обеспечения безопасности и аутентификации пользователей. Основные принципы&#58;

{/* prettier-ignore */}
1. <strong>Выдача токена (</strong><code>Token issuance</code><strong>)&#58;</strong> После аутентификации пользователя сервис выдает токен, который содержит информацию о пользователе и правах доступа.

1. <strong>Типы токенов&#58;</strong>

    - JWT содержит набор claims. Подписанный JWT обычно доступен для чтения после декодирования base64url; подпись защищает от подмены, а конфиденциальность требует шифрования, например JWE.

    - <strong>Opaque token&#58;</strong> Ссылка на информацию аутентификации, хранящаяся в базе данных или кэше.

1. Валидация JWT включает проверку подписи разрешённым алгоритмом, доверенного издателя, аудитории и срока действия. Проверка подписи не является расшифровкой. Для opaque token обычно нужна серверная проверка или introspection.

1. <strong>Обновление токена (</strong><code>Token refresh</code><strong>)&#58;</strong> Используется для продления срока действия токена без необходимости повторной аутентификации пользователя.

1. <strong>Использование в микросервисах&#58;</strong>

    - Каждый микросервис проверяет токен при получении запроса от клиента.

    - Общие сервисы аутентификации или аутентификационные шлюзы могут облегчить процесс валидации токена.

1. <strong>Преимущества&#58;</strong>

    - <strong>Безопасность&#58;</strong> Токены могут содержать ограниченный набор прав доступа.

    - <strong>Масштабируемость&#58;</strong> Управление доступом и аутентификацией может быть легко расширено на большое количество микросервисов.

    - <strong>Гибкость&#58;</strong> Возможность централизованного управления правами доступа и аутентификационными данными.

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

:::note[Ссылки для изучения]

1. [JWT и opaque-токены в API Gateway и микросервисах](https://habr.com/ru/articles/872918/)
1. [Проверка Bearer-токена: аудитория, издатель, подпись и срок действия](https://learn.microsoft.com/ru-ru/entra/identity-platform/scenario-protected-web-api-app-configuration)
   :::

---

## По каким признакам распознать распределённый монолит? [#q-transfer-0333]

Распределённый монолит выдаёт отсутствие независимости при формально раздельных сервисах. Изменение одной функции требует правок и одновременного релиза нескольких сервисов; схема общей БД связывает их сильнее API; длинные синхронные цепочки превращают локальный сбой в общий. Дополнительные признаки: циклические зависимости, общие библиотеки с бизнес-логикой, распределённая транзакция для обычного сценария и невозможность откатить или масштабировать сервис отдельно. Само наличие синхронных вызовов или общей технологии ещё не доказывает проблему. Главный тест: можно ли менять и выпускать один компонент без согласованного изменения остальных.

:::note[Ссылки для изучения]

1. [Признаки распределённого монолита: связанные релизы, общие данные и каскад отказов — Домклик](https://habr.com/ru/companies/domclick/articles/1050890/)
   :::

---

## Как определить границы микросервисов? [#q-transfer-0334]

Границы проводят вокруг бизнес-возможностей и правил, которые меняются вместе. Сначала выделяют владельцев данных, инварианты и операции, затем проверяют связность: внутри границы должно быть много совместной логики, между границами меньше. Данные и транзакции по возможности принадлежат одному сервису; межсервисные сценарии проектируют с учётом eventual consistency. У каждой границы нужен понятный владелец и возможность независимо разрабатывать, развёртывать и масштабировать компонент. Если почти каждое изменение пересекает несколько сервисов, границы выбраны неудачно. Размер кода и организационная схема полезны как ограничения, но не заменяют анализ домена.

:::note[Ссылки для изучения]

1. [Определение границ микросервисов: домен, связность и независимое развёртывание — Microsoft](https://learn.microsoft.com/ru-ru/azure/architecture/microservices/model/microservice-boundaries)
   :::