Как реализовать запланированную работу в качестве микросервиса

Question

У меня есть приложение Spring Boot, которое предоставляет REST API для Angular веб-интерфейса.

В этом приложении Spring Boot также есть запланированное задание. Задача состоит в том, чтобы заполнить базу данных некоторыми объектами, скажем, книгами (они взяты из внешнего источника, в частности, с веб-сайта). Я хочу поместить эту работу в отдельный микросервис.

Вопрос в том, должен ли микросервис работать напрямую с общей базой данных или получать доступ к основному приложению через REST. В первом случае некоторые (если не все) модели и сервисы будут общими, это выглядит не очень хорошо. Но во втором случае каждый доступ к базе данных будет go через первое приложение. Это нормально?

Answer 1

Проверьте SOLID принцип дизайна.

S - для Single Responsibility

В архитектуре микросервиса также есть шаблон с тем же именем: Принцип единой ответственности

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

Ни в один момент времени одна микросервис не должна иметь более одной ответственности.

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

Но, прочитав ваше описание, я бы предложил следующее:

• ваш текущий database-microservice должен быть подключен к БД и принимать HTTP-запросы на сохранение книг в базе данных;

• ваш новый cronjob-microservice должен начать работу вовремя получите книги с сайта и отправьте HTTP-запрос на database-microservice, поэтому он не должен быть подключен к базе данных.

Answer 2

Другой вариант - использовать очередь, подобную ActiveMQ, вместо REST.

cronjob-service выбирает книги и проверяет данные, например. Вы можете хранить данные где-нибудь в формате файла, например CSV. Это может быть сохранено в S3 Bucket на AWS или что-то в этом роде. cronjob-service затем отправляет ссылку на этот файл через очередь, а database-service выбирает данные и сохраняет их.

Преимущество перед REST заключается в том, что задача не может быть потеряна. Если вы по database-service не работаете или по какой-то причине заняты, запрос REST вернет 404, и вы должны реализовать против него отказоустойчивость. В очереди задача сохраняется в очереди. Даже если экземпляр database-service начинает обрабатывать задачу и по какой-то причине не выполняется, задача все еще находится в очереди, а другой экземпляр database-service может ее взять и обработать.