软件开发中的上游和下游
What is Upstream and Downstream in Software Development的中文翻译版本。
在最近一段时间，我开始在软件开发环境中接触到 “上游” 和 “下游” 这两个词，常常迷惑不解。每次我都必须查一下它的含义，因此决定将它们写成blog来帮助理解。
生产过程中的上游和下游
让我们从一个简单的生产过程开始，尽管它与软件开发无关，但是我们可以在此基础上定义软件开发的上游和下游。
在上面的例子中，我们有三个步骤:
- 收集零件
- 组装零件
- 绘制装配体
上面的生产过程与河流非常相似，因此很容易理解 随着流程从一步到下一步，逐步向"下游"移动
我们可以推断以下规则:
- 依赖规则: 每个当前的项目都依赖于上游的所有项目
- 增值规则: 在向下游移动的过程中，每一步都为产品增加更多价值
现在，让我们尝试将这些规则应用于不同的软件开发环境。
软件依赖中的上游和下游
大多数软件组件都依赖于其他组件。那么什么是上游依赖和下游依赖呢？
如图所示:
组件 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 进入系统的数据流，而是数据流系统一直到面向用户的服务。
服务离用户（或任何其他最终消费者）越近，它离下游越远。
结论
在使用“上游”和“下游”概念的任何上下文中，我们可以应用两个简单的规则来找出哪个项目是另一个项目的上游或下游。
如果一个项目为另一个项目增加价值或以任何其他方式依赖它，它肯定是下游。