今天我们来聊聊，如何做好第三方系统对接

正常情况数据应该是这样的：

| id | 流水no | 创建时间 |

| — | — | — |

| 10378 | QJ00073001 | 2020-12-18 12:10:11 |

| 10379 | QJ00073002 | 2020-12-18 12:10:11 |

但是现场的情况是：

| id | 流水no | 创建时间 |

| — | — | — |

| 10378 | QJ00073001 | 2020-12-18 12:10:11 |

| 10379 | QJ00073001 | 2020-12-18 12:10:11 |

存在重复的流水号：QJ00073001⚠️，当场我就裂开了，这TM测试环境跑了一周没事儿，正式环境都搞了2-3天了出现问题，趁事态没有扩大，各种排查，

是不是线程安全问题啊？是不是第三方问题啊？这2天动了什么现场环境等等。

很快我们就定位出问题来了，原来是昨天晚上，又对接了一个新的局点导致的，第三方服务部署架构是分级部署的。

我们以为的对接：

实际的对接：

第三方的部署架构是每个局点单独部署一套服务，所以他们那边的流水号都是从1开始的，导致我们直接拿流水号来用的时候裂开了。

处理方式也很简单，流水号加上局点code即可，例如：HW31QJ00073001、HW89QJ00073001

Why 为什么

---

为什么要对接第三方系统？

比如我们经常对接支付宝、微信平台，你不可能自己开发个支付系统的，再说了支付宝和微信支付的用户也多，方便你我他，可以让我们更专注自己的业务开发。

再比如对接短信平台、快递鸟平台等等。

总结下：基本上都是自己公司想做一件事情，但是自己又没有足够的物力、财力、精力去实现，那么就去找市面上有成熟的解决方案，把专业的活交给专业的人，来以最小化的成本实现我们的需求。

How 怎么做

---

这里我们再以对接前、对接中、对接后这3个阶段，来分阶段讨论下每个阶段应该怎么做，才能稳步推进我们的对接需求。

对接前

• 明确需求，以及对接的价值（是否真的有必要做及其实现的意义，有可能这一步直接让对接流产✋。。。）

• 搞清楚我们跟第三方的大致交互流程和双方所需数据。（别鸡蛋里面找骨头，他也找不到啊，你要我没有的数据，我可怎么提供）

• 评估大概所需要花费的钱，毕竟跟别人对接，大部分情况下是花钱的。（花的钱太多有可能得不偿失）

• 确定双方相关业务负责人、技术负责人，以及要指定一个总负责任人来推动双方稳步前进（别双方都是放羊模式）

• 制定一个合理的计划，确定联调时间、上线时间、试运行时间（一定要制定合理的计划）

对接中

1. 确定细节

拉上双方业务人员、技术负责人，共同制定接口调用流程，画出接口调用流程图、泳道图、时序图等，毕竟一图胜千言。

这里一定要拉上真正熟悉业务和技术的人去沟通，别找中间人去传话了，也别找不懂的人去，否则在这一步，坑就已经开始挖了。

泳道图示例：

泳道图很清晰的能看到对接双方交互流程，职责划分清晰。

时序图示例：

时序图能清晰看到消息传递的时间顺序。

下面的关键细节我列一下：

| 关键细节 | 事项 | 备注 |

| — | — | — |

| 字段内容 | 双方确定需要提供什么字段、需要获取哪些字段 | |

| 接口版本 | 接口版本规范，url中 /v1/xxx，还是header中 verison=v1，以及协商版本具体规范细节 | |

| 大量数据 | 是分页返回，还是以文件的形式，例如csv等 | |

| 异常处理 | 定义错误码，以及其对应的相应操作，有什么兜底补偿方案没 | |

| 调用方式 | 主动拉取还是被动等待推送 | 建议双向即可主动式，又可被动式 |

| 通信协议 | Restful、Webservice、MQ、Websocket等，复杂的对接，是否可以考虑提供sdk | 一般建议Restful |

| 报文协议 | json、yaml、xml、自定义等 | 一般建议Json |

| 接口方式 | 同步接口还是异步接口 | |

| 接口安全 | Oauth2.0 sign token等，注意内外网、以及业务的保密级别 | |

| 幂等性 | 确保双方接口是否都是幂等的，防止重复提交 | |

| 重试机制 | 一定要确认是否需要接口调用失败后的重试机制，保证数据传输的最终一致性

