要思考的问题。
假设我有一个微服务，它可以同时解析 1 到 N 个文档/站点（以下简称为对象）。解析一个需要一分钟到 M 分钟。
假设任务是分配负载，让微服务的工作更有效率。我们不会详细介绍 - 里面是什么，它是如何工作的，什么工具用于解析，在什么基础上 - 这个任务是抽象的。
由于我们使用的是微服务架构，因此拥有多个实例而不是 1 个实例是合乎逻辑的。假设我们有 1 到 K 个微服务实例。
但是如何并行化？理论上，你可以编写另一个微服务——微服务提供者。它将从我们的解析器的当前实例中获取信息，找出当前有多少正在工作，它正在做什么，并选择有空闲槽的实例。
这里所说的槽，是指一个实例可以同时解析多少个对象，也就是同一个N。
反过来，微服务提供者将有一个对象队列用于解析，并在一定的超时时间内轮询实例以获取空闲槽，并在槽空闲时提供对象。
问题是所提出的解决方案在微服务架构上的正确性如何，即使在这个抽象的例子中，也会有滑点吗？
我会预约——然后让解析后的数据放入数据库，它们不会去另一个微服务，它们之间不会以任何方式相互同步，也许只有在提供者微服务中才有验证（检查唯一性对象）。
您和处理者可以向供应商请求工作，而供应商 - 将工作“推”给处理者。这样的方案不是多余的吗？
鉴于提供者没有被正式通知处理者的意图（也许他想完成他已经分配并完成的事情），我认为应该只留下来自处理者的主动请求。同时，供应商有权向处理者发送“我有工作要给你”的信号——这将允许处理者在完成当前工作但没有收到新的工作之前“睡觉”。来自供应商的信号，而不是拉它。
此外，处理程序必须在处理完成时告诉提供者作业已完成。而那个 - 在收到此信号之前不要删除任务（或直到超时到期，之后认为处理“失败”，并且该任务必须转移到另一个执行程序）。当然，同时出现了“退出当前任务，这个刹车还是完成了”的信号……
提供者应该有办法获取可用处理程序的当前列表。还假设提供者可以调用处理程序并请求其状态（并获得诸如“工作”、“装傻”、“休息，请勿打扰”之类的东西）作为响应。即使有必要，尝试在允许的范围内启动另一个处理程序进程，或者相反，如果没有任务，则卸载冗余处理程序，留下几个“职责”。