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

Я читал о микросервисах, и мне кажется нелогичным создавать отдельную БД для каждой службы просто для достижения изоляции. Я могу добиться того же, используя только веб-сервисы и единую базу данных. Зачем нам это вообще нужно? Дело в том, что отдельная база данных не подлежит обсуждению. Или я не прав? Можете ли вы направить меня в этом?

Зачем нам это вообще нужно?

Вы не

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

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

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

Я видел людей, которые тривиально относятся к этой идее, как «каждый микросервис должен владеть и контролировать свою собственную базу данных, и никакие два сервиса не должны совместно использовать базу данных». Идея обоснована: не разделяйте одну базу данных между службами, потому что тогда вы столкнетесь с конфликтами, такими как конкурирующие шаблоны чтения / записи, конфликты моделей данных, проблемы координации и т. Д.

Но единая база данных предоставляет нам много возможностей для обеспечения безопасности и удобства: транзакции ACID, единственное место для поиска, понятное (вроде?), Одно место для управления и т. Д.

Путешествие к микросервисам - это просто путешествие . Это будет отличаться для каждой компании. Здесь нет жестких и быстрых правил, есть только компромиссы.

Самое сложное в микросервисах: ваши данные

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

Микросервисы позволяют самостоятельно развертывать и масштабировать вещи на «микро» уровне. Такая гранулярность обеспечивает множество технических преимуществ и даже больше нетехнических преимуществ, поскольку позволяет лучше разделять команды разработчиков, выпускать при необходимости, а не один большой выпуск, опробовать новые технологии или процессы изолированно и т. Д. Наличие общей базы данных убивает Многое из-за зависимости от БД. Если вы не можете развернуть свой сервис, не беспокоясь о данных другого сервиса, вы потеряли.

Дело в том, что отдельная база данных не подлежит обсуждению. Или я не прав?

Тем не менее, вы также совершенно не правы.

Когда вы работаете в облаке, базы данных дешевы. Обычно бесплатно! Конечно, сервер стоит денег, но мы не говорим об отдельном сервере на микросервис (по крайней мере, сначала). Один сервер с кучей (логических) баз данных хорош, если вы старательно избегаете запросов между базами данных (которые вводят зависимости, которые наносят вред «независимо развертываемым и масштабируемым»). Черт, перекрестные запросы к БД невозможны в некоторых облачных сервисах баз данных, таких как Azure SQL. Вам даже не нужно быть прилежным там ...

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

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

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

Зачем нам это вообще нужно?

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

Посмотрите на Amazon AWS или Twilio. Вы знаете, реализованы ли их сервисы на Java или Ruby? Они используют Oracle или PostgreSQL или Cassandra или MongoDB? Сколько машин они используют? Тебя это вообще волнует; другими словами, влияют ли эти технологические решения на то, как вы используете эти сервисы? ... И что более важно, если они перейдут на другую базу данных, придется ли вам соответствующим образом изменять свое клиентское приложение?

Что произойдет, если два сервиса используют одну и ту же базу данных? Вот небольшая часть проблем, которые могут возникнуть:

• Группа разработчиков службы 1 хочет перейти с SQL Server 2012 на SQL Server 2016. Однако группа 2 использует устаревшую функцию, которая была удалена в SQL Server 2016.

• Сервис 1 пользуется огромным успехом. Размещение базы данных на двух машинах (master и failover) больше не вариант. Но масштабирование кластера на несколько машин требует таких стратегий, как разбиение. Между тем, команда 2 довольна нынешним масштабом и не видит причин переходить к чему-либо еще.

• Служба 1 должна перейти на UTF-8 в качестве кодировки по умолчанию. Служба 2, однако, рада использовать кодовую страницу Windows Latin 1.

• Служба 1 решает добавить пользователя с определенным именем. Однако этот пользователь уже существует, созданный несколько месяцев назад второй командой.

• Сервису 1 нужно много разных функций. Служба 2 является критически важным компонентом и должна поддерживать минимальные возможности базы данных, чтобы снизить риск атак.

• Служба 1 требует 15 ТБ дискового пространства; скорость не важна, поэтому обычные жесткие диски в порядке. Для службы 2 требуется не более 50 ГБ, но требуется доступ к ней как можно быстрее, то есть данные должны храниться на SSD.

• ...

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

это слишком [...] неуправляемо.

Тогда вы делаете это неправильно. Я полагаю, вы развертываете вручную .

Это не то, как все должно быть сделано. Вам необходимо автоматизировать развертывание виртуальных машин (или контейнеров Docker), на которых выполняется база данных. После их автоматизации развертывание двух серверов, двадцати серверов или двух тысяч серверов не сильно отличается.

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

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

это слишком дорого

Определите стоимость.

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

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

Если ваша проблема связана с памятью, то виртуальные машины не являются хорошим выбором для вас. Контейнеры есть. Вы сможете охватить столько, сколько захотите, зная, что они не потребляют больше оперативной памяти, чем необходимо. Хотя общее потребление памяти будет большим для множества небольших баз данных по сравнению с одной большой, я полагаю, что разница не будет слишком важной. YMMV.

Зависит от того, что вы считаете «дорогим».

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

Все эти службы могут также использовать один экземпляр / сервер базы данных и иметь только изолированные схемы для каждой службы.

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

Лучший способ, которым служба может владеть и контролировать свои данные, - это иметь собственную «личную» базу данных. Это обеспечивает полную свободу выбора технологии и схемы передачи данных. Единственный способ, которым любой другой сервис может получить доступ к данным, принадлежащим сервису, - запросить данные у сервиса. Таким образом, если необходимо изменить внутреннее представление данных, его можно легко изменить, и никакие другие сервисы не сломаются.

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