作业调度服务设计

Question

有一种想法是创建一个建立在多个域微服务和一些服务上的系统，这些服务可以做一些额外的事情，比如作业调度服务。这里的想法是能够安排来自任何微服务的任何作业，所以如果将新的微服务添加到系统中，那么从新的微服务中安排新的工作也不是什么大事。

首先，我担心的是创建这样的服务的能力，它似乎独立于域微服务，而另一件事是对服务进行足够的抽象，这样客户就不会知道服务是如何实现的，它使用的是哪个作业调度库等等。恐怕不可能实现我想要的东西。

例如，我有一个微服务，需要每周五发送一封带有特定内容的电子邮件，而另一个微服务想要安排另一份工作。因此，他们都将与我想要实现的作业调度服务进行通信。是否有任何架构解决方案来实现这一目标？

对不起，我太抽象了，我把问题描述得很清楚。我希望您的提示和想法将帮助我找到最好的方法，拥有这样的功能。也许有些库提供了现成的功能。

Answer 1

对于您所描述的内容，您应该使用事件和单个服务来封装域的该部分。例如，对于类似电子邮件的内容，您应该拥有一个电子邮件服务，该服务可以监听事件，然后为特定事件发送特定的电子邮件。

假设您正在进行用户注册，例如，当用户注册时，您可能拥有一个实际创建用户记录的用户服务。该服务完成后将发送"UserCreated“事件。然后，电子邮件服务将通过向用户发送一封受欢迎的电子邮件来响应"UserCreated“事件。您可能还有其他服务也响应相同的事件。此抽象允许您将创建新用户的逻辑与创建新用户后需要执行的任务分离开来，这不是用户服务的域。

Answer 2

我建议在您的微服务架构之上设置一个控制器。我将以Docker和Kubernetes为例。

这会是什么样子：

控制器(作业调度程序)-位于控制部署计划的拱顶上* Kubernetes / Docker群-容器的坐标比例尺*码头容器

控制器将允许您在整个网络中具有可见性。它将能够协调您的Kubernetes / Docker群部署策略。您还可以将代理放置在Docker容器中，可以根据您的需要使用首选配置进行缩放或向下扩展。

您可以查看下面的链接，以获得有关示例体系结构的快速视频。坦白说，我是Stonebranch的工程师

云业务

码头作业自动化