DB是服务的下游还是上游，你平时用对了吗？

我们都知道沟通的基础是大家得建立一致的通用语言，说人话就是，得口径一致才能沟通明白。现在我们不管在公司内部讨论，还是在群里吹水，说到架构、服务治理的时候，肯定会提到上游服务、下游服务之类的名词。但你有没有想过你说对上下游的理解可能是错误的。

就跟有人一开始不理解反向代理为什么不是反着的一样，那上游服务为什么不在上边？😁

我相信大家一开始，都会认为网关算是应用服务的上游，服务是DB的上游，原因也好理解，平时的架构图网关都是画在服务的上面的，服务在DB上面，这么一看就是网关算是上游呀。

不过今天给大家普及下这个小知识，网关真的是最下游，咱们平时把上下游给理解反了，我第一次怀疑自己理解反的时候是在看技术书，书里把业务服务叫做身份和权限认证服务的上游，我当时心想用户来了不是先访问身份认证服务吗？怎么能叫下游呢？后来查了查还真是自己理解错了。

关于上游、下游这两个名词来源和它们在技术架构领域的正确解释，最近看桃花源写的短文非常好，感觉特别有共鸣，在这里转给大家一起看看，能纠正一个算一个。以下内容转自码农桃花源。

---

工作中，有一些术语比较容易混淆，聊半天，最后发现双方对术语的理解不一致。这个时候用英文原本的表达或者换一种方式来表述能让沟通更顺畅。

像我们经常说的『上下游』便是经常发生混淆的一对名词。

以前，我经常说『梳理一下我们依赖的下游』，后来发现这种说法是错误的。正确的是：梳理一下我们依赖的上游。

是不是听着很奇怪？

可以这样理解，越是上游的地方，越是离源头更近的地方，源头就是指数据源。

对于互联网服务用户而言，数据沿着源头、上游、下游，一直流到用户的设备上。源头可能是数据库，上游可能是后端服务、下游可能是 gateway。对于某个微服务的 owner 也一样：你的服务做的事就是从上游获取某项数据，然后经过一些加工处理，吐出加工后的数据，数据会流向下游。

有人可能会反问：服务之间的交互，一问一答，请求和响应都有数据，那流向该怎么算？其实这里的数据是指响应数据，是终端用户最终需要的数据：可能是短视频，可能是公众号文章。

我们记住这张图就可以了：

上面这张图来自这篇文章^[1]，文中介绍了好几种 downstream/upstream，但对于后端研发来说，弄清服务调用间的上下游就足够了。

实在不好区分的，想想 nginx 中的 upstream 配的是什么地址就能回忆起来。

最后，在有可能要频繁说起上下游的场合，一定要先和大家约定好名词的定义。这时用 upstream、downstream 可能会更好一些；或者改叫调用方、被调用方也很清晰。

参考资料

[1]

文章: https://reflectoring.io/upstream-downstream

- END -

扫码关注公众号「网管叨bi叨」

给网管个星标，第一时间吸我的知识 👆

网管整理了一本《Go 开发参考书》收集了70多条开发实践。去公众号回复【gocookbook】领取！还有一本《k8s 入门实践》讲解了常用软件在K8s上的部署过程，公众号回复【k8s】即可领取！

觉得有用就点个在看  👇👇👇