ИТМО Микросервисы - лекция 7 - Межпроцессное взаимодействие. API. REST API, RMI, Messaging API

• Лектор обсуждает формат лекции с вопросами и ответами и возможность использования функции поднятия руки в Zoom.  

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

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

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

• Лектор объясняет, что блокирующее общение может привести к снижению доступности системы и делает ее менее устойчивой.  

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

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

• Kafka обеспечивает гарантии доставки сообщений и позволяет клиентам самостоятельно решать, когда читать сообщения.  

• В видео объясняется, что такое опи и как оно используется в межпроцессном взаимодействии.  

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

• В примере с микросервисами, опи используется для общения между сервисами с помощью REST-запросов.  

• Видео обсуждает рест-апи, его идеологию и использование.  

• Рест-апи был создан для упрощения работы с API и его использование стало популярным.  

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

• Видео объясняет, что параметры и статусы являются частью рест-апи.  

• Статусы могут быть использованы для выражения ошибок и их группировка по категориям.  

• Видео обсуждает, как передать знания о рест-апи клиентам.  

• Один из вариантов - включить документацию в приложение, которое скачивают клиенты.  

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

• Видео обсуждает проблему дублирования кода при использовании рест-апи в микросервисной архитектуре.  

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

• Обсуждение проблемы дублирования кода и необходимости создания библиотек для каждого сервиса.  

• Предложение использовать интерфейсы для упрощения работы с клиентами.  

• Создание отдельного модуля с декларативным описанием опи для каждого сервиса.  

• Использование аннотаций для объявления методов и параметров.  

• Создание интерфейсов на основе декларативного описания опи.  

• Использование аннотации "feyn client" для указания корневого пути.  

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

• Обсуждается возможность использования одного репозитория для всех микросервисов, но это может привести к дублированию кода и увеличению времени сборки.  

• В видео объясняется, что микросервисы общаются через кафку, и каталог сервис отправляет сообщения в кафку через определенный канал.  

• Обсуждается, что в данном случае каталог сервис является клиентом, а не сервером, поскольку он отправляет сообщения, а не получает их.  

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

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

• Пример: обновление вин в час.  

• Ивенты - это события, которые произошли в системе, например, обновление вин.  

• Команды - это запросы, которые могут быть отправлены только на определенный сервис, например, отправка нотификации.  

• Для объявления рест-апи нужно знать глаголы, типы параметров, типы сущностей и структур данных.  

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

• Обсуждение использования хедеров для обработки сообщений на стороне сервера.  

• Упоминается, что хедеры могут обрабатываться на клиенте, но это может привести к потере сообщений и проблемам с гарантией доставки.  

• Обсуждение использования Kafka для обработки сообщений и его преимуществ перед другими системами.  

• Упоминается возможность разделения топиков на партии для обеспечения надежности и юзабилити.  

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

• Упоминается пример использования этого подхода в разработке сервиса для обработки событий.  

• Обсуждение проблемы с репозиториями, которые могут быть устаревшими или содержать ошибки.  

• Предлагается снести и переделать такие репозитории, если они не нужны.