02. Микросервисная архитектура (Keycloak, Security, Kafka, RabbitMQ, FeignClient, Authorisation)

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

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

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

Интегрированные И Индивидуальные Решения для Обеспечения Безопасности Система предлагает выбор между предварительно настроенными решениями безопасности и полностью настраиваемыми реализациями. Готовые инструменты, такие как Spring Security, предоставляют оптимизированную среду, богатую плагинами, которая поддерживает широкую интеграцию. В качестве альтернативы, пользовательские микросервисы могут быть созданы с использованием специальных библиотек для настройки генерации токенов и управления на основе ролей. Такая гибкость позволяет точно управлять стратегиями аутентификации в зависимости от конкретных операционных потребностей.

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

Микросервис продукта построен на базе надежной системы обнаружения, которая объединяет различные инструменты, такие как FeignClient и Spring Cloud actuators, для предотвращения перегрузки архитектуры сервисов. Используется интуитивно понятный клиентский подход, при котором интерфейсы контроллера просто описываются и вызываются как стандартные сервисы, обеспечивая плавное взаимодействие между сервисами. Альтернативные методы, такие как очереди сообщений, Kafka и быстрый протокол gRPC, ориентированный на двоичный код, предлагают гибкие и высокоэффективные возможности обмена данными. gRPC, оптимизированный Google, выделяется своей скоростью и простотой при удаленном вызове процедур.

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

Динамическая обработка ошибок и мгновенное перенаправление потока RabbitMQ предоставляет возможность немедленно перенаправлять сообщения в альтернативные очереди при возникновении ошибок, упрощая управление сбоями. Эта функция устраняет необходимость в ручной привязке разделов при выполнении определенных условий. Как только сообщение обработано или перенаправлено, оно больше не сохраняется, что подчеркивает временную модель обработки.

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

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

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

Spring Cloud Sleuth отслеживает один запрос, который беспрепятственно проходит через четыре различных микросервиса, объединяя отдельные журналы в комплексную информацию об обнаружении ошибок. Этот процесс раскрывает весь путь выполнения запроса, позволяя разработчикам точно определить, где возникают проблемы в распределенных журналах. Отмечается переход от упрощенного использования Spring Cloud Sleuth в Spring 2 к использованию в Spring Boot 3 более надежной библиотеки Micrometer, которая объединяет трассировку с расширенными возможностями мониторинга.

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