Микросервисы

Все темы Systems Analyst

Знакомы ли вы с микросервисами?

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

1. Независимость: Каждый микросервис может быть разработан, развернут и масштабирован отдельно от других.

2. Гибкость и масштабируемость: Изменение и масштабирование одного сервиса не влияет на работу других.

3. Легкость в развертывании и обновлении: Благодаря отдельному развертыванию, обновления микросервисов проще и безопаснее.

4. Язык и технология: Каждый микросервис может быть написан на разных языках программирования и использовать разные технологии.

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

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

Что такое Хореография и Оркестрация?

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

1. Хореография: В этом подходе каждый микросервис знает о своих задачах и взаимодействует напрямую с другими сервисами по согласованным между ними правилам. Отсутствует централизованное управление, и вся логика распределена между участниками взаимодействия.

2. Оркестрация: Здесь есть централизованный компонент, называемый оркестратором, который координирует действия микросервисов. Оркестратор управляет последовательностью вызовов и обеспечивает согласованное выполнение бизнес-процессов.

Различия:

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

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

Какие достоинства и недостатки микросервисов вы знаете?

Микросервисы имеют ряд достоинств и недостатков:

1. Разделение на слабосвязанные компоненты: Позволяет разрабатывать и поддерживать каждый сервис независимо.

2. Гибкость и масштабируемость: Легкость в масштабировании отдельных сервисов в зависимости от нагрузки.

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

4. Быстрая разработка и доставка: Позволяют ускорить разработку новых функций и функциональных улучшений.

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

1. Сложность управления: Усложняется управление и мониторингом множества микросервисов.

2. Сетевая задержка: Взаимодействие между сервисами через сеть может вызвать задержки.

3. Сложность тестирования: Необходимость интеграционного тестирования между микросервисами.

4. Потребление ресурсов: Для работы множества микросервисов требуются дополнительные ресурсы.

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

Расскажите про токен-авторизацию в микросервисах.

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

1. Выдача токена (Token issuance): После аутентификации пользователя сервис выдает токен, который содержит информацию о пользователе и правах доступа.

2. Типы токенов:

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

   • Opaque token: Ссылка на информацию аутентификации, хранящаяся в базе данных или кэше.

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

4. Обновление токена (Token refresh): Используется для продления срока действия токена без необходимости повторной аутентификации пользователя.

5. Использование в микросервисах:

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

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

6. Преимущества:

   • Безопасность: Токены могут содержать ограниченный набор прав доступа.

   • Масштабируемость: Управление доступом и аутентификацией может быть легко расширено на большое количество микросервисов.

   • Гибкость: Возможность централизованного управления правами доступа и аутентификационными данными.

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

По каким признакам распознать распределённый монолит?

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

Как определить границы микросервисов?

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