36 самых популярных вопросов по микросервисам на собеседованиях

Подпишитесь на наш ТЕЛЕГРАМ КАНАЛ РАБОТА ДЛЯ ТЕСТИРОВЩИКА.ВАКАНСИИ

С 2015 года микросервисы стали революционным архитектурным подходом, изменившим способы проектирования, разработки и развертывания приложений. Согласно опросу Statista, в 2021 году 45% респондентов отметили, что используют микросервисы в аналитических/BI-приложениях (business intelligence applications).

Если вы рассматриваете переход на эту технологию или хотите изучить что-то новое, микросервисы это отличный выбор. Давайте разберем 36 ключевых вопросов, которые задают как новичкам, так и опытным разработчикам.

Топ вопросов по микросервисам

1. Что такое архитектура микросервисов?

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

2. Ключевые особенности микросервисов

Основными особенностями микросервисной архитектуры являются:

Децентрализованная разработка: каждый сервис развивается автономно
Модульность: приложение делится на узкоспециализированные сервисы
Слабая связанность: API минимизируют зависимости между сервисами
Масштабируемость: сервисы можно масштабировать независимо
Гибкость технологий: можно использовать разные языки и фреймворки

3. Почему выбирают микросервисы?

Легкая адаптация к новым технологиям.
Отказ одного сервиса не ломает всю систему.
Подходит как для крупных компаний, так и для небольших команд.
Быстрое развертывание.

4. Основные компоненты микросервисов

Контейнеризация (Docker) и оркестрация (Kubernetes).
Инфраструктура как код (IaC).
API шлюз (Kong, Apigee).
Сервисная шина (RabbitMQ, Kafka).
Механизмы обнаружения сервисов (Eureka, Consul).

5. Как работает микросервисная архитектура?

Клиент
Инициирует запросы и взаимодействует с системой (например, мобильное приложение или веб-браузер).
API шлюз (API Gateway)
Выполняет роль единой точки входа:
- Маршрутизирует запросы к нужным сервисам
- Может обрабатывать аутентификацию, кэширование и балансировку нагрузки
Сервисы (Сервис 1, Сервис 2, …, Сервис N)
- Каждый сервис отвечает за конкретную функцию (например, платежи, аутентификацию)
- Общаются между собой через:
  - REST/gRPC API (синхронно)
  - Очереди сообщений (Kafka, RabbitMQ — асинхронно)
Статический контент
Хранит неизменяемые данные: изображения, CSS/JS файлы, HTML шаблоны.

Управление (Management)
- Обеспечивает балансировку сервисов между узлами кластера
- Автоматически обнаруживает и обрабатывает сбои в работе сервисов
Обнаружение сервисов (Service Discovery)
- Механизм автоматического поиска и маршрутизации между микросервисами
- Позволяет сервисам находить друг друга без жестких зависимостей (например, через Eureka или Consul)
CDN (Content Delivery Network)
- Распределенная сеть прокси серверов и дата центров
- Ускоряет доставку статического контента пользователям по географическому принципу
Удаленные сервисы (Remote Services)
- Обеспечивают доступ к данным и функциональности на удаленных компьютерах и устройствах
- Работают через сетевые протоколы (REST, gRPC, WebSockets)

6. Как работает микросервисная архитектура на уровне модулей?

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

Принцип работы:

Разделение на модули
- Приложение делится на небольшие сервисы (например, «Пользователи», «Платежи», «Заказы»)
- Каждый модуль отвечает за свою функцию и слабо связан с другими
Распределенная инфраструктура
- Модули могут работать на разных серверах, облаках или дата центрах
- Например: сервис аутентификации в AWS, сервис платежей в Google Cloud
Автономность
- Каждый сервис:
  - Запускается как отдельный процесс
  - Может обновляться или заменяться без влияния на систему.
  - Масштабируется независимо (например, только «Корзина» при нагрузке).
Гибкость
- Система легко адаптируется к новым требованиям:
  - Добавление новых функций = создание новых микросервисов.
  - Изменение логики = модификация одного сервиса без переделки всего приложения

7. Что такое монолитная архитектура?

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

