软件架构与思考

👉 所有文章
高性能 高性能设计模式
数据库 数据库分库分表指南 MySQL 建表参考 MySQL 初始化数据的一些方案 数据版本号
分布式 ID 分布式 ID 生成方案探讨 一个简单的分布式 ID 实现 一个随机的分布式 ID 实现
缓存 缓存 使用数据版本号保证缓存是最新数据 基于redis的二级缓存
微服务 如何实现远程调用 RPC 协议中的数据签名验签和加解密方案探讨 关于服务间调用循环依赖的一些思考 我所理解的负载均衡 一致性哈希 基于Redis的分布式会话管理系统 如何部署服务 灰度发布 如何区分上游和下游 日志级别
算法与协议 一个可扩展的 MQ 消息设计 Dynamo涉及的算法和协议 写时复制
任务分发 Gearman入门 如何使用redis构建异步任务处理程序
安全 关于对账的一些理解 一个简单可靠的 Dubbo 请求/响应数据签名方案
其他 使用卫语句减少 if else 嵌套

如何区分上游和下游


定义

根据河道流经区的自然环境和水文情况,黄河分为上、中、下游。 自河源至内蒙古托克托河口镇为 上游 ,托克托河口镇至河南桃花峪花园口附近为 中游 ,桃花峪至入海口为 下游 。 -- 摘自 https://zhuanlan.zhihu.com/p/447537667

根据黄河上下游的定义,可以看出上下游的特点:

  1. 下游依赖上游,如果没有上游,就没有下游。如果河源没有水,那么入海口也就没有水。
  2. 水是从河源流到入海口河源是上游,入海口 是下游。

在软件开发中区分上下游

我们尝试基于上下游的两个特点去推导一个基于微服务架构的应用的上下游关系:

假设某手机应用,用户操作时,调用的是 HTTP 服务 A , HTTP 服务 A 会调用 RPC 服务 B,RPC 服务 B 会调用 RPC 服务 C 。

按照服务间调用的依赖关系,我们可以得到:

RPC 服务 C <-依赖- RPC 服务 B <-依赖- HTTP 服务 A <-依赖- 手机应用

所以:

  • RPC 服务 CRPC 服务 B 的上游;
  • RPC 服务 BHTTP 服务 A 的上游;
  • HTTP 服务 A手机应用 的上游。

但是,按照用户操作产生的事件和数据的流向,我们可以得到:

手机应用 -事件和数据-> HTTP 服务 A -事件和数据-> RPC 服务 B -事件和数据-> RPC 服务 C

事件和数据手机应用 流向 HTTP 服务 A ,所以 手机应用HTTP 服务 A 的上游,依次可得到:

  • 手机应用HTTP 服务 A 的上游;
  • HTTP 服务 ARPC 服务 B 的上游;
  • RPC 服务 BRPC 服务 A 的上游;

可以看到我们从不同的角度分析,得到了相反的结论。

结论相反,我们该怎么办 ?

在上面的示例中,我们得到了相反的结论,该怎么办?

解决方法很简单: 团队内统一语言,统一用某一种方式来区分上下游即可。

目前看到的网上资料,多是使用服务调用的依赖关系来区分上下游。我个人更倾向使用事件和数据的流向来区分上下游。

相关资料


( 本文完 )

文章目录