为什么这么多后端开发上下游不分?

2023-09-19 16:29:52 +08:00
 v2nika

面试了不少于 100 个后端工程师, 初级到高级都有. 有相当一部分 (>70%) 的人, 都会说我做的服务调用下游服务如何如何.

为什么会这样? 只要认真思考一下, downstream 和 upstream 的概念不至于记不住吧?

11336 次点击
所在节点    程序员
109 条回复
ryan4yin
2023-09-20 10:39:16 +08:00
这不能证明面试者有问题,只能证明这套术语本身有毛病。
就如同什么南向北向,鲁棒性之类的傻逼玩意儿。
coyove
2023-09-20 10:40:03 +08:00
不好意思,在我司依赖的 3 方服务叫上游,依赖的内部服务叫下游。
定义每家都不一样,为什么要来 yygq ?
22F41628gA98q4Lx
2023-09-20 10:45:14 +08:00
维基百科
upstream 在 计算机网络中的解释
In computer networking, upstream refers to the direction in which data can be transferred from the client to the server (uploading).
upstream 在软件开发中的解释
In software development, when software has been forked or uses a chain of libraries/dependencies, upstream refers to an issue that occurs in software related to the chain. It is the direction that is toward the original authors or maintainers of software. It is usually used in the context of a version, a bug, or a patch.
upstream 在水文学中的解释
The term upstream (or upriver) refers to the direction towards the source of the stream (or river), i.e. against the direction of flow. Likewise, the term downstream or downriver describes the direction towards the mouth of the stream or river, in which the current flows. The term "left bank" and "right bank" refers to banks as seen from the direction of flow.
看起来和调用没太多关系
leeg810312
2023-09-20 10:47:06 +08:00
了解或做过供应链或者物流系统的可能比较容易理解,永远是下游获取上游的数据,哪有反过来的说法,获取方式可以是推或者拉,是否上下游取决于业务流程,而不是获取方式,无论是业务处理系统还是数据类系统应该都是这样,楼上好些人这都搞不懂吗?
RedisMasterNode
2023-09-20 10:47:30 +08:00
@v2nika 听起来没什么问题?一直都是这么用的。不需要强加自己的理解于别人之上,面试只需要表达清楚意思就可以了。

上下游的定义一直都有(至少)两类,

第一类: 按 action 的方向定义
上游: 指收到了哪里的请求 / 要响应给谁。
- 上游服务调用了我,我要响应给上游服务。
下游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用我的下游。

第二类:依赖关系
上游: 发请求给谁 / 从谁那接收它的响应。
- 我正在调用服务的上游
下游: 指收到了哪里的请求 / 要响应给谁。
- 下游服务调用了我。

面试里面结合语义这些东西并不值得纠结,而且既然不是个所有人都同意的东西,hh ,我也觉得会有人发帖:

```
为什么这么多后端开发上下游不分?
面试了不少于 100 个后端工程师, 初级到高级都有. 有相当一部分 (>70%) 的人, 都会说我做的服务调用上游服务如何如何.
为什么会这样? 只要认真思考一下, downstream 和 upstream 的概念不至于记不住吧?
```
zp324511
2023-09-20 10:49:28 +08:00
@darksword21 我猜因为你是老板
wr516516
2023-09-20 10:58:20 +08:00
我建议你要是想 pass 人家就直说.
这种东西不管怎么说怎么理解,进公司了统一口径就行了呗.

面试在这种问题上挑刺得话,招聘到的就只能是符合个人审美和面试者习惯性格的人而已,这种点也考察不了啥啊.
你还不如跟东堂葵似的直接问他喜欢什么什么样的女人
IvanLi127
2023-09-20 10:58:36 +08:00
我感觉问题是在这个语境下,用上下游不是个明确的说法。如果一定要用,那 OP 的说法基本上是正确的。
上下游能互换的话那能叫上下游吗?只有层层递进的用法,不可能 A 和 B 互为下游,更不可能反过来。狭义上不是说这个服务收到别的服务的数据就被称做下游,只能说这个接口是这个数据的下游。大概这样,所以我觉得 OP 思路没毛病。
xiaooloong
2023-09-20 11:01:05 +08:00
引用「在微服务或者服务链路中,"上游"和"下游"的概念确实和 Nginx 的 "upstream" 方向相反。

在微服务架构中,如果服务 A 调用了服务 B ,那么我们通常认为服务 A 是"上游"服务,服务 B 是"下游"服务。而在 Nginx 中的"upstream"则定义了后端服务器群组,这些服务器是被 Nginx (作为代理服务器)调用的,所以从这个角度看,它们应当被看作是"下游"。

这样的混淆源于不同领域对"上游"和"下游"概念的使用有所不同。在 Nginx 配置中,"upstream"是指代理服务器发送请求的目标服务器列表,这是从流量的流动方向来定义的。而在许多其他上下文中,"上游"和"下游"通常是从数据处理或依赖关系的角度来定义的。」
coolmenu
2023-09-20 11:20:50 +08:00
孔乙己文字游戏吗?问点技术问题,这种上游下游本身就有分歧的含义,有什么可抱怨的?
runzekk
2023-09-20 11:31:26 +08:00
不用杠,一般以用户的视角来看,用户首先访问的就是上游服务,然后上游服务一层层往下调用。
Desiree
2023-09-20 11:33:29 +08:00
懂了你也不会招的
liuzhedash
2023-09-20 11:35:47 +08:00
你要是在华为,面试 100 个人能有 70 个知道啥是 [胶片] 么
yongzhenchen682
2023-09-20 11:38:25 +08:00
数据流向 a->b
a 是上游,个人理解
RedisMasterNode
2023-09-20 11:56:43 +08:00
@yongzhenchen682 数据可以是提交数据,也可以是查询数据,你怎么去定义呢?

服务 A 向服务 B 查询了一堆数据,数据是从 B 流向 A ,所以你觉得 B 是上游,A 是下游;

服务 A 向服务 B 写入了一堆数据,数据从 A 流向 B ,所以说 A 是上游,B 是下游。

根本就没办法解释和通用地定义“流向”和“依赖”,文字游戏是没啥意思的
hackersee
2023-09-20 11:59:33 +08:00
沟通的目的就是意会,你知道他要表述的是内容就行了。
概念比较适合团队,可以让团队内的沟通效率更快,而团队之外则普通意会即可。
就好比 UGC ,PGC ,PUGC 这些概念,视频/自媒体行业的人一般都知道,其他的不一定。
kanepan19
2023-09-20 12:11:43 +08:00
看到楼主被骂惨了我就放心了
collen
2023-09-20 12:14:07 +08:00
是阿里吗
brader
2023-09-20 12:19:04 +08:00
比如我是做 A 系统,有另外一个 B 系统,我经常需要向 B 系统的一些 API 接口查询数据。
但同时我也会收集一些用户、后台提交的纠错数据,通过 B 系统的 API 提交给他们。

那这种两个系统之间有来有回的,你怎么去精确的抠字眼区分呢?
按我意思就是往大了看,从整个系统架构去看,我的 A 系统大部分是依赖于 B 系统提供一些基础数据服务,那我就认为 B 是我的上游,这有啥问题。
fan88
2023-09-20 12:23:19 +08:00
OP 想表达的意思:我很牛 B ,他们都是菜狗。

有啥的,什么上下游,什么微服务,老子一点都不懂,PHP 一把梭一年五六十万拿

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/975243

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX