Правильно ли я использую микросервисную архитектуру?
Такой вопрос. Раньше я занимался, в основном, разработкой монолитных приложений. В новом проекте было принято использовать микросервисную архитектуру, но это абсолютно новый и пока еще незнакомый для меня подход.
Из того, что я понял - необходимо продумать и разбить приложение на маленькие независимые сервисы ( со своими БД). Как правило, сервисы общаются между собой через REST API + можно использовать брокеры сообщений..
Так же в микросервисном подходе используется API GATEWAY. Я так понял, что это такая точка входа, которая может проксировать запрос к внутреннему сервису, может сама обращаться к сервисам, затем агрегировать полученные данные и возвращать клиенту. Так же API GATEWAY может проверять, что запрос от авторизованного пользователя, может кэшировать какие-то запросы, и т.д.
Так вот. Если в монолитных приложения с рендерингом шаблонов страниц все было понятно, то здесь не очень. Общение с сервисами происходит через REST API, т.е. возвращаются данные для шаблона. А откуда должны браться сами шаблоны? Как будет правильно? Придется делать отдельный сервис, который отдает шаблон в зависимости от запрошенного url?
было принято использовать микросервисную архитектуру
все было понятно, то здесь не очень.
Похоже на "Поди туда - не знаю куда".
А цель какая? Это ведь тоже надо рассматривать как "инструмент по задаче". Расходы времени точно вырастут. Если попробовать/поиграться - то ок.
Есть ещё 3-й тип, когда делается монолит но с изолированными компонентами (микросервисами) внутри - нет столько возни деплоя как с микросервисами, и нет затрат (сетевых) на вызов микросервиса. А когда приходит реальная необходимость выделить компонент в микросервис, то он легко отпочковывается.
по идее ваш api gateway или точка входа просит другой сервис сделать работу, делигирует задачу так сказать. А далее уже - как выходит. Иногда да, рендринг шаблонов происходит отдельным адаптером к микросервису (если у нас несколько интерфейсов), иногда самим микросервисом и т.д. Тут как удобнее собственно.