我一直想到沿着实际流线的上游和下游，信息流就像水一样。因此，上游是水/数据来自的地方（例如HTTP请求），下游就是它所处的位置（例如，为请求提供服务的底层系统）。
我最近一直在关注API网关，并注意到其中一些使用了此定义的反转。当时我耸耸肩作为一个古怪的东西。然后我发现一些API网关所基于的nginx也使用了与我预期相反的术语。 nginx将它发送请求的服务器调用到＆＃34;上游服务器＆＃34;，因此传入的请求可能是＆＃34;下游客户端＆＃34;。
从概念上讲，似乎nginx会推动这些请求＆＃34; uphill＆＃34;如果进入一个＆＃34;上游服务器＆＃34;，这完全是反直觉的......显然，反向代理和API网关的重力是相反的！
我已经看到其他讨论谈论上游/下游代表系统之间的依赖关系，但是对于位于系统之间的中间件或基础架构组件，依赖关系的想法有点宽松，我发现在思考方面更有帮助信息流仍然存在 - 因为这通常是你的依赖的来源。
我是否从根本上错误地理解了流类比，或者这些软件组件是否会使这些概念倒退？
答案 0 :(得分：43)
在HTTP世界中，＆＃34;上游服务器＆＃34;术语是在HTTP / 1.0规范中引入的，RFC 1945：
502 Bad Gateway
服务器在充当网关或代理时收到无效 来自上游服务器的响应，它在尝试时访问 满足要求。
后来在RFC 2616中添加了正式定义：
上游/下游
上游和下游描述了消息的流程：全部 消息从上游流向下游。
根据这个定义：
同时，在HTTP中，大部分数据流不是针对请求，而是针对响应。因此，如果您考虑响应流，那么＆＃34;上游服务器＆＃34;这个词听起来很合理合理。该术语在502响应代码描述中再次使用（它与HTTP / 1.0相同），以及其他一些地方。
同样的逻辑也可以用术语＆＃34;下载＆＃34;和＆＃34;上传＆＃34;用自然语言。大多数数据流是从服务器到客户端，这就是为什么＆＃34;下载＆＃34;意味着从服务器向客户端加载某些东西，并且＆＃34;上传＆＃34; - 从客户端到服务器。