看到讨论微服务优劣的帖子，我有个疑问，如果微服务中的某个基础服务对外接口发生变化，假设有 10 个服务调用了此接口，那么所有接口都需要重新改动？甚至于有时不知道哪些服务会调用到这个变动的接口，这是个大问题，请问大家都用什么方案来解决以上问题？
 |
1
littlewing 3 天前
变化当然是要考虑兼容性啊
|
 |
2
ipwx 3 天前  1
把旧的接口留着，调一下新的接口相关代码呗。微软 20 年老 API 都留着呢
|
 |
3
cvbnt 3 天前 via Android
那要看什么级别的改动，如果是接口名称，参数修改那没辙，但是可以单独将请求对外接口封装到单独的一个服务里供其他服务使用，这样外部接口发生变化，仅需要改动这一个服务就行了
|
 |
4
quan7u 3 天前
1 、版本号 or 参数控制接口版本，比如保留 v1 、新开 v2 ，通知上游接口切换
2 、完善监控，统计接口流量、分渠道的调用量 |
 |
5
lnbiuc 3 天前
旧的接口不变，新的改成 v2 版本，其他的服务如果有需要就改，没需要就维持现状
|
 |
6
xuanbg 3 天前
首先，出现 10 个服务调用情况基本就是设计的问题。代码写错地方真的比写错了代码还糟糕。
然后，问题已经出现了，那该怎么办呢？简单，给一个 V2 版本就行了。需要新的改用 V2 版本，不需要的继续用 V1 ，就不需要动他了。 |
 |
7
conn4575 3 天前 via Android
如果你有更上层的 api 网关的话，可以在上面做参数重写，这就是 api 网关的意义。否则就只能用 v1 v2 做好兼容了
|
 |
8
wogogoing 3 天前 via iPhone
/api/v1
/api/v2 让需要的服务显式变更。 |
 |
9
lasuar 3 天前
1. 内部逻辑变化不影响其他服务，仅接口出入参变化需要关联更新
2. 接口出入参变化属于较大结构调整，可能是因为之前设计不完善或业务/功能原因需要调整，频率较低 3. 微服务中的服务调用一般是基于生成式代码的 RPC 调用，不存在说 [不知道影响了哪些服务] 4. 楼主的问题在微服务中属于基础，最好是先尝试本地使用熟悉语言实践一下微服务架构，这样方能避免一知半解的状态。 |
 |
11
cyrivlclth 2 天前
这个场景和微服务没强关联，你就做下提供给移动端的 api 就知道了，有些接口你要是变更了，那没升级的那些移动端的用户是不是直接不给用了？那可不是十多个，那是成千上万个用户。
这种涉及到对外接口的，都要做版本控制的。 |
 |
12
pxxu 2 天前
如果微服务提供的接口是为了保障和其他微服务之间的接口变化感知的话，pact 之类做服务之间的契约测试，CI 定期监控应该满足你的需求
|
 |
14
johnhuangemc2 2 天前
都微服务了, 得考虑接口变更治理
变更巨大就把接口版本化 小变更就尽量保证兼容性 新旧接口并行一段时间就找机会把老接口绞杀掉 |
 |
15
CodeCaster 1 天前
微服务接口变化，而造成的调用方也要发生改变，最常规的解决方案，就是老的接口先不变，新增一个全新的接口，所有调用方根据自己的升级节奏逐步升级到新接口，待全部调用方都升级完毕之后，再将老接口下线。
其实，上述问题在微服务体系中非常常见，我觉得这个问题就是微服务架构这种模式造成的，因为不同的微服务本质上是离散的不同个体，他们之间的调用就是他们之间的强依赖关系，既然是强依赖，那么被依赖方发生改变，必然会造成依赖方要随之改变，这种变化是会传播的。 看到了微服务具有这样的问题，其实再看看过去的传统单体应用，调用方和被调用方都在一个进程中，这个时候，服务提供方发生改变，我们随手把调用方代码一起改了就完事了，根本不会有这样的问题，因为其实调用方和被调用是一个整体。 所以，这个问题，我觉得，没有什么更好的方案了，既然选择了微服务，就需要正视这样的问题存在，选择最常规最稳妥的解决方案吧。 |
Select Language