В данной реализации нет. Но на эту тему есть отличная статья от mail.ru, в ней коллеги пишут как можно использовать zero-copy upgrade на «голом» TCP-соединении. TCP работает сильно быстрее HTTP: BenchmarkUpgradeHTTP: 5156 ns/op 8576 B/op 9 allocs/op BenchmarkUpgradeTCP: 973 ns/op 0 B/op 0 allocs/op
Архитектура штука многогранная ) Монолиты и Микросервисы это два основных стрима внутри которых я имел удовольствие реализовывать различные архитектурные паттерны (MVC, listener, Event Sourcing, API GW, ORM и многое другое)
Простите, не совсем понял Ваш вопрос. Вы хотите чтобы я дал строгое определение монолита и микросервиса? Пожалуй я не готов это сделать, по мне так это очень халиварная тема и мне будет жаль потраченного времени. Но я могу поделиться своим практическим опытом, и продемонстрировать что в моей картине мира есть микросервис, а что монолит.
4. В зависимостях между сервисами часть стрелочек (например, комментарии зависят от User) опущена намеренно для «чистоты концепции»? — чистоты концепции
3. Каким образом обеспечивается целостность и непротиворечивость данных в трех экземплярах БД? — на уровне приложения. Это цена за независимость и распределенность.
2. При отказе сервиса User все будет продолжать работать? Really? — why not, все силно зависит от архитектуры решения и способа публикации.
— На том же K8s можно поднять сервис User в котором гарантировано будет работать несколько подов микросервиса.
— Сервисы потребители должны быть устойчивы к подобного рода кейсам и не крашиться, а например повторять запросы по затухающей шкале (в gRPC это реализовано из коробки)
— Если, например, вы используете патерн API Gateway, в этом случае функция аутентификации/авторизации может кэшироваться на API Gateway и в этой части критичность сервиса User снижается
Попробую ответить по пунктам
1.Каким образом межсервисное сетевое взаимодействие ... — имеется ввиду когда под нагрузкой монолит будет «вставать на коленки» микросервис развернутый, например, на K8s за LB будет автоматически скейлится и работать в штатном режиме.
Безусловно за LB можно поставить весь монолит, вопрос сколько Вам для этого потребуется ресурсов. Прелесть микросервисова в том, что вы масштабируете только узкие места, сохраняя производительность малой кровью.
Мое личное мнение, моно-репа это наследие мышления в системе координат монолитых решений. Избыточность кода, это цена за независимость и децентрализованность. Представьте что каждый отдельный микросервис «пилит» отдельная команда, которая ничего не знает о коде других команд. В этом смысле избыточность выглядет уже иначе )
В примере моно-репа использовалась для упрощения процесса запуска проекта и понимания структуры проекта в целом.
Из основных причин, пожалуй это высокая нагрузка, но из моего опыта у систем такого класса это достаточно редкое явление ) Также использование микросервисной архитектуры позволяет сделать разные части проекта независимыми, т.е. например, отказ в работе комментариев не отразится на работоспособности других сервисов. В целом, цель статьи показать вариант реализации взаимодействия между микросервисами на простом и понятном примере. MongoDB выбрана с целью децентрализации данных. Использование единой релеационной БД вносит ненужную связанность между микросервисами, а использование отдельных релеационных БД под каждый микросервис, на мой взгляд, избыточно.
BenchmarkUpgradeHTTP: 5156 ns/op 8576 B/op 9 allocs/op
BenchmarkUpgradeTCP: 973 ns/op 0 B/op 0 allocs/op
— На том же K8s можно поднять сервис User в котором гарантировано будет работать несколько подов микросервиса.
— Сервисы потребители должны быть устойчивы к подобного рода кейсам и не крашиться, а например повторять запросы по затухающей шкале (в gRPC это реализовано из коробки)
— Если, например, вы используете патерн API Gateway, в этом случае функция аутентификации/авторизации может кэшироваться на API Gateway и в этой части критичность сервиса User снижается
1.Каким образом межсервисное сетевое взаимодействие ... — имеется ввиду когда под нагрузкой монолит будет «вставать на коленки» микросервис развернутый, например, на K8s за LB будет автоматически скейлится и работать в штатном режиме.
Безусловно за LB можно поставить весь монолит, вопрос сколько Вам для этого потребуется ресурсов. Прелесть микросервисова в том, что вы масштабируете только узкие места, сохраняя производительность малой кровью.
В примере моно-репа использовалась для упрощения процесса запуска проекта и понимания структуры проекта в целом.