我一直认为上游和下游是像实际的河流一样，信息的流动就像水流一样。所以上游是数据的来源（例如HTTP请求），而下游则是数据的流向（例如处理请求的底层系统）。
最近我在研究API网关时发现有些网关使用了这个定义的相反方式。当时我认为这只是一个奇怪的现象。后来我发现基于nginx的一些API网关也使用了我所期望的术语的相反方式。nginx称其发送请求的服务器为“上游服务器”，因此传入的请求可能就是“下游客户端”。
从概念上讲，如果流向“上游服务器”，nginx似乎会将请求“顶上坡”，这完全违反直觉...显然，在反向代理和API网关的领域，重力被反转了！
我看到其他讨论中提到上游/下游表示系统之间的依赖关系，但对于中间件或基础设施组件，它们位于系统之间，依赖关系的概念可能会更加松散，而我仍然发现按照信息流的方式思考更有帮助——因为通常情况下这才是您依赖项的来源。
我的河流类比理解是否根本错误，还是这些软件组件把概念搞反了？
2个回答
202
在HTTP世界中，“上游服务器”这个术语是在HTTP/1.0规范RFC 1945中引入的：
502 Bad Gateway 服务器扮演网关或代理角色，在尝试满足请求时，从其访问的“上游服务器”接收到无效响应。
后来在RFC 2616中添加了正式定义：
上游/下游 上游和下游描述了消息的流动方向：所有消息都从上游到下游流动。
根据这个定义：
如果您正在查看请求，则客户端是上游，服务器是下游； 相反，如果您正在查看响应，则客户端是下游，服务器是上游。
同时，在HTTP中，大部分数据流不是请求的数据，而是响应的数据。因此，如果考虑响应的流量，则“上游服务器”这个术语听起来相当合理和逻辑。该术语在502响应代码描述中再次使用（与HTTP/1.0相同），以及其他一些地方。
同样的逻辑也可以在自然语言中的“下载”和“上传”术语中看到。大多数数据流是从服务器到客户端，这就是为什么“下载”表示从服务器向客户端加载某些内容，“上传”则表示从客户端向服务器加载某些内容。
502 Bad Gateway 服务器扮演网关或代理角色，在尝试满足请求时，从其访问的“上游服务器”接收到无效响应。
后来在RFC 2616中添加了正式定义：
上游/下游 上游和下游描述了消息的流动方向：所有消息都从上游到下游流动。
根据这个定义：
如果您正在查看请求，则客户端是上游，服务器是下游； 相反，如果您正在查看响应，则客户端是下游，服务器是上游。
同时，在HTTP中，大部分数据流不是请求的数据，而是响应的数据。因此，如果考虑响应的流量，则“上游服务器”这个术语听起来相当合理和逻辑。该术语在502响应代码描述中再次使用（与HTTP/1.0相同），以及其他一些地方。
同样的逻辑也可以在自然语言中的“下载”和“上传”术语中看到。大多数数据流是从服务器到客户端，这就是为什么“下载”表示从服务器向客户端加载某些内容，“上传”则表示从客户端向服务器加载某些内容。
- Maxim Dounin
2
27谢谢，我理解了。作为一个有集成背景的人，我必须承认我倾向于把方向看作是谁发起通信而不是数据传输量的多少。现在我可以在HTTP定义的上下文中理解这一点了，但考虑到HTTP本质上是请求/响应（即双向）的，我希望他们完全避免使用术语，因为它实际上并不能帮助我们理解方向！ :) - ChrisC
如果“上游和下游描述消息的流动：所有消息都从上游流向下游。”，那么这意味着不能谈论“上游/下游API”——总会有请求和响应。最好的情况是（比如说），下游始终是服务器，上游始终是客户端（即重点在于请求而不是响应）。 - stemadsen
2
nginx做得很好。传统上，“上游/下游”比喻用于表示依赖的方向，而不是消息的方向。因此，尽管序列图将请求描述为不可否认的“下游”遍历，但实际上，它所到达的服务是被依赖的服务（而不是依赖于其他服务）。
当你在水里撒尿时，影响是下游的。同样，如果一个服务决定更改其API，则调用它的服务会受到影响。
当你在水里撒尿时，影响是下游的。同样，如果一个服务决定更改其API，则调用它的服务会受到影响。
- cmarenbach
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接