这是一个创建于 1701 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近做一个系统，接了不少业务之后出现问题了，不同业务有不同的监控系统要对接，设计了接口，现在对接了两套监控系统，结果又出现了第三套监控系统，原来设计的接口又不适用了。。 感觉每次调整接口不是办法，但是后边可能还有更多的监控系统，每个调用时候的传入参数都不相同，我也没办法现在去把所有的调研一遍。 那这种情况，可以设计一个什么样的接口来应对以后的情况吗？
 |
1
loading 2020-03-31 11:04:59 +08:00
这个世界没有银弹
你先兼容几个大厂吧，等大厂接口成了事实标准就好了。 |
 |
2
maichael 2020-03-31 11:09:38 +08:00
抽象好底层，业务层做组装，由业务层来扛差异。
|
 |
3
Mithril 2020-03-31 11:12:45 +08:00
没有接口可以应对所有情况的，哪怕你用 GraphQL 你也得看别人用不用。而且 GraphQL 也不是能应对所有变化的。
只能从设计上把接口层隔离出去，保持更底层的稳定。如果以后要应对很多不同系统，就想办法用一些脚本或者配置文件生成这一层的代码。如果就只处理几套接口那自己硬写就完了。 |
 |
4
qiayue 2020-03-31 11:18:05 +08:00
脏活累活才是价值所在
类似 ping++ |
 |
5
newtype0092 2020-03-31 11:26:07 +08:00
之前搞过类似的，总体来说就是分三层：
下层是完全与外部无关的，一份搞定 中间层是处理对接整体逻辑流程的，就是如果外部系统接入的逻辑步骤大致相似的，可以抽象成一套 上层是具体的接口层，对每个外部系统分别处理参数格式化之类的逻辑 这样下来是个树形结构，因为相同功能的外部系统整体逻辑不会差异太多，所以第二层基本只需要两三类，这样下来已经在保持灵活的基础上尽量减少工作量了。 |
|
6
Mithril 2020-03-31 11:31:38 +08:00
@newtype0092 所以说这个世界上没有什么问题是加一个中间件解决不了的，如果不行就再加一个。
|
Select Language