Блог

Итак, в моем проекте uni профессор сказал, что мы можем попробовать использовать микросервисы, так почему бы не попробовать правильно? У меня есть одна проблемная мысль. Я понятия не имею, как взаимодействовать с интерфейсом (клиентское приложение) на серверной части.

С монолитом это легко. Интерфейс работает по адресу:порт xxxx серверная часть работает по адресу:порт гггг просто вызывайте порт гггг каждый раз, когда вам нужны данные. Но как вы делаете это с микросервисами, не имея тонны разных адресов в вашем интерфейсном коде?

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

В основном:

1.Интерфейс вызывает этот сервер в середине для продуктов

2.Сервер в середине видит, что интерфейсу нужны продукты, поэтому он вызывает микросервис продуктов на своем порту.

3.Возвращает результат микросервиса продуктов пользователю.

Сработает ли такой подход?

Есть слишком много способов. Нет ничего правильного или неправильного.

Если у вас много микроуслуг, скажем, более 10, service mesh обычно используется шаблон.где каждая служба может вызывать 1 или более нижестоящих служб. В этом случае каждая служба должна знать, от каких адресов других служб она зависит.

Если вы хотите проложить маршрут через одну службу. Что ж, это шаблон шлюза. Где все ваши запросы проходят через одну службу, а она, в свою очередь, направляется в нижестоящие службы.

Например: 192.168.14.2:8080/учетная запись 192.168.14.2:8080/что-то

В зависимости от маршрутов эта служба шлюза может вызывать accout-service или something-service не подходит, когда вы со временем добавляете дополнительные службы. Нагрузка на службу шлюза увеличится, и она станет единственной точкой отказа, например, вы можете использовать spring cloud gateway. Это в точности похоже на ваше решение

Надеюсь, это ответ на ваш вопрос