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

• 一定要从宏观到微观的搞清楚我们自己的系统是做什么业务，有哪些数据、哪些字段；需要提供给第三方哪些数据、哪些字段；又需要从第三方获取哪些数据、哪些字段。

这里的宏观和微观指的是宏观的系统物理架构、逻辑架构、部署架构、业务架构，微观的指系统模块、功能点的实现细节、及其涉及的表和其他三方对接历史。

要找到掌握这么多的人，可不是一件容易的事儿，这里能掌握这么多的人，一般都是团队的核心骨干、首席开发工程师❤️

• 同样的也要掌握第三方系统大致业务流程，部署架构等等，知己知彼，百战不殆。

为什么要搞清楚部署架构？在这里我分享下之前的一个真实案例，当场裂开的那种 🐜。

项目对接开始，前期双方都紧锣旗鼓的对接、测试等等，各个环节都很顺利，于是乎在测试环境稳定一周左右后上线。

上线之后的2-3天，突然的某一天，运营人员的一通电话☎️ 打破了祥和的假象！线上出现了很多重复的业务流水号⚠️。

例如：

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

| 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掉了，导致我们这边所有相关的业务出现了类似“档案查询接口不可用”的提示。

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

最后

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长，自己不成体系的自学效果低效漫长且无助。

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！
5931)]

[外链图片转存中…(img-tEqcUoYZ-1715209665931)]

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，不论你是刚入门Android开发的新手，还是希望在技术上不断提升的资深开发者，这些资料都将为你打开新的学习之门！

如果你觉得这些内容对你有帮助，需要这份全套学习资料的朋友可以戳我获取！！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！