服务接口不知道被谁用到，找不到调用方 怎么处理？

[WillingXyz]

问题：

当前分为两种类型的接口，一种是给客户端使用的，一种是给其他服务使用的。 一个接口提供给外部使用之后，当要修改时，需要找到所有调用方。 问题是 不知道调用方是谁。

方案：

一个方案是 要求调用方传递一个标识，标识调用方是谁，如 appId/appName 。 该方案的缺点：

1. 如果不强制传，调用方可能会不传
2. 缺乏统一管理，只能通过日志筛选

另一个方案是 创建一个服务管理平台，当调用方需要用这个服务时，需要先在平台上创建，创建后生成 appId 或 appName ，然后调用方每次调用时传递该标识。 该方案的缺点：

1. 有点麻烦，是否有必要

各位大佬们 当前都是怎么管理的

[Inn0Vat10n]

发邮件周知，然后一段时间后静默，等调用方找上门

[dapang1221]

appid/secret 方案不麻烦啊，代码都不用改，在应用的前一级加一个中间件就行了

[kekxv]

直接上新接口🐶

[Gota]

API 设计的时候就要考虑好升级时的兼容性, 如果是破坏性升级就得版本号 +1, 然后调用方自行决定是否升级.
每次升级都要使用者全改一遍一般很难维护下去.

[lyz1990]

下线，等他们炸

[yazoox]

我的理解，有点像，某服务 /API 发布了一年，现在要修改该 API 的 bug ，或者参数变化。需要通知使用该 API 的客户，他们需要升级代码才能调用 API ，否则一旦 API 升级，那些客户的程序就不能工作了。

如果找不到那些“客户”，为了“向前兼容”，只能使用新的接口了

[jsion]

最直接的方法辨识客户端身份就是通过认证，密码认证 /Token 认证，不会说你们接口调用不需要认证?

这种场景直接用 Kong 做 API 网关就好了，连平台都不用搭建，里面有 consumer 的模块，帮你把用户跟踪、访问控制都可以统一管起来，只需要为调用方创建并提供 consumer 对应的 key ，调用方在请求头部设置就可以，要觉得需要修改用户请求数据，也可以通过网关插件来改，然后透传给后端服务。

[ffxrqyzby]

1 是通过 ip, agent 等肯定可以追溯到调用方进行沟通
2 是就像 ls 们说的周知邮件

[jinliming2]

API 不兼容的升级，那么为了平滑过渡，新 API 和旧 API 要同时存在一段时间，然后通知迁移，给个 deadline 。deadline 前几天检查旧 API 的流量，如果还有人在用，就给对应业务方发最后通知，过 deadline 下线旧 API 。
应用调 API 需要强制标记业务方，这个对管理有益，业务方请求肯定是有封装的，统一加个参数也不麻烦（要是请求没有封装，散落在各个地方，这不重构留着过年？）

现在业务方没传业务标记的话，不妨统一升级一套 API ，强制传业务标记。这样出问题也可以很容易定位到具体是哪个业务出的问题。

[strawberryBug]

1.链路追踪，可以拿到所有上下游服务的调用链路。
2.监控，从应用调用外部服务的监控数据里，反查调用方。
3.网关或服务网格记录上下游。
4.啥都没有就群发邮件，敦促各方自查吧。

[CEBBCAT]

为什么需要找到调用方呢？ API 的升级应该是兼容性地。

如果实在需要找到调用方，那么可以通过 HTTP 的 UA 、来源 IP 等来判断来源。

如果想用鉴权来解决，token 、JWT 都是可以的

[Vindroid]

新旧并存可以吗？旧版能用但不再维护，并公告

[yuancoder]

接口提供出去就不要改了，非要改就新加接口

[iGooner]

做服务鉴权

[jones2000]

加版本号， 老的版本接口和新的版本接口并存

[HENQIGUAI]

把接口下了，谁找你就说明谁调用了。

[liuzhaowei55]

1 、2 都要做，可以先从 1 次开始做，梳理下当前的接口使用情况，2 是进阶的做法。
当前可以先从源 IP 来大致区分一下，找一下上游应用。

[SmiteChow]

你这槽点，让我无处下嘴。还是问一下领导同事吧。

[qeqv]

旧接口不要有破坏性改动，有的话上新接口，如果一定要下线旧的再做调研。和领导同事沟通下再做，或者和提新需求的人

[512357301]

一楼说的发邮件，会不会调用方也不确定自己有没有用这个接口，毕竟接口挺多的