---
title: Микросервисы
seo:
  title: "Микросервисы — С# Developer"
  description: "Тема «Микросервисы» для собеседования С# Developer. Какую проблему решают микросервисы? Какие есть способы коммуникации микросервисов?"
---

[Все темы С# Developer](/s-developer)

## <strong>Какую проблему решают микросервисы?</strong> [#q-14bee738d69b81a6b540f1760517f150]

<strong>Микросервисы решают проблему монолитной архитектуры</strong>, улучшая
масштабируемость, гибкость и управляемость приложений.

#### Основные проблемы, решаемые микросервисами&#58;

{/* prettier-ignore */}
1. <strong>Масштабируемость&#58;</strong>

    - <strong>Проблема&#58;</strong> В монолитных приложениях сложно масштабировать отдельные компоненты.

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

1. <strong>Разделение обязанностей&#58;</strong>

    - <strong>Проблема&#58;</strong> Монолитные приложения часто имеют тесно связанные компоненты, что затрудняет поддержку и развитие.

    - <strong>Решение&#58;</strong> Микросервисы разделяют приложение на независимые сервисы с четко определенными обязанностями.

1. <strong>Гибкость разработки&#58;</strong>

    - <strong>Проблема&#58;</strong> В монолите изменения одного компонента могут затронуть другие части системы, что замедляет разработку.

    - <strong>Решение&#58;</strong> Микросервисы позволяют командам работать над разными сервисами одновременно, используя разные технологии и языки программирования.

1. <strong>Устойчивость к сбоям&#58;</strong>

    - <strong>Проблема&#58;</strong> Сбой в одном компоненте монолита может привести к отказу всего приложения.

    - Решение&#58; изоляция, таймауты и circuit breaker могут ограничить распространение сбоя. Без этих мер отказ зависимости может вызвать каскадный отказ.

1. <strong>Упрощение деплоя&#58;</strong>

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

    - <strong>Решение&#58;</strong> Микросервисы позволяют деплоить и обновлять отдельные сервисы без перезагрузки всей системы.

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

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

1. [С чем едят микросервисы](https://habr.com/ru/companies/otus/articles/716686/)
   :::

---

## <strong>Какие есть способы коммуникации микросервисов?</strong> [#q-14bee738d69b81b88fb3fc0793d758c9]

<strong>Способы коммуникации микросервисов&#58;</strong>

{/* prettier-ignore */}
1. <code>HTTP&#47;REST</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Использование HTTP запросов (GET, POST, PUT, DELETE) для взаимодействия между сервисами.

    - <strong>Примеры&#58;</strong> JSON или XML для передачи данных.

    - <strong>Преимущества&#58;</strong> Простота, широко используемый стандарт.

    - <strong>Недостатки&#58;</strong> Низкая производительность по сравнению с бинарными протоколами.

1. <code>gRPC</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Высокопроизводительный RPC (Remote Procedure Call) протокол, использующий HTTP/2 и бинарный формат данных Protocol Buffers.

    - <strong>Примеры&#58;</strong> Вызов методов удаленно, как локальных функций.

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

    - <strong>Недостатки&#58;</strong> Требует больше усилий для настройки по сравнению с REST.

1. <strong>Сообщения (</strong><code>Message Brokers</code><strong>)&#58;</strong>

    - <strong>Описание&#58;</strong> Использование посредников сообщений для асинхронной передачи данных между сервисами.

    - <strong>Примеры&#58;</strong> RabbitMQ, Apache Kafka, Azure Service Bus.

    - <strong>Преимущества&#58;</strong> Асинхронность, высокая надежность, возможность обработки больших объемов данных.

    - <strong>Недостатки&#58;</strong> Сложность настройки и управления, задержка доставки сообщений.

1. <code>GraphQL</code><strong>&#58;</strong>

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

    - <strong>Примеры&#58;</strong> Запросы и мутации для получения и изменения данных.

    - <strong>Преимущества&#58;</strong> Гибкость, уменьшение объема передаваемых данных.

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

1. <code>gRPC&#45;Web</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Расширение gRPC для работы в веб-браузерах.

    - <strong>Примеры&#58;</strong> Позволяет браузерам вызывать gRPC-сервисы.

    - <strong>Преимущества&#58;</strong> Высокая производительность в веб-среде, совместимость с gRPC.

    - <strong>Недостатки&#58;</strong> Ограниченная поддержка по сравнению с gRPC.

Микросервисы могут взаимодействовать через HTTP/REST, gRPC, сообщение брокеров, GraphQL и gRPC-Web, каждый из которых имеет свои преимущества и недостатки. Выбор метода зависит от требований к производительности, надежности, асинхронности и простоты настройки.

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

1. [Способы общения микросервисов](https://habr.com/ru/companies/maxilect/articles/677128/)
   :::

---

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

Варианты реализации распределенных транзакций в микросервисах&#58;

{/* prettier-ignore */}
1. <strong>Двухфазный коммит (</strong><code>2PC &#45; Two&#45;Phase Commit</code><strong>)&#58;</strong>

    - <strong>Описание&#58;</strong> Координатор транзакции управляет подготовкой и фиксацией всех участников.

    - <strong>Преимущества&#58;</strong> Гарантирует согласованность.

    - <strong>Недостатки&#58;</strong> Высокая сложность и вероятность блокировок, низкая производительность.

    - <strong>Пример&#58;</strong>

        ```text
        1. Prepare Phase: Координатор запрашивает участников подготовить транзакцию.
        2. Commit Phase: Координатор запрашивает участников зафиксировать транзакцию.
        ```

1. <strong>Сага (</strong><code>Saga</code><strong>)&#58;</strong>

    - <strong>Описание&#58;</strong> Длинная транзакция разбивается на серию маленьких, с возможностью отката (compensating transactions).

    - <strong>Преимущества&#58;</strong> Высокая производительность, асинхронное выполнение.

    - <strong>Недостатки&#58;</strong> Сложность реализации компенсирующих операций, возможность временной неконсистентности.

    - <strong>Пример&#58;</strong>

        ```text
        1. Транзакция 1: Создание заказа.
        2. Транзакция 2: Зарезервировать товар.
        3. Транзакция 3: Списать деньги.
        4. В случае ошибки: Компенсирующие транзакции для отката.
        ```

1. <strong>Транзакции с согласованием (</strong><code>Consensus&#45;Based Transactions</code><strong>)&#58;</strong>

    - Описание&#58; Paxos и Raft согласуют реплицируемое состояние. Сами по себе они не обеспечивают атомарную транзакцию между независимыми сервисами; это компонент инфраструктуры, а не замена 2PC или саги.

    - <strong>Преимущества&#58;</strong> Надежность и отказоустойчивость.

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

    - <strong>Пример&#58;</strong> Использование Raft для распределенного согласования состояния между микросервисами.

1. <code>Eventual Consistency</code> <strong>(Согласованность в конечном итоге)&#58;</strong>

    - Описание&#58; eventual consistency — модель согласованности&#58; при отсутствии новых изменений реплики в итоге сходятся. Она не является протоколом распределенной транзакции; доставку событий и обработку сбоев нужно реализовать отдельно.

    - <strong>Преимущества&#58;</strong> Высокая производительность, простота реализации.

    - <strong>Недостатки&#58;</strong> Временная неконсистентность данных.

    - <strong>Пример&#58;</strong> Использование событий и асинхронной репликации данных.

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

1. [Сравнение подходов к реализации распределенных транзакций](https://habr.com/ru/companies/maxilect/articles/677128/)
   :::

---

## <strong>Что такое</strong> <code>circuit breaker</code><strong>?</strong> [#q-14bee738d69b8197a1a7eb75b36fc57f]

<code>Circuit Breaker</code> <strong>(Размыкатель цепи)</strong> – это паттерн
для повышения устойчивости и отказоустойчивости микросервисов, предотвращающий
повторные ошибки при взаимодействии с зависимыми системами.

#### Основные возможности&#58;

{/* prettier-ignore */}
1. <strong>Предотвращение каскадных отказов&#58;</strong>

    - Отключает повторные запросы к сбойной службе, предотвращая её перегрузку.

1. <strong>Повышение устойчивости&#58;</strong>

    - Улучшает устойчивость системы к временным сбоям зависимых служб.

#### Режимы работы&#58;

{/* prettier-ignore */}
1. <code>Closed</code> <strong>(Замкнутый)&#58;</strong>

    - Все запросы проходят к зависимости.

    - Если количество ошибок превышает порог, переключается в состояние Open.

1. <code>Open</code> <strong>(Разомкнутый)&#58;</strong>

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

    - Через определённое время переключается в состояние Half-Open для проверки состояния.

1. <code>Half&#45;Open</code> <strong>(Полуоткрытый)&#58;</strong>

    - Некоторые запросы проходят к зависимости.

    - Если запросы успешны, переключается в состояние Closed.

    - Если запросы продолжают проваливаться, возвращается в состояние Open.

#### Пример использования <code>Circuit Breaker</code> в C# с <code>Polly</code>&#58;

```csharp
using Polly;
using Polly.CircuitBreaker;
using System;
using System.Net.Http;
using System.Threading.Tasks;

class Program
{
    static async Task Main()
    {
        var circuitBreakerPolicy = Policy
            .Handle<HttpRequestException>()
            .CircuitBreakerAsync(
                exceptionsAllowedBeforeBreaking: 3,
                durationOfBreak: TimeSpan.FromSeconds(30)
            );

        var httpClient = new HttpClient();

        for (int i = 0; i < 10; i++)
        {
            try
            {
                await circuitBreakerPolicy.ExecuteAsync(async () =>
                {
                    var response = await httpClient.GetAsync("http://example.com");
                    response.EnsureSuccessStatusCode();
                });
            }
            catch (Exception ex)
            {
                Console.WriteLine($"Request failed: {ex.Message}");
            }
        }
    }
}
```

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

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

1. [С чем едят микросервисы](https://habr.com/ru/companies/otus/articles/716686/)
   :::

---

## Какие гарантии доставки дают брокеры&#58; at-most-once, at-least-once и exactly-once? [#q-14bee738d69b81ff8c91d74d7f9f37be]

Брокеры сообщений (<code>Message Brokers</code>) – это системы промежуточного слоя, которые управляют передачей сообщений между отправителями и получателями, обеспечивая надежную и асинхронную коммуникацию.

<strong>Основные возможности&#58;</strong>

{/* prettier-ignore */}
1. <strong>Асинхронная обработка&#58;</strong>

    - Позволяют отправителям и получателям работать независимо.

1. <strong>Очереди и топики&#58;</strong>

    - Поддержка различных моделей доставки сообщений (очереди, публикация/подписка).

1. <strong>Надежность&#58;</strong>

    - Гарантируют доставку сообщений с различными уровнями гарантии.

<strong>Примеры&#58;</strong>

- <code>RabbitMQ</code>

- <code>Apache Kafka</code>

- <code>Azure Service Bus</code>

#### Семантика доставки сообщений&#58;

{/* prettier-ignore */}
1. <code>At&#45;least&#45;once</code> <strong>(Не менее одного раза)&#58;</strong>

    - <strong>Описание&#58;</strong> Сообщение доставляется минимум один раз, возможны повторные доставки.

    - <strong>Преимущества&#58;</strong> Высокая надежность.

    - <strong>Недостатки&#58;</strong> Потребуется обработка дубликатов.

    - <strong>Пример&#58;</strong> RabbitMQ с подтверждением сообщений.

1. <code>At&#45;most&#45;once</code> <strong>(Не более одного раза)&#58;</strong>

    - <strong>Описание&#58;</strong> Сообщение доставляется максимум один раз, возможна потеря сообщений.

    - <strong>Преимущества&#58;</strong> Высокая производительность.

    - <strong>Недостатки&#58;</strong> Возможна потеря сообщений.

    - <strong>Пример&#58;</strong> UDP, неподтвержденные сообщения в брокерах.

1. <code>Exactly&#45;once</code> <strong>(Ровно один раз)&#58;</strong>

    - <strong>Описание&#58;</strong> Сообщение доставляется ровно один раз, без потерь и дубликатов.

    - <strong>Преимущества&#58;</strong> Высокая надежность и консистентность.

    - <strong>Недостатки&#58;</strong> Высокая сложность реализации.

    - Kafka может обеспечить exactly-once обработку в пределах поддерживаемой транзакционной цепочки чтение–обработка–запись в Kafka. Дедупликация Azure Service Bus по MessageId ограничена окном времени и не гарантирует единственное выполнение внешнего побочного эффекта.

#### Примеры брокеров с семантикой <code>exactly&#45;once</code>&#58;

- <strong>Apache Kafka&#58;</strong> Поддержка транзакций, обеспечивает
  exactly-once семантику для потоков данных и обработки сообщений.

- Azure Service Bus поддерживает транзакции и дедупликацию отправок, но повторная доставка получателю остается возможной. Получатель должен учитывать дубликаты.

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

1. [С чем едят микросервисы](https://habr.com/ru/companies/otus/articles/716686/)
   :::

---

## Какие инструменты для очередей есть в .NET и как выбрать брокер? [#q-14bee738d69b8119b855dcb9dc30698e]

<strong>Инструменты для работы с очередями&#58;</strong>

#### В .NET&#58;

{/* prettier-ignore */}
1. <code>System&#46;Threading&#46;Tasks&#46;Dataflow</code> <strong>(TPL Dataflow)&#58;</strong>

    - <strong>Описание&#58;</strong> Библиотека для построения параллельных и асинхронных программ на основе потоков данных.

    - <strong>Пример использования&#58;</strong> Обработка и передача сообщений между блоками обработки.

1. <code>System&#46;Collections&#46;Concurrent&#46;ConcurrentQueue</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Потокобезопасная очередь для использования в многопоточных приложениях.

    - <strong>Пример использования&#58;</strong> Хранение и обработка задач в многопоточной среде.

#### Отдельные продукты&#58;

{/* prettier-ignore */}
1. <code>RabbitMQ</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Легковесный брокер сообщений с поддержкой различных протоколов (AMQP).

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

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

1. <code>Apache Kafka</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Дистрибутивный стриминговый платформенный брокер сообщений.

    - <strong>Преимущества&#58;</strong> Высокая производительность, горизонтальная масштабируемость, семантика exactly-once.

    - <strong>Пример использования&#58;</strong> Обработка больших объемов данных в реальном времени, потоковая аналитика.

1. <code>Azure Service Bus</code><strong>&#58;</strong>

    - <strong>Описание&#58;</strong> Облачный брокер сообщений от Microsoft.

    - <strong>Преимущества&#58;</strong> Глубокая интеграция с Azure, поддержка транзакций, очереди и топики.

    - <strong>Пример использования&#58;</strong> Интеграция облачных сервисов, построение масштабируемых распределенных систем.

1. <code>Amazon SQS</code> <strong>(Simple Queue Service)&#58;</strong>

    - <strong>Описание&#58;</strong> Облачный сервис очередей сообщений от AWS.

    - <strong>Преимущества&#58;</strong> Простота использования, высокая доступность и масштабируемость.

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

#### Выбор инструмента&#58;

- <strong>RabbitMQ&#58;</strong> Выберу для проектов, требующих гибкости и
  поддержки различных протоколов сообщений.

- <strong>Apache Kafka&#58;</strong> Предпочту для высокопроизводительных систем
  с большими объемами данных и стриминговой аналитикой.

- <strong>Azure Service Bus&#58;</strong> Идеален для проектов, развернутых в
  Azure, благодаря интеграции с другими сервисами Azure.

- <strong>Amazon SQS&#58;</strong> Выберу для проектов на AWS, требующих простой
  и надежной очереди сообщений.

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

1. [Queue класс](https://learn.microsoft.com/ru-ru/dotnet/api/system.collections.queue?view=net-8.0)
   :::