2PC
Двухфазный коммит (2PC, Two-Phase Commit) — это протокол, обеспечивающий атомарность транзакций в распределенных системах. Этот протокол гарантирует, что транзакция будет завершена (зафиксирована или откатана) на всех участниках или ни на одном из них.
Протокол двухфазного коммита состоит из двух фаз:
-
Фаза подготовки (Prepare phase):
- Координатор отправляет запрос на подготовку к коммиту всем участникам транзакции.
- Каждый участник выполняет все операции транзакции до момента фиксации, но не фиксирует их, и сообщает координатору, готов ли он зафиксировать или нет.
-
Фаза коммита (Commit phase):
- Если все участники сообщили, что готовы к коммиту, координатор отправляет им команду на фиксацию транзакции.
- Если хотя бы один участник сообщил, что не готов к коммиту, координатор отправляет всем участникам команду на откат транзакции.
Основные компоненты протокола:
- Координатор (Coordinator): Этот компонент контролирует выполнение протокола двухфазного коммита.
- Участник (Participant): Это компоненты, которые участвуют в транзакции и выполняют операции, связанные с транзакцией.
Однако стоит отметить, что двухфазный коммит имеет свои недостатки. Один из основных — это блокировка ресурсов в случае сбоев. Если координатор или один из участников транзакции сталкивается с проблемой (например, отказом), другие участники могут оставаться в заблокированном состоянии на неопределенное время.
Масштабирование сервисов (стратегии)
-
Разделение сервисов:
- Разбиение крупных монолитных проектов на более мелкие сервисы - это не новая идея. Это было введено как SOA (Service-Oriented Architecture) и позже эволюционировало в архитектуру, известную как микросервисы.
- Разделение функциональности на несколько сервисов может значительно улучшить производительность, масштабируемость и снизить затраты. Вместо масштабирования всей системы можно масштабировать только наиболее проблемные сервисы.
-
Горизонтальное масштабирование:
- В прошлом популярным был подход, известный как вертикальное масштабирование, но горизонтальное масштабирование является противоположным способом решения той же проблемы. Вместо добавления большего объема оперативной памяти или CPU к существующей машине, можно приобрести больше машин.
-
Раздельные базы данных для чтения и записи:
- Во многих системах, ориентированных на пользователя, количество операций чтения данных на несколько порядков выше, чем операций записи. Копирование данных в отдельную базу данных только для чтения и использование ее для обслуживания запросов на чтение может значительно улучшить систему.
-
Шардирование баз данных:
- Шардирование баз данных - это еще один широко используемый метод масштабирования. Короче говоря, это логическое разделение данных на основе выбранного набора значений, часто называемых ключами раздела или шардами.
-
Кэширование в памяти:
- Кэширование в памяти, вероятно, самый известный способ повышения производительности. Кэширование дорогостоящих запросов к базам данных, медленных вычислений или рендеринга страниц может творить чудеса.
-
Переход в облако:
- Технически переход в облако сам по себе не является методом масштабирования, но это изменяет правила игры с точки зрения масштабирования и экономии средств. Современные облачные провайдеры используют модель оплаты по мере использования, автоматически масштабируя наши приложения, когда это необходимо.
Безопасное коммуницирование в микросервисах
Проблемы
-
В архитектуре микросервисов количество точек API для защиты значительно больше, чем в монолитных приложениях. К тому же предпочтение бесстатусным службам делает традиционный подход к безопасности на основе сессий более сложным.
-
Запрос или транзакция могут проходить через несколько служб, что затрудняет мониторинг системы. Логи и метрики служб необходимо агрегировать в распределенной архитектуре, чтобы получить целостное представление о всем приложении.
-
Управление несколькими версиями одновременно работающей службы вводит сложности, такие как направление запросов к соответствующей версии службы. Некоординированный выход новых версий или неэффективная маршрутизация запросов может привести к несоответствиям в обмене данными, потенциально раскрывая чувствительную информацию или создавая точки уязвимости для атак.
-
Необходимо аутентифицировать и авторизовать все запросы к службам в целях безопасности. Разработчики также должны шифровать трафик между службами, используя безопасность транспортного уровня (TLS).
Решения
Взаимный TLS или mTLS Взаимный TLS - это версия протокола TLS, при которой клиент отправляет подписанный сертификат серверу (и наоборот). Сервер ожидает, что сертификат клиента будет подписан определенным Центром сертификации (CA), специфичным для системы, тем самым подтверждая, что клиенту разрешен доступ. Сертификат также может содержать метаданные о клиенте, которые могут дополнительно информировать решения об авторизации.
OpenID Connect (OIDC) OIDC - это протокол, построенный поверх OAuth2, который позволяет центральному серверу идентификации аутентифицировать пользователей от имени других сервисов, к которым пользователь хочет получить доступ. Этот протокол широко используется как в частных, так и в корпоративных средах для создания среды единого входа (SSO), где пользователю нужно аутентифицироваться только один раз, а не в каждом отдельном сервисе. После аутентификации пользователь получает JSON Web Token (JWT) от провайдера идентификации и отправляет его в каждом запросе. Сервисы, получающие запросы от пользователей, могут проверить JWT и извлечь информацию о пользователе из него.
Авторизация Аутентификация только подтверждает личность сервиса, отправляющего запрос. Авторизация в микросервисах - это процесс определения, разрешен ли сервису или пользователю, от имени которого действует сервис, доступ к запрашиваемым данным или выполнение запрашиваемого действия. Логика авторизации может быть жестко закодирована в бизнес-логике, но это сцепление затрудняет внедрение изменений в политику.
Лучшая альтернатива - это разделение кода политики и передача всех решений об авторизации точке принятия решений о политике, такой как Open Policy Agent (OPA). OPA может быть развернут рядом с каждым сервисом как sidecar для обработки решений об авторизации на основе детализированных политик и правил. Доступ предоставляется только тогда, когда выполняются все условия политики, и решение сохраняется в аудит-логе, позволяя службам безопасности проверять подозрительные запросы.
Сервисные меши Сервисный меш - это специализированный уровень инфраструктуры, который использует sidecar-прокси для управления всеми коммуникациями сервис-к-сервису в микросервисном приложении. Сервисные меши также используют mTLS для защиты коммуникационных каналов между сервисами и отделения мониторинга и безопасности от приложения.
Сервисный меш также решает несколько критических проблем коммуникации между микросервисами, таких как балансировка нагрузки, предотвращение каскадных сбоев и распределенное трассирование. Эти возможности объясняют, почему сервисный меш является важным компонентом во многих облачных системах. Фактически, согласно Business Research Insights, рынок сервисных мешей ожидает показать сложный годовой темп роста (CAGR) на уровне 41,3% и достигнуть значения в 1,44 миллиарда долларов к 2027 году.