8. Отличия монолита и микросервисов

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

9. Стратегии развертывания микросервисов

В микросервисных системах обычно применяют следующие стратегии развертывания:

Сине-зеленое развертывание (Blue-Green)
- Поддерживаются две идентичные продакшн среды (синяя и зеленая)
- Позволяет мгновенно переключаться между версиями для обновлений или откатов
- Минимизирует downtime при деплое
Канареечное развертывание (Canary)
- Постепенный развертывание обновлений для части пользователей/трафика
- Позволяет протестировать изменения на небольшой аудитории перед полным внедрением
- Снижает риски при выходе новых версий
Постепенное развертывание (Rolling)
- Поэтапное обновление серверов/инстансов
- Новые версии разворачиваются последовательно, заменяя старые
- Обеспечивает плавный переход без полной остановки системы
Теневое развертывание (Shadow)
- Копирование продакшн трафика в новую версию для тестирования
- Позволяет проверять работу системы в реальных условиях без влияния на пользователей
- Особенно полезно для тестирования производительности

10. Что такое Spring Cloud?

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

Для типичных сценариев использования Spring Cloud предлагает готовые решения и обширный набор функций, включая следующие:

Версионное распределенное управление конфигурациями
Механизм регистрации и обнаружения сервисов
Возможность вызовов между сервисами
Гибкая маршрутизация запросов
Паттерн «Circuit Breaker» и балансировка нагрузки
Управление состоянием кластера и выбор лидера
Глобальные блокировки и распределенная система сообщений

11. Что такое Spring Boot?

Spring Boot — это open-source фреймворк на Java, который упрощает создание и настройку готовых к продакшену приложений. Он особенно полезен для разработки микросервисов, так как ускоряет запуск проектов и сокращает время на разработку и тестирование.

Ключевые особенности Spring Boot:

Автоконфигурация (Autoconfiguration): Spring Boot автоматически настраивает компоненты приложения (бины, подключение к БД, безопасность) на основе зависимостей в проекте.
Встроенные серверы (Embedded Servers): приложение можно упаковать в один JAR-файл, который включает: Tomcat (по умолчанию) или Jetty или Undertow (альтернативы). Не нужен отдельный сервер приложений (например, WildFly) просто запускаете JAR.
Стартеры (Starters): готовые наборы зависимостей для быстрого старта: для REST API, для работы с БД, для аутентификации. Избавляют от ручного подбора совместимых библиотек.
Actuator (Мониторинг и управление): готовые HTTP эндпоинты для администрирования: проверка состояния сервиса, метрики производительности, настройки окружения. Позволяет отслеживать работу приложения без написания кода.

12. Как переопределить значения по умолчанию в проекте Spring Boot?

В Spring Boot можно переопределить стандартные свойства, указав новые значения в файле application.properties.

Например, в приложениях Spring MVC необходимо указать префикс и суффикс для представлений. Это можно сделать, добавив в application.properties следующие строки:

Для суффикса:
spring.mvc.view.suffix: .jsp

Для префикса:
spring.mvc.view.prefix: /WEB-INF/

13. Что делает Actuator в Spring Boot?

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

14. Какие встроенные контейнеры поддерживает Spring Boot?

При развертывании Java приложений можно использовать два подхода:

Внешний сервер приложений (например, WildFly, WebLogic)
Встроенный (embedded) контейнер — сервер упаковывается прямо в JAR-файл приложения.

Spring Boot поддерживает три популярных встроенных контейнера:

1. Tomcat (по умолчанию)

Apache Tomcat — легковесный сервер для Java приложений. Стабильность и широкое распространение. Поддержка Servlet API, JSP, WebSocket.

2. Jetty

Eclipse Jetty — оптимизирован для облачных и микросервисных решений. Быстрый старт и низкое потребление памяти. Часто используется в Kubernetes и Docker контейнерах.

3. Undertow

Undertow (от Red Hat) — высокопроизводительный асинхронный сервер. Максимальная производительность (подходит для high-load систем). Гибкая архитектура на основе обработчиков (handlers).

15. Реализация Spring Security в Spring Boot приложении

