updated: '2020-09-07 01:23:20'
在最近的过去，我在各种软件开发环境中对“上游”和“下游”一词的定义有几次失误。每次，我都必须查找它的含义。有足够的理由对其进行撰写以使其坚持下去。
生产过程中的上游和下游
让我们从一个简单的生产过程开始，即使它与软件开发无关，因此我们可以在此基础上定义软件开发的上游和下游。
在上面的示例中，我们分三个步骤：
- 收集零件
- 组装零件
- 喷涂组件
生产过程与河流非常相似，因此很容易理解， 随着生产过程从一个步骤到另一个步骤，我们正在向下游移动。
我们可以推导出以下规则：
- 依赖规则：每个项目从其角度依赖上游的所有项目
- 价值准则：向下游移动，每一步都为产品增加价值
现在，让我们尝试将这些规则应用于不同的软件开发环境。
上游和下游软件依赖性
大多数软件组件都依赖于其他组件。那么什么是上游依赖性和下游依赖性？
考虑一下这个数字：
组件C取决于组件B，而组件B又取决于组件A。
应用依赖性规则，我们可以安全地说组件A在组件B的上游，而组件B在组件C的上游（即使箭头指向另一个方向）。
在这里应用“价值规则”稍微抽象一点，但是我们可以说组件C拥有最大的价值，因为它“导入”了组件B和A的所有功能并将其自身的价值添加到这些功能中，从而使其成为下游组件。
上游和下游开源项目
在开源开发中经常使用“上游”和“下游”一词的另一个上下文。实际上，它与上面讨论的组件依赖关系非常相似。
考虑项目A和B，其中A是原始项目，而B是A的分支：
在开源项目中，这是一种相当普遍的开发风格：我们创建项目的分支，修复错误或在该分支中添加功能，然后向原始项目提交补丁。
在这种情况下，依赖关系规则使项目A成为上游项目，因为如果没有项目B，它就可以很好地生存，但是如果没有项目A（原始项目），项目B（分支）甚至不存在。
价值规则同样适用：由于项目B添加了新功能或错误修正，因此为原始项目A增加了价值。
因此，每次我们向一个开源项目提供补丁时，我们都可以说已经向上游发送了补丁。
上游和下游（微）服务
在由微服务（或老式的普通分布式服务）组成的系统中，还讨论了上游和下游服务。
毫无疑问，依赖规则和价值规则也都适用于此上下文。
服务B是上游服务，因为服务A依赖于它。服务A是下游服务，因为它增加了服务B的价值。
注意，在这种情况下，定义上游和下游的“流”不是通过服务A 进入系统的数据流，而是从系统核心一直到面向用户的服务的数据流。
服务离用户（或任何其他最终用户）越近，它就越下游。
结论
在使用“上游”和“下游”概念的任何上下文中，我们都可以应用两个简单规则来找出哪个项目在另一个项目的上游或下游。
如果一个项目为另一个项目增加了价值或以任何其他方式依赖它，那么它肯定是下游的。