Дизайн сервиса «Планирование работы» - PullRequest
0 голосов
/ 09 октября 2019

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

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

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

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

Ответы [ 2 ]

1 голос
/ 09 октября 2019

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

Допустим, вы делаете регистрацию пользователя, например, когда пользователь регистрируется, у вас может быть пользовательский сервис, который фактически создает запись пользователя. Эта служба отправит событие «UserCreated», когда это будет сделано. Тогда служба электронной почты будет отвечать на события «UserCreated», отправляя пользователю приветственное письмо. У вас могут быть и другие службы, которые также отвечают на те же события. Эта абстракция позволяет вам отделить логику создания нового пользователя от задач, которые должны выполняться после создания нового пользователя, который не является доменом пользовательского сервиса.

0 голосов
/ 18 октября 2019

Я бы порекомендовал установить контроллер поверх вашей архитектуры микросервисов. В качестве примера я буду использовать Docker и Kubernetes.

Как это будет выглядеть:

Контроллер (планировщик заданий) - располагается над аркой, контролирующей расписание развертывания * Kubernetes / Docker Swarm- шкала координат контейнеров * Docker контейнеры

Контроллер позволит вам иметь видимость всей вашей сети. Он сможет координировать вашу стратегию развертывания Kubernetes / Docker Swarm. И вы можете размещать агентов внутри контейнеров Docker с возможностью масштабирования в зависимости от ваших потребностей с предпочтительными конфигурациями.

Вы можете посмотреть ссылки ниже для быстрого видео на примере архитектуры. Полное раскрытие, я инженер в Stonebranch

Cloud Orchestration

Docker Automation Workload Automation

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...