Как разработать приложение на основе микросервиса, в котором каждый микросервис имеет собственный источник данных?
Я разрабатываю приложение на основе микросервисов, в котором есть службы, использующие информацию из базы данных MySQL. Есть две службы - служба бронирования и служба оплаты.
Платежной службе требуется информация от службы бронирования.
Как спроектировать это с использованием MySQL, сохраняя при этом отдельные базы данных для обеих служб? Как обеспечить соблюдение реляционных ограничений между двумя таблицами, находящимися в разных базах данных?
P.S: Я использую Spring Boot для разработки веб-сервисов.
Значит, выставление счетов за оплату бронирования все эти отдельные услуги должны быть объединены в одну услугу?
Ответы 2
Микросервисам рекомендуется использовать разные базы данных и хранить свои собственные данные (Полиглот).
Обмен данными через API должен происходить через API.
В этом случае, если платежной службе требуются данные бронирования, эти данные следует получить, позвонив в API службы бронирования.
Подробнее см. В статье Мартина Фаулера ссылка на сайт to microservices.
Я не думаю, что платежная служба должна вызывать API службы бронирования. Платежная служба не должна даже заботиться о существовании службы бронирования и даже не знать о ней! Вместо этого платежный сервис должен просто прослушивать события, чтобы обновить свое хранилище данных для обеспечения согласованности с тем, что ему нужно. См. Ответ techagrammer, посвященный этому.
Персистентность полиглота ортогональна разделению баз данных - у вас может быть монолит, который взаимодействует с несколькими различными видами сохраняемости, или набор микросервисов, которые все используют разные экземпляры одной и той же технологии сохраняемости.
В микросервисах нет ничего, что называется реляционной согласованностью, ваша система должна в конечном итоге стать согласованной.
Возьмем ваш случай, у вас есть два микросервиса с diff. БД
- Бронирование
- Оплата
Теперь предположим, что кто-то создал бронирование и теперь хочет оплатить бронирование с помощью платежного сервиса.
Вы, должно быть, думаете, что это Платежная служба, я должен проверить, существует ли бронирование или нет, отменено или нет.
Вышеупомянутые проверки могут быть выполнены, но не на 100%, без создания очень высокой зависимости между службами, что противоречит принципам микросервисов.
Приведу пример:
- Кто-то отменил бронирование во время выполнения платежа - предположим, что вы обрабатываете платеж в платежной службе после того, как проверили, что бронирование разрешено Службой бронирования, в то время как платеж выполняется, кто-то отменил бронирование.
Теперь, поскольку в этом случае система временно находится в несогласованном состоянии, вам следует сделать это, исходя из событий в Службе бронирования, таких как BookingCancelled, проверить, приняли ли мы платеж, да, затем начать процесс обратного платежа, а не проверять все сразу.
Go for a eventual consistent system in which both service listen to events to one other and tries to be consistent.
Вы не можете навязать реляционные ограничения между двумя отдельными базами данных - если вы считаете, что вам это нужно, ваши две службы слишком тесно связаны, чтобы быть отдельными микросервисами.