今天我们就来聊聊，如何做好常见第三方系统的对接，分享几个真实的坑爹案例--什么是 "坑爹"？

对接的是什么？

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

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

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

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

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

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

上线之后的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