我们经常谈到上游和下游，但有时会比较困惑怎么界定两者的关系。例如，在电商系统中，由于订单需要依赖商品，我们通常认为订单是下游，商品是上游；由于下单后才能支付，我们认为订单系统是上游，支付系统是下游。如果从系统的依赖关系看，订单服务会调用商品服务的接口，订单是发起端，商品是接收端，而订单系统会发消息给支付系统，订单是发起端，支付系统是接收端。那么问题来了，为什么调用的发起方有时是上游，有时又是下游呢？
先不谈这个问题，还是先来看上游和下游概念的含义。上游和下游的概念，是从现实中江河的水流而来的。水流有个显著特点，水是从上游流到下游的，而不会倒过来。这有两层含义：首先，从行为的时间顺序看，上游先发生，下游后发生；其次从依赖关系看，下游是依赖于上游的。同理，在软件系统中，数据流是从上游到下游的，下游的能力依赖上游。
按照上述定义，如果你认为下游就是数据的接收方，上游是数据的发起方，那就会出现自相矛盾的逻辑。例如，业务系统中往往有些基础服务负责基础数据存储，这些基础数据是通过业务系统调用基础服务触发写入，当业务系统使用数据时，再调用基础服务获取数据，那么从数据写入视角，基础服务是数据接收方，处于下游，但从数据读取视角，业务系统又变成了上游！抛开上述定义，从业务视角看，由于业务系统最终要使用基础服务的数据，很显然业务系统才是下游，基础服务是上游。那为什么会出现这个矛盾的现象呢？注意，这里有个巨大的误区，在写入场景下，业务系统虽然调用基础服务接口写数据，但这个数据来自前端或其他系统，并不归属业务系统，业务系统本身也未存储这部分数据，因此你不能认为数据是从业务系统流向了基础服务。但在读场景下，业务系统需要查询基础服务的数据，并拿过来在自身系统内使用，这才意味数据从基础服务流向了业务系统，逻辑才是自洽的。
因此，我认为上下游本质上代表的是系统间使用数据的依赖方向，这和系统间的接口调用方向无直接关系。系统间使用数据无非两种方式：下游使用方主动拉取上游数据，或数据生产方作为上游主动推送数据到下游。
- 下游主动拉取方式：A服务调用B服务服务的读接口，拉取B的数据，并用于A自身计算或存储，A是下游，这里体现了下游对上游的依赖，典型的例子是下单场景查询商品信息；
- 上游主动推送方式：A服务调用B服务写接口或A服务发消息给B服务写数据，那么A是上游，典型的例子是订单发消息给物流、支付系统创建物流单和支付单。不过这里要排除一种上面提到的例外场景：B服务写入的是后续被A依赖使用的数据，该场景下B作为基础服务存在，B是上游。
