Чем микросервисы на backend хороши в больших проектах ?
Из опыта скажу что микросервисы очень хорошая вещь, которая помогает большим проектам жить более спокойно. Очень часто были такие случаи когда в какой-то момент прибегает заказчик и кричит что все упало и ничего не работает. Это возникает в том случае если у вас монолит, который допустим из-за обработки большого файла может просто лечь.
Микросервисы в этом же случае помогает распределить ответcтвенность и уже если какой-то сегмент приложения упадет, он не затронет другой. Это очень хороший способ снять отвественность с единой точки.
Это что касается того что будет видно сразу и понятно сразу же. Но есть еще момент из-за которого на больших проектах микросервисы предпочтительней нежели монолит
Как-то когда работал, прилетел мне один проект, проект был легаси, честно говоря и к тому же большой. Такие проекты это головная боль, рефакторить их это дело то еще. Если изначально начинать разработку микросервисов, вы обезопасите себя тем что вы можете кусками просматривать/разрабатывать ваше приложение. Вы можете отдавать эти куски разным командам, которые даже не будут предполагать о других составных частях.
Теперь более технически: Для разработки микросервисов я использовал как брокер rabbitmq (недавно узнал что этот брокер самый медленный), оборачивал это все в докер и пулял на сервер. Если же были разные сервера, то там связь была просто по http. Важно понимать что базы у микросервисов должны быть отдельные иначе это не микросервисы. Так же еще важно понимать что передача сообщений должно быть защищенным, чтобы никакой залетный пассажир не получил важную информацию.
По литературе посоветую: Микросервисы (Крис Ричардсон).
Если интересно могу накидать оттуда интересных моментов, поддержи меня только реакцией
Из опыта скажу что микросервисы очень хорошая вещь, которая помогает большим проектам жить более спокойно. Очень часто были такие случаи когда в какой-то момент прибегает заказчик и кричит что все упало и ничего не работает. Это возникает в том случае если у вас монолит, который допустим из-за обработки большого файла может просто лечь.
Микросервисы в этом же случае помогает распределить ответcтвенность и уже если какой-то сегмент приложения упадет, он не затронет другой. Это очень хороший способ снять отвественность с единой точки.
Это что касается того что будет видно сразу и понятно сразу же. Но есть еще момент из-за которого на больших проектах микросервисы предпочтительней нежели монолит
Как-то когда работал, прилетел мне один проект, проект был легаси, честно говоря и к тому же большой. Такие проекты это головная боль, рефакторить их это дело то еще. Если изначально начинать разработку микросервисов, вы обезопасите себя тем что вы можете кусками просматривать/разрабатывать ваше приложение. Вы можете отдавать эти куски разным командам, которые даже не будут предполагать о других составных частях.
Теперь более технически: Для разработки микросервисов я использовал как брокер rabbitmq (недавно узнал что этот брокер самый медленный), оборачивал это все в докер и пулял на сервер. Если же были разные сервера, то там связь была просто по http. Важно понимать что базы у микросервисов должны быть отдельные иначе это не микросервисы. Так же еще важно понимать что передача сообщений должно быть защищенным, чтобы никакой залетный пассажир не получил важную информацию.
По литературе посоветую: Микросервисы (Крис Ричардсон).
Если интересно могу накидать оттуда интересных моментов, поддержи меня только реакцией