微服务之间是怎么“串门”的
在开发一个电商平台时，订单服务要扣减库存，就得调用库存服务。用户下单那一刻，订单服务就像去邻居家敲门：“兄弟，我这儿有个单，你那边还有货吗？”——这就是典型的微服务依赖关系。
这种“串门”不是随便走动，得提前说好谁依赖谁，怎么找得到对方。一旦库存服务宕机或者响应变慢，订单服务也会被拖住，甚至整个下单流程卡死。所以，搞清楚这些服务之间的依赖路径，比写代码本身还关键。
常见的依赖形式
微服务之间最常见的依赖是通过 HTTP 或 RPC 调用完成的。比如用户服务需要获取权限信息，就会调用认证服务的接口：
GET /api/v1/auth/user-permissions?uid=10086这种调用关系一旦多起来，就像小区里的小路越踩越多，最后变成一张网。如果没人画地图，出问题了都不知道该修哪条路。
用配置文件明确依赖
在 Spring Cloud 这类框架里，通常用 application.yml 来声明依赖的服务地址：
rest:
service:
inventory:
url: http://inventory-service:8080
user:
url: http://user-service:8081这样订单服务启动时就知道去哪儿找库存服务。但如果 inventory-service 的地址变了，而配置没更新，那就相当于按旧地址寄快递——永远送不到。
服务发现让依赖更灵活
与其硬编码地址，不如让服务自己报到。用 Eureka 或 Nacos 做服务注册中心，每个服务启动后主动登记：
eureka:
client:
service-url:
defaultZone: http://nacos-server:8848订单服务要调库存，先问一声注册中心：“现在 inventory-service 在哪儿？”拿到最新地址再发起请求。就像打网约车，系统自动分配最近的司机，不用你自己记电话。
别忘了设置超时和降级
依赖多了，风险就高。库存服务要是半天不回话，订单服务也不能一直干等。得设个 timeout，比如两秒没回应就放弃：
feign:
client:
config:
default:
connectTimeout: 2000
readTimeout: 2000同时准备个降级方案：查不到库存？先记下来，走异步补单流程。就像餐厅没菜了，先给顾客上壶茶，后台赶紧联系供应商。
可视化你的依赖图谱
大项目里几十个服务互相调用，光靠人脑记不住。可以用 SkyWalking 或 Zipkin 把调用链画出来，一眼看出哪个服务被多少人依赖，哪里是瓶颈节点。
比如发现支付服务居然被报表服务同步调用，那报表一卡，支付也跟着卡——这明显不合理，应该改成异步推数据。
配置管理要跟上迭代节奏
每次上线新功能，可能都会新增或调整依赖关系。把这些变化写进配置中心，比如 Apollo 或 Consul，做到动态生效，不用每次改个地址都重启服务。
团队协作时尤其要注意：前端改了个接口路径，没通知后端，结果调用全失败。这类问题八成出在依赖关系没对齐。定期核对服务契约（Contract），比事后排查快得多。