Как синхронизировать БД при использовании архитектуры микросервисов?
Im собирается узнать, как работает архитектура микросервисов. До сих пор я не понимал, что каждому микросервису нужна своя база данных, которая имеет смысл.
Итак, скажем, у нас есть микросервис клиента, который отвечает за создание клиента и возврат списка клиентов. Служба ofcource будет иметь собственную клиентскую БД.
Допустим, у нас очень высокая нагрузка на этот сервис, поэтому мы выбираем масштаб 20x.
Så у нас есть 20 микросервисов и каждый имейте свою собственную БД, и все службы находятся за балансировщиком нагрузки.
теперь клиент хочет создать клиента, балансировщик нагрузки отправляет запрос клиента в службу 9/20, и клиент создается.
при следующем запросе тот же клиент хочет убедиться, что клиент создан и хочет просмотреть список клиентов, по запросу LB отправляет его в службу 11/20.
теперь, как я могу убедиться, что служба 9/20 синхронизировала вновь созданного клиента с БД услуги 11/20?
в MSSQL есть функциональность, чтобы синхронизировать БД, прежде чем отказаться от начальной фиксации, чтобы сначала сохранить данные во всех других базах данных, но этот подход даст проблемы в долгосрочной перспективе, потому что чем больше служб, тем больше времени потребуется для фиксации?
3 ответов
каждый микрослужб нужна своя база данных
отдельная БД на микросервис не является обязательным условием (или требованием, на самом деле).
вы можете иметь столько микросервисов, сколько хотите, работающих поверх одной базы данных, но использовать разные схемы, например.
в ограниченном контексте конструирование должны быть границы.
Допустим, у нас очень высокая нагрузка на эту услугу, поэтому мы выбираем масштабирование 20x.
масштабирование до (X) экземпляров одной и той же микросервиса не обязательно означает наличие отдельной базы данных для каждого экземпляра той же службы.
большинство баз данных разработаны с учетом параллельных соединений, пользователей, транзакций. один экземпляр базы данных (с некоторым оптимистичным параллелизмом) может обрабатывать сотни (если не тысячи) параллельных подключений изящно.
Если вы явно выбрали отдельный DB для каждого экземпляра тот же сервис, тогда вам придется синхронизировать эти базы данных. и, скорее всего, от этого пострадает согласованность данных.
вот несколько советов:
используйте одну базу данных на микросервис (не на экземпляр) независимо от того, сколько экземпляров ее использует. И рассматривайте только БД на экземпляр, когда вы уверены, что одна БД не может справиться с нагрузкой.
используйте общий слой кэша поверх БД (возможно, redis кэш)
используйте кластер баз данных для работы с высокой нагрузкой/доступностью баз данных.
Это может быть достигнуто с помощью шаблона проектирования CQRS, который является разделением создания и просмотра сущности, следуя асинхронной парадигме.
при создании мы помещаем постоянство сущности в Kafka / RabbitMQ и помещаем его в базу данных асинхронно. Материализованные представления могут быть созданы в БД, что делает поиск быстрее.
при использовании одной и той же базы данных для нескольких служб можно избежать, так как это создаст более высокую связь между службами, чем желательно. Е. Г. время простоя базы данных коснется всех сервисов обмена, но только один, если каждая служба имеет свой собственный.
чтобы избежать "распределенного монолита" сервисов, которые делают синхронные вызовы друг другу (например, используя REST), вы можете работать с потоковым подходом. Каждая служба будет публиковать изменения событие, когда его данные изменяются, и другие службы могут подписаться на эти потоки. Таким образом, они могут реагировать на изменения данных, относящиеся к ним, например, путем хранения локальной версии данных (в представлении, подходящем для их потребностей, например, только столбцы, которые они заинтересованы int) в своей собственной базе данных. Таким образом, они могут предоставлять свои функции, а также если другие службы недоступны в течение некоторого времени. Естественно, такая архитектура использует семантику возможной согласованности, но обычно это неизбежно в распределенные системы в любом случае.
один из способов настроить такие потоки данных-изменить CDC Data capture, который будет отслеживать файлы журналов баз данных (например, binlog в MySQL) и публиковать соответствующие события для каждой вставки, обновления и удаления. Одним из инструментов CDC с открытым исходным кодом является Debezium который поставляется с соединителями для MySQL, Postgres, MongoDB, а также (работа в процессе на данный момент) Oracle и SQL Server. Его можно использовать с Apache Kafka в качестве магистрали потоковой передачи или библиотеки в ваших Java-приложениях, позволяя вам передавать изменения данных в другие потоковые слои, такие как Pulsar или Kinesis, только с небольшим количеством кода. Одним из приятных преимуществ использования постоянных тем для событий изменений, например, с Kafka, является то, что новые службы могут придумать и перечитать весь поток изменений (в зависимости от политики хранения темы) или просто получить текущее состояние каждой записи, чтобы сделать начальное семя своей локальной базы данных.
(отказ от ответственности: я ведущий Debezium)