Spring Web Application architecture

Question

Я изучаю Spring Framework. Поэтому я хочу создать приложение, архитектура которого будет достаточно хорошей. Например, мое приложение будет какой-то социальной сетью. Я использую контейнер Spring Boot для этого веб-приложения. Правильно ли эта архитектура? Я имею в виду масштабируемость, будущую поддержку кода и т. Д. Каковы преимущества и недостатки? Я хочу использовать REST api и микросервисы. 1 страница = 1 контроллер = 1.

Answer 1

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

Могу ли я также предложить вам не нарушать работу, когда вам не нужно. Все ваши микросервисы, которые вы планируете, могут быть компонентами вашего приложения. В противном случае вы обнаружите, что у вас есть огромные накладные расходы на поддержание кода, который просто пересылает и получает HTTP-запросы. Это также может стоить вам чрезвычайно ценного инструмента: Сделки! Вы потеряете транзакции, и это может привести к несогласованности в поддержании данных. Имейте в виду только одного человека. Я пытаюсь закончить webapp, над которым я работал, на котором выполнено 95%, и я провожу 8 часов в день после работы, работая над ним до 2 утра. Сделайте себе одолжение и не создавайте больше работы для себя.

Answer 2

Я согласен с большинством баллов Snickers3192's answer. Микросервисы - это не то, что вам следует планировать, прежде всего, ваше приложение должно существовать, а монолит - для начала. Мартин Фаулер написал a good piece about the Microservices yes or no question. Как только ваше приложение растет, и вы видите необходимость в том, чтобы отдельные части вашего приложения были масштабированы отдельно или команды, которые должны были иметь возможность самостоятельно развиваться, тогда у вас есть бизнес-пример для Microservices (и, как вы увидите из статьи Фаулера, вы также должны быть готовы поддержать такую ​​архитектуру). Прямо сейчас это переоценка.

Сказанное: Если вы начнете с монолита и планируете позже перейти на Microservices, тогда вам нужно обратить внимание на свое дерево зависимостей. Различные части вашего приложения должны будут обращаться друг к другу, и это нормально, но убедитесь, что вы не вводите круговые зависимости, иначе извлечение Microservices позже станет кошмаром. В идеале вы можете определить интерфейсы служб, которые вы будете использовать, и реализовать их локально сейчас, но позже сможете реализовать их, вызвав Rest API.

Образец, который вы предлагаете (1 услуга для 1 контроллера), сопоставляется с шаблоном Backends for Frontends, что может быть хорошей идеей, в зависимости от сложности вашего веб-сайта. Если у вас много компонентов пользовательского интерфейса, которые совместно используются контроллерами, то вы, вероятно, захотите принять другой подход, например. Big Pipe. Но имеет смысл иметь один контроллер, который связывает все, что должна знать данная страница, и делегирует ее в восходящие службы независимо от того, все ли это на одном компьютере или в архитектуре Microservice.

И наконец: если вы идете с Microservices, обратите внимание на устойчивость. Используйте автоматический выключатель, такой как Hystrix или управляемая событиями архитектура, иначе один умирающий сервис может уничтожить всю архитектуру.