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

Question

[razer96]

Всем доброго дня. Опытные DevOps подскажите)) Могут ли два микросервиса быть зависимыми друг от друга так, что у них будет общая база данных?

В кратце. Есть один сервис( дадим ему условное имя А ) на котором крутится сервер Socket.io, и он обрабатывает все ивенты сокета и частично ему нужен доступ к базе данных со всей логикой связанной с комнатами?
И есть второй сервис( дадим ему условное имя В), который полностью реализует бизнес логику комнат и их функционала.

Например. Некий пользователь решил создать новую комнату. Он посылает запрос на сервис В, для того чтобы сохранить созданную им комнату( в модели данной комнаты хранится массив подключений ). Дальше пользователь должен подключиться к этой комнате, и он уже тригерит ивент joinRoom на сервисе A. Сервис А должен сохранить подключенного пользователя в комнату. И вот для подобной ситуации, я думаю нужна общая база. Можно ли так сделать? И какие от этого могут быть недостатки? Заранее спасибо

Answer 1

[Andrey Shatokhin]

Не плодите лишние микросервисы. Вам же будет сложней в отладке и тестировании.
По Вашему вопросу - плохая практика использовать одну бд в разных микросервисах.

Comments

[razer96]

Но если оно того требует? Просто например один сервис должен держать до 5000-10000 одновременных соеденений по WebSocket, и если этот же сервер еще будет и обрабатывать бизнес логику принимая примерно 100-200 http запросов в секунду, хотя данную бизнес логику может выполнять и другой сервис, так как большая часть этой логики ни как не должна напрямую взаимодействовать с Socket.io сервером. Как быть тогда?

[Andrey Shatokhin]

razer96, Не путайте Микросервисы и проблему масштабирования нагрузки. Микросервисы позволяют упростить масштабирование, но вопрос нагрузки они не решают. А если сделаете с общей бд - так и не упростят они у вас ничего.

[nrgian]

razer96,

Но если оно того требует? Просто например один сервис должен держать до 5000-10000 одновременных соеденений по WebSocket, и если этот же сервер еще будет и обрабатывать бизнес логику принимая примерно 100-200 http запросов в секунду, хотя данную бизнес логику может выполнять и другой сервис, так как большая часть этой логики ни как не должна напрямую взаимодействовать с Socket.io сервером. Как быть тогда?

Это всё решаемо и в монолитной архитектуре.
И даже еще более эффективно по возможностям той же аппаратуры на удержание высокой нагрузки.

Вы пытаетесь резать на микросервисы вертикально - по этапам обработки запроса в длинной цепочке.

А нужно резать горизонтально - по функционалу. И по возможности, не пересекающемуся.

[nrgian]

Andrey Shatokhin,

А если сделаете с общей бд - так и не упростят они у вас ничего.

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

Но это маловероятно.

Скорее всего, затык будет именно в обращении к БД, как вы и написали.

[razer96]

nrgian, Хорошо, благодарю за советы. Тогда рассмотрим вариант того, чтобы сделать общий сервис. Мы видимо и правда ошиблись в проектировании. Благодарю.

Answer 2

[nrgian]

Могут, если сильно хочется.
Но не нужно, в общем случае.

Идея микросервисов и цель их создания - в их независимости друг от друга, в автономности.

Поэтому в идеальном случае у микросервисов:

• и БД должны быть независимыми
  
• и запросы, по возможности, должны быть такими, чтобы не приходилось на каждый чих дергать по цепочке все до единого микросервисы
  

если у вас не так:
то в проектировании ошибка, которая аукнется потом проблемами по производительности и по масштабированию - а масштабирование это, собственно, и есть то, за ради чего микросервисы придуманы.

исключение - какие-то общесистемные вещи, типа микросервиса, отвечающего за аутентификацию/авторизацию.

Comments

[razer96]

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

[nrgian]

razer96,

Я просто читал о подобных исключениях, когда два микросервиса обращались к одной базе

Это возможно.
Но для этого должна быть веская причина

и идея было именно в том, что у них была тесно связанная бизнеслогика.

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

[razer96]

nrgian, А чем с точки зрения производительности будет лучше, если будет больший трафик идти на один сервис? Из описанной мною ситуации, думаете это будет лучше?

[nrgian]

razer96,

А чем с точки зрения производительности будет лучше, если будет больший трафик идти на один сервис? Из описанной мною ситуации, думаете это будет лучше?

По описанной вами схеме:

В кратце. Есть один сервис( дадим ему условное имя А ) на котором крутится сервер Socket.io, и он обрабатывает все ивенты сокета и частично ему нужен доступ к базе данных со всей логикой связанной с комнатами?
И есть второй сервис( дадим ему условное имя В), который полностью реализует бизнес логику комнат и их функционала.

Вижу только одно достоинство:

Что можно масштабировать количеством отдельно сервисы А и сервисы B.
То есть можно сделать очень много А и очень мало В или же наоборот.

Однако по характеру описанной вами нагрузки (из того, где именно и какой функционал реализован) видно, что при таком разделении вы имеете кучу накладных расходов.

Но при этом, насколько я понял из вашего описания, если А+В будут работать в одном большом сервисе - этих накладных расходов не будет.

Да, вы не сможете масштабировать отдельно А или отдельно В.
Но если в ненагруженном состоянии А/В жрут мало ресурсов - то это неважно.

Другими словами:

• Создали вы сервис А+В.
  
• Функционал компоненты А в таком А+В потребовал отмасштабироваться до 100 экземпляров.
  
• При этом автоматически будет отмасштабирована и компонента В, так как она тоже часть единого сервиса А+В. Она будет отмасштабирована до 100 экземпляров, хотя ей этого и не надо было бы, а хватило бы и 5 экземпляров.
  
• При этом, если компонента В всегда и безусловно откусывает, к примеру, по 2 гигабайта оперативной памяти вне зависимости от нагрузки - разумеется, в данной ситуации это будет разбазариванием ресурсов.
  
• Вам потребуется 2*100 гигабайтов, хотя хватило бы 2*5 гигабайтов.
  
• Однако, если компонента В не резервирует под себя много ресурсов (тех же ресурсов оперативной памяти), пока они ей реально не понадобятся, то такой проблемы не будет.
  
  

[razer96]

nrgian, Понял, спасибо большое за консультацию. В коментарии к коментарию Andrey Shatokhin написал, что мы ошиблись при проектировании, и действительно пришли к вертикальному масштабированию вместо горизонтального, что оказалось не верно в корни. Спасибо. Склеим в таком случае эти два сервиса)

[nrgian]

razer96,

А чем с точки зрения производительности будет лучше, если будет больший трафик идти на один сервис?

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

От того, что перед СУБД у вас будет стоять 100 микросервисов - система не будет работать лучше, ибо самым узким местом останется база данных, которая одна-единственная.

Одним из способов хоть каким-то способом снять с неё нагрузку будет - разделить эту БД по функционалу. Тогда можно будет размещать такие меньшие по размерам отдельные мини-БД на отдельных физических серверах.

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

При этом, если вам для выполнения одного-единственного запроса понадобится собрать данные с нескольких таких мини-БД и объединить их, то ключевым моментом является возможность параллельного независимого выполнения нескольких запросов к нескольким этим мини-БД (напрямую в СУБД или опосредованно через микросервисы).

Если же логика вашей системы заставит запросы к таким мини-БД придется делать последовательно - проблема по производительности останется.