Развертывание микросервисов и их баз данных на отдельных узлах

Question

У меня общий вопрос, касающийся микросервисных приложений и их развертывания.

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

Например, если я использую Docker, могу ли я развернуть микросервис X и соответствующую базу данных X в двух разных контейнерах, расположенных на двух разных машинах с отдельными IP-адресами?

Это должно быть возможно с дополнительными возможностями. Однако, что делает меня любопытным на самом деле, что бы говорить за или против такого подхода? Будет ли какая-то выгода от этого? Или это будет просто чрезмерная инженерия?

Answer 1

Например, если я использую Docker, могу ли я развернуть микросервис X и соответствующая база данных X в двух разных контейнерах, расположенных в двух разные машины с отдельными IP-адресами?

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

Недостатки: Что ж, у вас будет небольшая задержка в сети, и вам придется обслуживать две разные "машины".

ПРИМЕЧАНИЕ: «Две разные машины» спорны, так как вы можете оказаться в двух разных виртуальных машинах на одной физической машине, если только вы не используете биметаллические машины в своем собственном центре обработки данных.

Answer 2

Причина, по которой вас просят не предоставлять общий доступ к базам данных, заключается в том, что вы связываетесь с другими службами только через API-контракты и ничего больше, предоставляя вам свободу изменять что-либо за вашим API.

Теперь, независимо от того, разворачиваете ли вы все свои сервисы на одном узле или на n разных узлах, микросервисы не определяются. Это продиктовано вашими требованиями, масштабом и степенью устойчивости системы.

Если вам нужно масштабировать, вы можете сделать это, развернув один и тот же контейнер на одном и том же узле несколько раз, но это не даст вам отказоустойчивости, ваша машина выйдет из строя, а ваша служба будет недоступна. Наличие их на двух разных узлах или в двух разных местах в целом зависит от ваших требований. У каждого из них есть свои плюсы и минусы, и это ваш выбор.

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