Микросервисы с общей базой данных? используя несколько ORM?
Я изучаю микросервисы, и я собираюсь построить проект с архитектурой микросервисов.
Дело в том, что один из моих товарищей по команде хочет использовать одну базу данных для всех служб, разделяя все таблицы, чтобы "данные не повторялись", каждая служба была бы построена с различными фреймворками и языками, такими как django и rails, которые используют очень разные стандарты ORM.
Каким будет правильный подход? Поскольку я думаю, что работа с одной базой данных будет включать в себя много "взлома" ORM, чтобы заставить их работать правильно.
Ответы
Ответ 1
Вы вряд ли выиграете от архитектуры Microservices, если все службы используют одни и те же таблицы базы данных. Это связано с тем, что вы эффективно тесно связаны с услугами. Если таблица базы данных изменится, все службы должны будут измениться.
Вы должны понимать, что вся причина для архитектуры Microservices заключается в том, чтобы уменьшить зависимости между командами разработчиков и позволить им двигаться вперед независимо от быстрых выпусков.
Вот цитата из Вернера Фогельса, технического директора Amazon (Amazon впервые разработала архитектуру стиля Microservices):
Для нас служебная ориентация означает инкапсуляцию данных с помощью бизнес-логика, которая работает с данными, с единственным доступом через опубликованный сервисный интерфейс. Запрет прямого доступа к базе данных из-за пределов службы, и нет обмена данными между услуги.
Для получения дополнительной информации прочтите this и this.
Ответ 2
В целом микросервис должен отвечать за свои собственные данные. Это идеальный мировой сценарий.
На практике некоторые из услуг могут быть очень связаны друг с другом. Например. Сервисы CustomerShippingDetails и CustomerShoppingCheckout могут обращаться к одному и тому же адресу данных - клиенту. Как вы могли бы решить проблему предоставления клиентского адреса клиенту? Если служба проверки напрямую запрашивает данные о покупках, вы теряете связь между службами. Другим вариантом является введение общей базы данных.
В архитектуре всегда должен быть какой-то компромисс. Что такое sacreficed - это архитектурное решение, которое сильно зависит от большой картины (дизайн всей системы).
Не имея слишком много подробностей о вашей системе, я бы пошел со смешанным подходом. То есть, имея общую базу данных для служб, которые занимаются подобной бизнес-логикой. Таким образом, CustomerShippingDetails и CustomerShoppingCheckout могут совместно использовать базу данных. Но StoreItemsDetails будет иметь отдельную базу данных.
Подробнее о шаблоне общей базы данных для микросервисов вы найдете в Архитектура Microservice.