重试机制包括 实时重试调用：指定次数 + 调用失败持久化，数据库定时任务重试 | |

| 接口文档 | 要有详尽的说明和丰富的示例代码 | |

| 联调环境 | 可以随便折腾的那种 | |

2. 一些建议

• 文档先行，统一规范（双方按照文档来开发，统一规范）

• 需要自己有对接模拟接口，防止三方公司接口迟迟未完成，影响整个项目进度

• 第三方对接模块做成单独的服务最好独立出来，尽最大努力保证服务的高可用、稳定性。（不然你滴电话就要被打爆了☎️）

• 接口升级，尽量做到影响最小，不去修改接口协议，如果必须要动，要做到接口兼容老版本。

• 尽量保证接口的幂等性，因为会有重试机制和补偿方案；

• 接口当中生成requestId，用于日志记录，到返回结果的全流程跟踪，接口接收到的数据，以及解析之后的参数值，都要用日志记录下来，方便查看原因。

• 编码推荐使用注解式声明编程 Feign

举个例子：把第三方对接模块做成单独服务的好处、以及做好对外服务降级操作（业务逻辑降级）。

之前项目中有个需求，需要对接一个厂商的服务，大致流程是调用一个实时接口，输入身份证号，返回这个身份证号关联人的最新的所有的档案信息。

第一阶段

一开始我们是直接把对接代码写到我们业务系统的，这也很正常。

第二阶段

使用一段时间后，公司的另一个团队也需要对接这个厂商，那么现在是否也复制一份儿代码去对接呢？显然我们不会这么去做，第三方接口升级啥的，我们2个团队都要改，耦合性太强了，还有万一后面我们还有其他团队对接呢？不可能都用这种方式。

所以我们的做法是把这个对接模块独立出来，做成一个单独的服务，供所有的团队使用，作为微服务的一部分。

架构如下图：

第三阶段

平稳运行一段时候后，突然的某一天第三方服务厂商服务down掉了，导致我们这边所有相关的业务出现了类似“档案查询接口不可用”的提示。

已经做了断路器、服务通用降级，返回提示信息“档案查询接口不可用”

虽然是第三方的问题，也有提示的降级操作，但是呢，用户体验还是不够友好，于是乎我们开会讨论更完美的方案，我们的需求是返回实时的个人档案信息，

但是如果当第三方服务down了，返回之前查询过的非实时数据，并给个不是最新的提示，也总比提示“档案查询接口不可用”要优雅的多。

于是乎我们会在每个用户查询到档案后，自己本地数据库存一份，当第三方服务不可用的时候去降级到本地数据库查询使用。

架构如下图：

对接后

持续跟踪一段时间系统的使用情况，然后进行总结，看看是否可以把这块对接流程规范化，做标准化接口，将自己的能力或者数据标准化出去，类似于开放平台，让别人按照你的标准来做。（那就乌鸦变凤凰了）

最后我也总结下，之前遇到的风险点：

对接风险

• 对方不配合 （奶茶☕、香烟给安排上，还不行只能让上级去推动了）

• 对接要从源头留痕，防止后面对方扯皮，要留证据。（拿证据说话）

最后

看完上述知识点如果你深感Java基础不够扎实，或者刷题刷的不够、知识不全面

小编专门为你量身定制了一套<Java一线大厂高岗面试题解析合集：JAVA基础-中级-高级面试+SSM框架+分布式+性能调优+微服务+并发编程+网络+设计模式+数据结构与算法>

针对知识面不够，也莫慌！还有一整套的<Java核心进阶手册>，可以瞬间查漏补缺

全都是一丢一丢的收集整理纯手打出来的

更有纯手绘的各大知识体系大纲，可供梳理：Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~

结构与算法>

[外链图片转存中…(img-h8Q6VMW3-1721170237622)]

针对知识面不够，也莫慌！还有一整套的<Java核心进阶手册>，可以瞬间查漏补缺

[外链图片转存中…(img-6DBGpJ3r-1721170237623)]

全都是一丢一丢的收集整理纯手打出来的

更有纯手绘的各大知识体系大纲，可供梳理：Java筑基、MySQL、Redis、并发编程、Spring、分布式高性能架构知识、微服务架构知识、开源框架知识点等等的xmind手绘图~

[外链图片转存中…(img-eM2GUEGb-1721170237623)]

[外链图片转存中…(img-4D5JEg3z-1721170237623)]