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

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

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

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

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

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

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

上线之后的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天动了什么现场环境等等。

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

我们以为的对接：

实际的对接：