это более безопасно?
Нет.Это не.Фактически, это менее безопасно, поскольку поверхность атаки больше.И вам нужно индивидуально аутентифицировать и авторизовать каждую службу.
лучшая производительность?
Нет.Вызовы функций в одном и том же приложении намного быстрее, чем сериализация -> задержка в сети (издержки http (s)) -> десериализация -> обработка -> сериализация -> задержка сети (издержки http (s)) -> десериализация
есть особые особенности разработки, которые мы должны учитывать?
Да, стратегия развертывания, обнаружение службы, постепенное снижение производительности в случае недоступности восходящей службы.
то есть тогда сервер REST не работает?нужно ли кэшировать данные на сервере приложений?
Это зависит от ситуации, универсального ответа на этот вопрос нет.Поверьте мне, никто, кроме вашей команды / владельца продукта, не может ответить на этот вопрос.В основном это решение будет основываться на договоре, который вы заключаете с вашими потребителями.Я бы посоветовал прочесть о разрыве цепи / постепенном ухудшении / кодах ответов http для частичного ответа и т. Д.
у нас также есть некоторая простая логика на стороне клиента, такая как «забыть пароль», какой сервер обрабатывает это?(Сервер приложений или REST), кто из них обрабатывает аутентификацию?
Исходя из этого вопроса, я предполагаю, что у вас пока нет четкого разделения для отдельных обязанностей каждой службы.Возникает вопрос, зачем разделять их на 2 в данный момент времени .Почему не все функции находятся в одном приложении?По мере развития, когда вы начинаете ощущать боль от монолитного приложения, вы можете пересмотреть свою архитектуру и разбить ее на мелкие кусочки, если сочтете нужным.На мой взгляд, для небольших приложений монолитная архитектура гораздо более управляема, чем микросервисы.
Только одно скромное предложение, я бы не назвал один сервис REST и другой сервер приложений, который может создать впечатление, что вы можетеглядя это с неправильного угла.
По моему мнению, если я подойду к моменту, когда мое монолитное приложение больше не будет управляемым, я бы разделил его по функциональности (посмотрите на несвязанные объекты и извлеките их как отдельный сервис)