Монолитные против микросервисов:
лучший вариант - определенно микросервисы .с микросервисами вы можете получить по крайней мере следующие преимущества:
- независимо развертываемые службы
- с использованием различных технологий для каждой службы
- развертывание каждой части с различными конфигурациями
- размещайте ваши рабочие службы с высокой нагрузкой на отдельных серверах
- быстро восстанавливайте сбои, не затрагивая другие части
- создавайте облачный дизайн
- масштабируйте быстро и доступно
Дизайн требует понимания и командной работы.В качестве исходного решения я предлагаю:
- использовать один сервис, который направляет внешние запросы в вашу систему и действует как шлюз API.Nginx - хороший выбор.
- доступ ко всем остальным сервисам возможен только изнутри.
- для связи между сервисами, вы можете предоставить rest-API для каждого или
- для использованияброкер сообщений.
Я предлагаю RabbitMQ (Кафка в некоторых случаях более подходит).каждая служба подписывается на несколько каналов в брокере сообщений.при получении связанного события, такого как «URL-адрес вставлен», оно определяет для себя новую задачу и начинает обработку задания (например, сканирование веб-сайта по этому URL-адресу).после этого он может отправить брокеру новое событие, такое как «обработанный веб-сайт», и поэтому другие службы будут проинформированы, в то время как каждая из них знает, что делать после.
- служба, отвечающая за ответ пользователюпри получении запроса на выполнение длительной работы уведомляет другие службы через их API или отправляет брокеру новое событие и связанные с ним данные, после чего отправляет сообщение об успешном выполнении пользователю.
- службы могутзапускать новые задачи после новых событий или по расписанию.
Некоторые подсказки:
использование контейнеров с чем-то вроде Docker.при этом вы можете использовать такие инструменты, как Docker Swarm или Kubernetes.они дают вам бесценные преимущества:
- простое обслуживание
- высокая доступность
- быстрое масштабирование
- автоматическое масштабирование по требованию
- масштабированиекаждый микро-сервис самостоятельно
- сервис обнаружения.нет необходимости жестко определять местоположение служб
- автоматический выключатель для предотвращения повторного запроса к отключенным службам и сокращения времени ожидания.
с микросервисами, вы можете выбирать междуобразцы хореографии и оркестровки.используйте хореографию.
- используйте шаблон CQRS (сегрегация ответственности за запросы команд), чтобы иметь разные БД для операций CRUD и создания отчетов
Для ответа на ваши вопросы :
- Микросервисная архитектура или монолитная?
- Должны ли мы создавать систему фоновых заданий в Rails, используя ....?
- ответ: вы можете использовать различные технологии и конструкции для каждой услуги
- Фоновые задания будут включать массовые вызовы API ...?
- ответ: вы можете масштабировать каждую микро-услугу по мере необходимости, даже динамически.
- Какой должна быть среда связи между микро-приложениями?
- ответ: оставшийся API, брокер сообщений или смешанный
- Совместно используемая БД в микро приложениях?
- ответ: каждому домену лучше иметь свою собственную БД.но это за домен, а не за работника.у вас может быть одна основная БД, совместно используемая соответствующими работниками.но для других доменов, таких как пользователи, лучше иметь разные базы данных.
- Всякий раз, когда нам нужно обработать операцию ....?
- ответ: некоторые службы могут быть запланированы так, чтобы работать как задания Cron.могут быть другие задания в потоке процесса, которые будут запускаться пользовательскими запросами асинхронно.