Архитектура взаимодействия микросервисов с БД
Сейчас в монолите выглядит так: я примерно представляю сколько соединений и сколько запросов выдержит мой сервер, отталкиваясь от этих цифр я делаю пул соединений с ограничением максимального количества возможных соединений и запросов на одно соединение. Также делаю возможность выполнить запрос мимо пула соединений, для определенных действий, которым нужно гарантированное выполнение.
Получается что у меня есть два интерфейса для работы с БД, я их называю limited и unlimited. Через limited соединения (пул с ограничениями) выполняются запросы от пользователей и в случае слишком большого их количества, пользователи, которым не хватило соединений получат соответствующее сообщение, когда как внутренние запросы (unlimited), выполнение которых должно быть гарантировано, продолжат выполняться в любом случае.
Эти два интерфейса используются в разных частях бэка. Сейчас я планирую разделить бэк на несколько микросервисов. Вопрос в том, как лучше сделать архитектуру взаимодействия с БД.
Вариант 1: вынести работу с БД в отдельный микросервис, в котором будут экшны для limited и unlimited запросов.
Вариант 2: в каждом микросервисе, в котором есть необходимость использовать БД городить свои соединения и свои пулы.
На текущий момент лучшим решением в моих глазах выглядит первый вариант. В этом случае у меня будет один единственный сервис, в котором я могу задавать и изменять лимиты пула соединений и контролировать нагрузку. Из минусов пока вижу единую точку отказа.
Буду рад выслушать мнения и предложения на этот счет.
Ответы (1 шт):
Просто иметь узлы, что обмениваются информацией - это будет сервис ориентированная архитектура, которая может быть микросервисами, а может и не быть. Микросервисы - это про максимальную независимость. Вот тут можно почитать определение. Вот тут про базы данных.
По идее, у каждого микросервиса должна быть своя БД и свой пул к ней. Если у вас сервисы шарят одну и ту же БД, возможно у вас не микросервисы, а просто распределеный монолит, когда сервисы завязаны на одну базу, на одни таблицы. В микросервисах каждый сервис отвечает за своё и не шарит состояние, потому даже если у одного сервиса база совсем отвалится, остальные продолжают работать. Микросервисы - это про максимально независимый друг от друга функционал, у вас же наоборот.
Нагрузка на каждый сервис рассчитывается отдельно и каждый сервис масштабируется назависимо в микросервисах - это один из бонусов микросервисов, что можно нагруженные части сильно масштабировать, не нагруженные - не сильно. Вообще, масштабирование - это не только про код на хостах, но и про БД в том числе, которую тоже можно масштабироввть по разному или даже разные БД использовать, в зависимости от специфики запросов и каких букв из САР теоремы надо сохрнить. Потому иметь отдельный пул на сервис в микросервисной системе - это нормально, так и надо по идее.
Про обмен данными между микросервисами см Communication style паттерны тут.