本文共 1073 字,大约阅读时间需要 3 分钟。
让我们以一个简单的生产流程开始,尽管它跟软件开发没有关系,这样我们能以此为基础定义软件开发中的上下游。
上面的例子有三个步骤:收集部件、组装部件、喷漆。
一个生产流程跟一条河流很相似,所以我们很容易理解:随着流程一步步往下进行,我们在往下游移动。我们可以推出以下原则:
依赖原则:从自身的角度看,每个环节都依赖其上游的环节 价值原则:往下游移动,每一环节都在产品上增加了价值 现在让我们将这些原则运用到不同的软件开发场景中。很多软件模块会依赖其他的模块。那么什么是上游依赖和下游依赖呢?
考虑下面关系: 模块 C 依赖模块 B,模块 B 依赖模块 A。 运用依赖原则,我们可以有把握地说模块 A 是模块 B 的上游,模块 B 和模块 C 的上游(尽管箭头是相反的方向)这里运用价值原则会有点抽象,但是我们可以认为模块 C 拥有最多的价值,因为它导入了模块 B 和 A 的所有功能,并且附加了自己独有的价值。所以模块 C 是下游模块。
另一个“上游”和“下游”被广泛使用的场景是开源软件开发。它跟上面讨论的模块依赖很像。
有两个项目 A 和 B,A 是原始项目,B 是从 A fork 出来的:这在开源项目中是很常见的开发模式:我们 fork 一个项目,在新项目中修复 bug 或者添加功能之后,提交一个 patch 到原来的项目。
在这个场景下,运用依赖原则:项目 A 是上游项目,因为没有项目 B 它也可以很好地存在,但是项目 B 无法存在如果没有项目 A。 运用价值原则同样可以运用:因为项目 B 增加了一些功能或者 bugfix,跟项目 A 比它增加了价值。所以每次我们往开源项目贡献一个 patch,我们可以说我们往上游发了一个 patch。
在由微服务(或者只是过时的分布式服务)构成的系统中,同样有上下游服务的讨论。意料之中,依赖原则和价值原则都可以运用到这个场景。服务 B 是上游服务因为服务 A 依赖它。服务 A 是下游服务因为它在服务 B 的基础上增加了价值。
请注意这里讨论的什么是上游什么是下游中的“游”不是通过服务 A 进入系统的数据流,而是从系统核心部分到面向用户服务的数据流。
离用户(或者其他终端客户)越近的服务,它就越下游。
我们可以在任何有“上游”和“下游”的场景中,运用这两条简单的原则来判断哪个是上游哪个是下游。
如果一个事物在另一个事物上增加了价值,或者以任何方式依赖另一个事物,那么它一定是下游。参考链接:
转载地址:http://yhfli.baihongyu.com/