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

前言

无论你是做面向ToB、ToC还是ToG的业务，开发业务系统，永远也逃脱不了与第三方系统对接的命运，例如：常见的支付宝、微信支付平台对接、短信平台对接，还有单点登录对接，以及与友商的数据接口对接等等，大到相对成熟的平台对接，小到一个接口的调用，基本上所有的开发都避免不了对接，它已经充斥在我们的日常工作中✒️，如何做好与第三方的对接，降低对接风险，按时保质的完成对接任务，已经成为我们非常头疼的问题了 ⚡⚡⚡。

今天我就在这里总结下，个人的经验以及互联网上发表的一些比较好的观点。有用的话，麻烦点个赞 👍 ，转发一波☀️。

首先当我们拿到对接需求的时候，直接3W三板斧理论抡起来，来帮助我们梳理一下对接思路。

What 是什么

对接的是什么？

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

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

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

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

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

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

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

例如：

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

但是现场的情况是：

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

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

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

我们以为的对接：

实际的对接：

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

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

Why 为什么

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

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

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

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

How 怎么做

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

对接前

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

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

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

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

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

对接中

1. 确定细节

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

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

泳道图示例：

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

时序图示例：

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

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

2. 一些建议

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

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

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

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

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

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

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

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

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

第一阶段

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

第二阶段

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

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

架构如下图：

第三阶段

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

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

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

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

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

架构如下图：

对接后

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

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

对接风险

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

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

• 对方服务升级，接口变了，未通知升级。（接口版本号制定好，接口做到向下兼容）

• 对方服务不稳定影响自有系统。（服务熔断、降级处理）

• 调用并发频率过高等。（控制频率）

总结与思考

没有最完美的方案，只有尽可能完善的方案，就像系统可用性达不到100%一样，我们做的每一步都要想好失败的场景，以及相应的对应策略，做好降级处理，最终的兜里方案就是人肉补偿了✈️✈️✈️。

QQ群【837324215】
关注我的公众号【Java大厂面试官】，回复：架构、资源等关键词（更多关键词，关注后注意提示信息）获取更多免费资料。

公众号也会持续输出高质量文章，和大家共同进步。