时间戳

首页 > 解决方案 > 让下游服务访问在上游服务中写入 API 是否被认为是糟糕的架构？

rest - 让下游服务访问在上游服务中写入 API 是否被认为是糟糕的架构？

问题描述

我有一个老板非常热衷于只让下游服务使用来自上游服务的数据。但是，在某些情况下，让下游服务向上游服务发送更新是有意义的，这自然是他完全反对的。

所以我的问题是让下游服务向上游服务发送更新数据是不是糟糕的架构？

似乎 RESTful api 在这种情况下将是可怕的架构，考虑到上游服务永远不需要 PUT，只有 GET。

他错了，还是我错过了什么？

标签： restservice

解决方案

这听起来像是一个消息传递的工作。我已经构建了一些这样的集成，其中系统将其环境中的更改广播到消息代理，并且任何对该更改感兴趣的东西都会使用该消息并相应地采取行动。但是需要共享消息格式。

如果上游服务是A，下游服务是B，那么

B 接受新用户摄取。B 处理请求并创建一个新用户。B 然后创建消息，例如：

<user mode="new">
  <name></name>
  <email></email>
</user>

或者

<users>
  <user mode="new">
    <name></name>
    <email></email>
  </user>
<users>

并将其发送到消息代理的主题，例如Apache ActiveMQ。主题可能是：

/user

A 可以是该user主题的持久订阅者，也可以使用Apache Camel将消息路由到 A 将订阅的另一个主题。理论上，持久消息和持久主题消费者可确保在代理出现故障时不会丢失消息。

A看到user消息，看到modeisnew并检查email它是否需要创建用户。然后 A 处理消息并执行它需要执行的操作。

此时，如果有其他系统需要了解新用户 A 可以将消息广播到他们收听的另一个主题。如果 A 需要先了解一个新用户，然后再决定还有谁需要知道，你会这样做。如果他们都需要知道，那么他们都可以订阅该user主题。

使用消息传递，没有系统需要知道任何其他系统。每个系统仅以已知格式广播事件（在这种情况下是特定于域的XML消息，但JSON很好）。

如果您有多个客户端，则每个客户端都可以进行自己的摄取，然后向主题广播一条或多条适当的消息，甚至每个用户可能一条消息，并且所有其他系统都可以对其采取行动。

如果您不想使用XML，或者JSON您可以将CSV所有新用户附加到消息中。关键是，所有其他系统都应该知道消息格式是什么。

推荐阅读