Настройка безопасности в Spring Boot приложении с использованием Spring Security включает 3 основных этапа:

Шаг 1: Добавление зависимости

Добавьте в pom.xml (Maven) или build.gradle (Gradle):

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-security</artifactId>
</dependency>

Примечание: После добавления этой зависимости Spring Boot автоматически настроит Spring Security с конфигурацией по умолчанию:

Автоматически активирует базовую защиту (все endpoints требуют аутентификацию)
Генерирует временный пароль (для входа в консоли при запуске)

Шаг 2: Настройка правил доступа

Создайте класс конфигурации, переопределяющий WebSecurityConfigurerAdapter:

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;


@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {


    @Override
    protected void configure(HttpSecurity http) throws Exception {
        http
            .authorizeRequests()
                .antMatchers("/public/**").permitAll()
                .anyRequest().authenticated()
                .and()
            .formLogin()
                .loginPage("/login")
                .permitAll()
                .and()
            .logout()
                .logoutUrl("/logout")
                .permitAll();
    }
}

Шаг 3: Настройка аутентификации

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

Пример аутентификации в памяти (для тестов):

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.authentication.builders.AuthenticationManagerBuilder;
import org.springframework.security.config.annotation.web.configuration.EnableWebSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;


@Configuration
@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {


    @Override
    protected void configure(AuthenticationManagerBuilder auth) throws Exception {
        auth
            .inMemoryAuthentication()
                .withUser("user")
                .password("{noop}password")
                .roles("USER");
    }
}

16. Что такое сквозное (End-to-End) тестирование микросервисов?

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

В контексте микросервисов E2E тестирование:

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

17. Что такое семантический мониторинг?

Семантический мониторинг (или синтетический мониторинг) — это практика регулярного выполнения авто тестов на рабочей (production) системе. Результаты этих тестов отправляются в сервис мониторинга, который генерирует оповещения при обнаружении аномалий.

18. Что такое Eureka в микросервисах?

Eureka — это инструмент для регистрации и обнаружения сервисов, разработанный Netflix для микросервисных архитектур. Является частью стека Open Source Software (OSS) от Netflix и используется для управления и поиска сервисов в динамической распределённой среде.

Микросервисы должны регистрироваться в сервере Eureka, что позволяет серверу вести полный учёт всех клиентских приложений, работающих на различных портах и IP адресах.

19. Как настроить сервис discovery?

Сервис discovery можно настроить несколькими способами, и один из эффективных методов использование Netflix Eureka. Этот подход не только прост, но и легковесен, что не нагружает приложение. Кроме того, он совместим с широким спектром веб приложений.

Настройка Eureka включает два основных шага:

Конфигурация клиента: Настройку клиента можно выполнить с помощью файлов свойств. В classpath Eureka ищет eureka-client.properties. Она также ищет переопределения, вызванные средой, в environment-specific property files.
Конфигурация сервера: Для настройки сервера сначала необходимо настроить клиент. После этого сервер запускает клиент, который используется для поиска других серверов. По умолчанию Eureka сервер использует конфигурацию клиента для поиска peer сервера.

20. Зачем нужны отчеты и дашборды в микросервисах?

Отчеты и дашборды в основном используются для мониторинга и поддержки микросервисов. Для этого применяются различные инструменты. Они позволяют:

определить, какие ресурсы предоставляют те или иные микросервисы
выявить сервисы, на которые повлияют изменения в компоненте
получить удобную точку доступа к документации
проверить версии развернутых компонентов
оценить уровень зрелости и соответствие стандартам компонентов

21. Как работает PACT?

PACT — это инструмент тестирования с открытым исходным кодом. Он помогает проверять взаимодействия между потребителями (consumers) и поставщиками сервисов (providers). Поддерживает множество языков, включая Ruby, Java, Scala, .NET, JavaScript и Swift/Objective-C.

Принцип работы основан на следующих принципах:

Контракты, определяемые потребителем (Consumer-Driven Contracts)
Тестирование потребителя (Consumer Testing)
Генерация PACT-файлов
Мокирование и тестирование сервисов
Интеграция в CI/CD
Совместимость между потребителем и поставщиком

