Подтвердить что ты не робот

Архитектура веб-приложения на основе микросервиса

Я смущен тем, что веб-приложение расходится в микросервисах - это уровень url или уровень модели? В качестве примера предположим, что у меня есть монолитное приложение, которое обслуживает 3 страницы. Скажите, что каждая страница обслуживает отдельную учетную запись, и я хочу вернуть их с помощью собственных микросервисов. Теперь, какой из них является правильным способом реализации архитектуры на основе микросервиса:

  • Я создаю три разных приложения (микросервисы), каждая из которых содержит (маршрут, контроллер, модели, шаблоны) для одной из страниц. И затем, на основе которого запрашивается страница, я направляю запрос в это конкретное приложение. Это означает, что вся страница из базы данных в HTML обслуживается отдельным приложением. В принципе, разные страницы на одном веб-сайте полностью обслуживаются различными приложениями на бэкэнд.
  • 3 микросервиса не обрабатывают материал пользовательского интерфейса, а только данные для их использования (модели, контроллер, без шаблонов) и выставляют его поверх REST api. У меня есть одно публичное приложение. Это приложение запрашивает три разных приложения (микросервисы) только для данных, а затем строит html-страницы, которые будут возвращены в браузер. Все страницы в веб-приложении в этом случае обслуживаются одним приложением, которое внутренне использует три разных микросервиса.

enter image description here

4b9b3361

ОТВЕТЫ

Ответ 1

Вы беспокоитесь, как моделировать ваши микросервисы.

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

Всегда, когда вы моделируете свои микросервисы, имейте в виду следующие факты.

  • Loose Coupling. Когда службы слабо связаны, изменение одной службы не требует изменения к другому. Весь смысл этой вещи Microservice заключается в том, чтобы внести изменения в одну услугу и развернуть ее независимо от необходимости изменять любую другую часть системы. Это действительно очень важно.

  • Сильная сплоченность. Мы хотим, чтобы связанное поведение сидели вместе и не связанное с этим поведение, чтобы сидеть в другом месте. Зачем? Ну, если мы хотим изменить поведение, мы хотим изменить его в одном месте и как можно скорее отпустить это изменение.

Ответ 2

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

Однако, учитывая формальное определение микросервисов, вариант 2 лучше иллюстрирует его. Одним из основных преимуществ использования микросервисов является его повторное использование. Различные приложения имеют разные требования и потребности в представлении информации. Создание ваших микросервисов приведет к представлению JSON ваших данных, что даст вам больше гибкости в том, как отформатировать эту информацию.

Ответ 3

Шаблон Api-шлюза Microservice apigateway - это первый момент, когда вы можете начать распространять или переадресовывать вызовы в разные службы