Микросервисная архитектура для сервера

[akudinov28]

enotit написал(а):

б) добавляется публичный интерфейс обращения к БД*, если сделать один лишний шаг, то и игровой сервер окажется в перде.

Нажмите для раскрытия...

Справедливости ради - проблема частично решается ограничением доступа с помощью файрвола. В настройках самой СУБД указываешь адреса, которые могут подключаться к БД, плюс в файрволе правилом дублируешь. В таком случае для доступа к базе данных тебе нужно будет либо ломать сервер БД, либо ломать один из серверов, которые могут к ней обращаться.

 

[enotit]

iuvis написал(а):

Немного офтопа, а расскажи про приведённый тобой пример MVC. Интересно стало.

Нажмите для раскрытия...

Я думаю он не столь интересен, ибо больше специфичный. Собес на разраба cms-ки на php. А так, про устройство внутреннего механизма "компонент" (ниже есть мой тгк, про мой опыт, не реклама).
Просто в общем, сколько я собешусь, сколько я собешу, то в сумме спрашивают базу "model view controller", а как это выглядит наяву, то мало кто знает. Особенно в битре.

akudinov28 написал(а):

Справедливости ради - проблема частично решается ограничением доступа с помощью файрвола. В настройках самой СУБД указываешь адреса, которые могут подключаться к БД, плюс в файрволе правилом дублируешь. В таком случае для доступа к базе данных тебе нужно будет либо ломать сервер БД, либо ломать один из серверов, которые могут к ней обращаться.

Нажмите для раскрытия...

Я как раз не про "сломать" БД, а про интерфейсы к ней. Что поставить ограничение на всех правах, это не проблема, базовые ограничения - понятно.
Можно нафлудить на некешируемые (если таковые вообще имеются) страницы, можно накидать запросами (если нет капчи). Понятно, что всё можно "исправить" "сделать хорошо", но живём не с пони. Чтоб так глобально архитектуру по бестпракису, то это ентерпрайз проект, а таких очень мало.

 

[23Serikk0z]

iuvis написал(а):

Из плюсов я вижу то, что обычно и выделяют в микросервисах - повышение отказоустойчивости, легче расширять инфраструктуру. Из минусов - вероятно достаточно высокую нагрузку на мосты между сервисами (что будет критично лишь для HTTP, пожалуй).

Нажмите для раскрытия...

честно тут метрика нужна раз такие большие запросы, пока на практике на реальных проектах, особенности в финтех gRPC чаще используется в таких моментах, ну и никому не секрет что все щас фин тех использует gRPC.

 

[23Serikk0z]

iuvis написал(а):

Авторизацию имеет смысл выносить в отдельный сервис, когда у тебя одинаковыми алгоритмами она производится в игре и на сайте в кабинете, условно.

Нажмите для раскрытия...

я бы посоветовал вынести это в гейтуэй намного легче на реактивке будет намного быстрее работать