22. Что такое Domain-Driven Design?

Domain-Driven Design (DDD) — это подход к проектированию программных систем, основанный на глубоком понимании предметной области (бизнес домена). Его цель согласовать разработку программного обеспечения со сложностями бизнес домена, что позволяет создавать более эффективные и поддерживаемые архитектуры на основе микросервисов. Основное внимание уделяется базовой логике домена, а сложные проекты строятся на основе его модели.

Ключевые принципы DDD:

DDD концентрируется на логике домена и самой предметной области
Сложные проекты полностью основываются на модели домена
Для улучшения модели и устранения проблем DDD предполагает постоянное взаимодействие с экспертами предметной области

23. Что такое зацепление и связность?

Зацепление (Coupling) и связность (Cohesion) — это фундаментальные понятия программной архитектуры.
Зацепление показывает степень зависимости между модулями. Низкое зацепление означает, что компоненты независимы: изменения в одном почти не влияют на другие.
Связность определяет, насколько логически связаны функции внутри модуля. Высокая связность: когда модуль решает одну четкую задачу.

Хорошая архитектура стремится к:

Минимальному зацеплению (сервисы работают автономно, система становится гибче)
Максимальной связности (вся связанная логика собрана внутри одного модуля, что уменьшает лишние взаимодействия)

Такой подход упрощает поддержку, тестирование и масштабирование кода.

24. Что такое OAuth?

OAuth (Open Authorization Protocol) — это протокол, который позволяет клиентским приложениям получать доступ к данным через сторонние сервисы (например, Facebook, GitHub и др.) по HTTP. Он также даёт возможность обмениваться ресурсами между разными сайтами без передачи учётных данных в виде логина и пароля.

OAuth разрешает третьим сторонам (например, Facebook) использовать информацию аккаунта конечного пользователя, сохраняя её безопасность без раскрытия или передачи пароля. Фактически, OAuth выступает посредником от имени пользователя, предоставляя серверу токен для доступа к запрашиваемым данным.

25. Зачем нужны контейнеры для микросервисов?

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

Преимуществ а использования контейнеров:

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

26. Какполучить доступ к RESTful микросервисам?

Доступ к RESTful микросервисам можно организовать двумя основными способами:

Балансируемый Rest Template
- Используется балансируемый rest шаблон
- Обеспечивает равномерное распределение сетевой нагрузки между серверами
- Повышает производительность и отказоустойчивость приложения
Множественные микросервисы
- Каждый микросервис выполняет определенную функцию
- Совокупность микросервисов формирует законченное приложение
- Позволяет гибко масштабировать отдельные компоненты системы

27. Какие основные сложности возникают при тестировании микросервисов?

Рассматривая недостатки, вот еще один важный вопрос о проблемах, с которыми сталкиваются при тестировании микросервисов:

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

28. Какие типичные ошибки допускают при переходе с монолитной архитектуры на микросервисы?

Переход с монолитной архитектуры на микросервисную сопряжен с рядом типичных ошибок:

Недооценка ключевых аспектов
- Недостаточный анализ вопросов управления данными, тестирования, коммуникации и безопасности
- Игнорирование существующих проблем текущей системы
- Отсутствие четкого плана миграции
Организационные просчеты
- Нечеткое распределение зон ответственности между командами
- Размытые сроки и границы реализации
- Отсутствие продуманной стратегии внедрения
Технические упущения
- Недостаточная автоматизация процессов (CI/CD)
- Запаздывающее внедрение DevOps практик
- Игнорирование вопросов безопасности (аутентификация, авторизация, шифрование)
- Попытка перенести монолитные подходы в микросервисную среду
Архитектурные ошибки
- Создание слишком мелких или слишком крупных сервисов
- Непродуманные механизмы межсервисного взаимодействия
- Отсутствие стратегии управления распределенными данными

29. Каковы основные принципы проектирования микросервисов?

Это один из самых популярных вопросов на собеседованиях по микросервисам. Вот ключевые принципы, которые нужно учитывать:

