Как интегрировать микросервис?

Ссылка скопирована
1 ответ

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

Поэтому прошу помощи с вопросами:

1. Как правильно настроить webpack?
Изначально было решено использовать относительные пути, а запросы проксировать на нужные адреса в зависимости от стенда, чтобы не возникало проблем с аутентификацией (ну и в вебпаке указан тогда один remote).

new ModuleFederationPlugin({   name: 'common',   remotes: {     filename: 'remoteEntry.js',     appB: 'appB@appB/dist/remoteEntry.js'   },   shared: {} })

new ModuleFederationPlugin({ name: 'common', remotes: { filename: 'remoteEntry.js', appB: 'appB@appB/dist/remoteEntry.js' }, shared: {} })

Возможно стоило для разных стендов задавать свой url используя process.env?
Но в любом случае после получения микросервиса, он будет отправлять запрос за данными и проксирование по идее все равно понадобится.

2. Возможно стоило использовать iframe для этих целей, это бы избавило от проблем с авторизацией?
На данный момент все застряло на том, что при первом запросе к remoteEntry.js возвращается ошибка авторизации, так как аутентификационная кука после авторизации устанавливается только относительно нашего поддомена, а не общая.
Когда пробовали вариант с редиректом, то застряли на CORS ошибках.

3. Микросервису B необходимо разработать sdk, а данные получать по отдельным API-запросам? (То есть не использовать module federation).
Или возможно микросервису B нужно сделать какие-то дополнительные настройки, которые не делают по дефолту для микросервисов.

Все упирается в сложность с авторизацией, так как у приложения A и приложения B они разные.
Проблем с интеграцией внутренних микросервисов (то есть лежащих в нашем окружении с общей аутентификацией) не возникало.

Дополнительно:

Ответы:

Возможно стоило для разных стендов задавать свой url используя process.env?

Именно так и надо делать. Это вполне стандартная практика. Просто кладете рядом локальный файл со всеми переменными окружения - адреса, порты и прочее.

  • Просто сталкиваюсь со следующей проблемой: обращение к remoteEntry.js успешно при входе в приложение. Но затем, когда в приложении открываю страницу где должен быть микросервис - ничего не работает. Идет обращение за js и css чанками, но почему-то по относительному пути.

    То есть, микросервис B лежит по адресу: https://app-B.com/dist/remoteEntry.js
    Запрос https://app-B.com/dist/remoteEntry.js - успешен.
    Запросы типа: https://app-A.com/dist/09_abc09zabc09z.js - естественно возвращают 404 ошибку (так как путь стал относительным)

    Но почему эти запросы генерируются относительно приложения А? Что-то нужно указать в настройках вебпака чтоб он шел к микросервису B?

  • про /dist/09_abc09zabc09z.js в вашем вопросе ничего нет.
    Вероятно, появляется при выполнении app-B/dist/remoteEntry.js?
    Тогда app-B должен при сборке подставлять полный url сервера к ресурсам.
    https://webpack.js.org/guides/public-path/
  • iljaGolubev, вы правы, не упомянул.
    По всей видимости, микросервис B не сможет при сборке подставлять полный url сервера, потому что проект собирается один раз. А созданный диструбутив раскатывается на разные стенды, то есть на разные сервера.

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

  • Но затем, когда в приложении открываю страницу где должен быть микросервис

    Эту страницу генерит app-A?
    Есть возможность прописать на ней <base href="https://app-B.com" />?

  • iljaGolubev, эх, к сожалению app-A – это SPA на React, поэтому возможности прописать base нет
Нужно решить такую задачу?

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

Заказать помощь
Лучший ответ
1
Игорь Волков Ответ

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

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

2. Используйте шаблон проектирования API Gateway: Для управления запросами к микросервисам лучше использовать шаблон проектирования API Gateway. Он позволит управлять запросами, маршрутизировать их к нужному микросервису и обеспечить безопасность и масштабируемость системы.

3. Реализуйте механизм обмена данными: Для обмена данными между микросервисами можно использовать различные протоколы, такие как REST, gRPC, GraphQL и т. д. Выбор протокола зависит от специфики вашего проекта.

4. Обеспечьте мониторинг и отслеживание: Важно иметь механизм мониторинга и отслеживания работы микросервисов. Это поможет выявить проблемы и улучшить производительность системы.

Пример интеграции микросервиса на языке программирования PHP:

// Пример кода для вызова микросервиса с использованием cURL
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, 'http://microservice-url/api');
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
$response = curl_exec($ch);
curl_close($ch);
 
// Обработка ответа от микросервиса
if ($response) {
    $data = json_decode($response, true);
    // Обработка данных от микросервиса
} else {
    // Обработка ошибки при вызове микросервиса
}

// Пример кода для вызова микросервиса с использованием cURL $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, 'http://microservice-url/api'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $response = curl_exec($ch); curl_close($ch); // Обработка ответа от микросервиса if ($response) { $data = json_decode($response, true); // Обработка данных от микросервиса } else { // Обработка ошибки при вызове микросервиса }

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

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно