上游和下游服务采用哪种方式？

对于由多个相互调用的服务组成的系统（例如，前端->后端->存储），我经常听到人们使用诸如“下游”或“上游”服务之类的术语。我不清楚这些是指哪个方向。数据双向流动。请求从更多的面向用户的流向更多的后端服务，但是响应却朝相反的方向流动，因此在我看来，可以说是任一种

下游服务是消耗上游服务的服务。特别是，它们取决于上游服务。因此，前端在后端的下游，因为它取决于后端。没有前端，后端可以有意义地存在，但是没有后端，前端就没有意义。

依赖关系不必像我在上一段中所说的那样强大。更一般地，上游服务不需要知道或关心下游服务的存在。下游服务关心上游服务的存在，即使它们只是可选地使用它们。

不幸的是，关于上游/下游的含义存在意见分歧。在讨论系统架构时，我将其定义如下：

给定关注的系统，启动与关注的系统的消息/数据交换的系统是上游系统，关注的系统所依赖的系统（即我的系统向其发起数据交换的系统）是下游系统。

ibm的此链接描述了与其产品之一的交互，从而证实了这一观点： 与上游和下游系统集成https://www.ibm.com/support/knowledgecenter/zh/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

上游系统是将数据发送到Collaboration Server系统的任何系统。下游系统是从Collaboration Server系统接收数据的系统。

给定术语“上游”和“下游”，可能有助于对河流进行类比。如果将一条消息（数据）放在河流中，它会从上游（发起者）流向下游（接收者）。

有趣的是，我发现架构师和中间件开发人员使用此定义，而Web开发人员则使用相反的定义（可能是由于“上传”）。

使用事件时间轴，事件在时间轴上的某个点之前发生（即触发另一个事件）时在上游发生，而在事件发生后（即接收到事件）发生在事件下游。因此，一系列事件中的上游和下游是什么，取决于您在时间轴上的位置。一个事件可以在下游，也可以在上游，这取决于起点是在事件之前还是之后。

正如@Jack所说，RFC7230 tools.ietf.org/html/rfc7230#section-2.3具有以下功能：

术语“上游”和“下游”用于描述
与消息流有关的方向性要求：所有
消息从上游流向下游

我很想看看投票，最常见的用法是！

考虑这一点的最佳方法是想到一条河。

河流的下游部分无法获得任何水，除非它来自上游，也就是说，下游的上游水源取决于上游。

如果有人破坏了河的下游部分，那将对上游没有影响。如果有人破坏了河的上游，这将影响下游，即不会得到任何水。

因此，下游服务取决于上游服务。如果上游服务被删除，则下游服务将无法正常工作。

这可能是语言和地理问题，而不是技术问题。

• 信息请求向上游发送。它来自下游系统。

• 对信息请求（请求的信息）的响应向下游发送，并由上游系统发送。

经典的IBM视图与当今的Web社区对这些术语的使用没有区别。

• 与服务使用者相比，服务提供商（服务器）将位于上游，并将信息下游发送给使用者。

• 与服务提供者相比，服务使用者（客户端）将位于下游，并将请求发送到上游。

理论上，物理系统的角色可能会立即发生变化，这些系统之间的流向也会发生变化。在对等网络中可能就是这种情况。

术语上载和下载是以客户为中心的术语。从客户端的角度来看，上载请求并下载响应，这与流的隐喻是一致的。