Определение границ сервисов
- Четкое определение области ответственности каждого сервиса
- Сочетание слабой связанности (loose coupling) и высокой связности (high cohesion)
- Создание уникального идентификатора для каждого сервиса (аналог первичного ключа в БД)
Разработка API и интеграция
- Тщательное проектирование API
- Особое внимание процессам интеграции
- Ограничение доступа к данным минимально необходимым уровнем
- Обеспечение плавного взаимодействия запросов и ответов
Оптимизация процессов
- Максимальная автоматизация для снижения временных затрат
- Минимизация количества таблиц для уменьшения сложности хранения данных
- Непрерывный мониторинг архитектуры и оперативное устранение недостатков
Изоляция компонентов
- Отдельное хранилище данных для каждого микросервиса
- Изолированная сборка для каждого сервиса
- Развертывание в контейнерах
- Использование stateless-серверов

Эти принципы обеспечивают гибкость, масштабируемость и надежность микросервисной архитектуры.

30. Где используется аннотация WebMvcTest?

Аннотация @WebMvcTest применяется для модульного тестирования Spring MVC приложений. Она фокусируется исключительно на компонентах Spring MVC.
Пример использования:
@WebMvcTest(value = ToTestController.class, secure = false):

В этом случае:

Загружается только ToTestController
Другие контроллеры и маппинги остаются неактивными во время теста
Параметр secure = false отключает проверку безопасности

31. Что такое Ограниченный Контекст (Bounded Context)?

В Domain-Driven Design (DDD) Ограниченный контекст — это четко определенная граница, в пределах которой:

Определяется и применяется конкретная доменная модель
Действуют согласованные термины, концепции и бизнес правила

Особенности:

Разделяет сложные доменные модели на управляемые части
Явно описывает взаимосвязи между контекстами
Объединяет логически связанные элементы бизнес домена

32. Какие существуют виды двухфакторной аутентификации (2FA)?

Основные методы двухфакторной аутентификации включают:

SMS-аутентификация
- Код подтверждения отправляется на зарегистрированный мобильный номер через SMS
- Пользователь вводит полученный код для верификации
Мобильные приложения-аутентификаторы (TOTP)
- Генерация временных одноразовых паролей в приложениях (Google Authenticator, Authy и др.)
- Коды обновляются через определенные интервалы времени
Email аутентификация
- Отправка кода или ссылки подтверждения на зарегистрированный email
- Требует ввода кода или перехода по ссылке
Биометрическая аутентификация
- Использование отпечатков пальцев
- Распознавание лица или радужной оболочки глаза
- Голосовая идентификация
Push уведомления
- Запрос на подтверждение приходит в мобильное приложение
- Доступ предоставляется после подтверждения пользователем
Голосовая аутентификация
- Автоматический звонок с кодом подтверждения
- Требует ввода кода или голосового подтверждения

33. Что такое клиентский сертификат?

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

34. Как настроить логирование в Spring Boot приложении?

Spring Boot предоставляет встроенную поддержку популярных систем логирования: Log4J2, Java Util Logging и Logback. Обычно они предварительно настраиваются как консольный вывод. Их можно настроить, указав только logging.level в файле application.properties.

logging.level.spring.framework = Debug

35. Как проводить тестирование безопасности микросервисов?

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

Индивидуальная оценка сервисов:
- Анализ каждого микросервиса на уязвимости
- Использование пентестинга и сканирования уязвимостей
Проверка безопасности API и данных:
- Валидация безопасности API
- Проверка шифрования данных
- Анализ методов безопасного хранения
Тестирование аутентификации и авторизации:
- Проверка механизмов аутентификации
- Контроль систем авторизации
- Предотвращение несанкционированного доступа
Тестирование защищенной коммуникации и интеграции:
- Обеспечение безопасных протоколов связи
- Проверка межсервисного взаимодействия на уязвимости
Масштабируемость и постоянный мониторинг:
- Оценка мер безопасности при масштабировании
- Реализация постоянного мониторинга
- Оперативное выявление и устранение проблем

36. Что такое идемпотентность и как она используется?

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

Перевод статьи «36 Most Asked Microservice Interview Questions».