Api REST基础设施设计所需的建议

这不是一个技术问题，而是关于如何设计多个API之间的通信。假设从基础架构的角度来看，只有这4个组件（微服务体系结构）

• 收集器->从外部源1获取数据，进行一些小的重新映射，就这样
• 收集器->从外部源2获取数据，进行一些小的重新映射，就这样
• 聚合器->存储收集器API中的数据，对数据进行适度的重新映射，使其按我所希望的方式结构化
• 调度器->负责定期触发从外部源获取数据

我的想法是：

方法1

• 调度程序调用Aggreagators端点。然后，聚合器生成一个 对收集器的HTTP调用，接收响应并存储在 数据库

方法2

• 调度器调用收集器，获取数据，然后进行另一个 调用聚合器组件来存储数据

方法3

• 调度器调用收集器并发送该收集器的回调url 聚合器（或收集器已知的聚合器URL） 组件），收集器从外部源获取数据并 然后调用聚合器组件

到目前为止，我的认识是：

方法1:

聚合器上的终结点不是RESTful的。想象一下，你想在2020年获得某个特定国家的所有足球比赛数据。您可以将国家和年份作为查询参数传递给聚合器组件上的POST端点，但这并不是您将在数据库中得到的实际数据。这是一种简单的方法，但我不喜欢聚合器组件上的端点对它们所做的事情不透明

方法2:

这种方法允许适当的RESTful API设计，但它确实需要调度器也充当代理。调度程序不会序列化然后反序列化数据。它只是从收集器的get端点获取数据，并将其转发到聚合器的POST端点，但这增加了该组件的复杂性

方法3:

允许适当的RESTful API设计，但我不喜欢数据如何实际进入聚合器（以及数据库）的逻辑隐藏在收集器组件中。此外，对于每个新收集器，相同的“逻辑”将被复制

到目前为止，方法2对我来说似乎是最有意义的，尽管它将组件变成了半调度器半代理。此外，我还可以引入一个新的代理组件。也许“代理”不是最好的措辞，但你明白了

它会被调度器调用，然后从收集器获取数据并转发到聚合器，但添加此组件似乎会给整个系统带来更大的复杂性，我不确定它是否会带来任何实际价值

---

我对其他方法、建议等持开放态度：）

我更喜欢你的方法2，但总的来说，我的观点是：

所有的操作看起来都非常异步，因为收集器可能需要很多时间 聚合器在很大程度上依赖于时间

聚合器应该了解收集器，因为在系统之间（比如说聚合器和收集器），应该有一个合同，可以由CDC（消费者驱动的合同测试）支持，这样消费者就知道生产者在生产什么以及如何生产

方法1 调度器可以直接调用为收集器提供URL的聚合器（可以存储在调度器中，或者让聚合器知道它，最好是后者，因为调度器只调度内容）。但在这里，聚合器也需要等待收集器响应，因此可以避免等待部分（这是调度器最擅长的部分）。此外，链接HTTP调用可能不是一个好主意。糟糕的设计。对于内部的多个API调用，我们使用类似于事件驱动体系结构的异步设计

方法2 调度程序调用收集器开始收集。完成后，通知调度程序。然后，调度程序要求聚合器开始操作。 A.调度程序不应将信息从收集器定向到聚合器，但聚合器可以直接执行API调用以直接从收集器获取数据

a。此外，还可以让收集器API在消息总线中将数据发送到aggregator async，并让aggregator处理传入数据（或存储本地副本，稍后再处理）。这使得系统更加解耦。所以调度器只调用收集器启动

c。如果收集器关闭，聚合器仍然可以使用过时的数据进行响应

方法3

---

听起来消费者（收集器）知道如何调用生产者（聚合器），我认为这不是生产者的责任，生产者不应该知道消费者的情况，而且它正在向生产者泄漏资源信息。

我喜欢使用消息总线的想法，但在项目的当前阶段，此实现不是一个选项。在方法2中，我需要创建某种缓存/缓冲区，收集器在其中存储已处理的数据，然后在聚合器提取数据时将其清除。我仍然需要向调度器发送某种响应，让它知道任务已经完成，聚合器现在可以获取数据。因为我不处理实时数据，端点也不相互依赖，所以我认为异步不会带来任何价值。还是我错了？你是对的，消息总线是过分的，因为它不是实时的。收集器可以只回复200 OK，执行进程，或者对于调度器来说只需ping就足够了。稍后，当调度器清除数据时，聚合器可以进行数据提取（即检查收集器作业是否完成）。因为它不是实时的，所以您