Микросервисы с общей базой данных? используя несколько ORM?

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

Дело в том, что один из моих товарищей по команде хочет использовать одну базу данных для всех служб, разделяя все таблицы, чтобы "данные не повторялись", каждая служба была бы построена с различными фреймворками и языками, такими как django и rails, которые используют очень разные стандарты ORM.

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

Ответ 1

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

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

Вот цитата из Вернера Фогельса, технического директора Amazon (Amazon впервые разработала архитектуру стиля Microservices):

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

Для получения дополнительной информации прочтите this и this.

Ответ 2

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

На практике некоторые из услуг могут быть очень связаны друг с другом. Например. Сервисы CustomerShippingDetails и CustomerShoppingCheckout могут обращаться к одному и тому же адресу данных - клиенту. Как вы могли бы решить проблему предоставления клиентского адреса клиенту? Если служба проверки напрямую запрашивает данные о покупках, вы теряете связь между службами. Другим вариантом является введение общей базы данных.

В архитектуре всегда должен быть какой-то компромисс. Что такое sacreficed - это архитектурное решение, которое сильно зависит от большой картины (дизайн всей системы).

Не имея слишком много подробностей о вашей системе, я бы пошел со смешанным подходом. То есть, имея общую базу данных для служб, которые занимаются подобной бизнес-логикой. Таким образом, CustomerShippingDetails и CustomerShoppingCheckout могут совместно использовать базу данных. Но StoreItemsDetails будет иметь отдельную базу данных.

Подробнее о шаблоне общей базы данных для микросервисов вы найдете в Архитектура Microservice.