三方对接「心得」与「体会」

和三方的关系要处好；

如果你看到这个话题，并不知道是什么意思，那么祝贺你，安安静静的当个小码农也挺好；

不过我敢说，随着职业生涯的慢慢发展，大家都得碰到，到时候就细细体会吧；

那年，我双手插兜，不知道什么叫三方对接；直到入职了一家金融公司后，承接了一个需求：跟银行对接数据流水；

从此就一发不可收拾，踏上了漫漫对接路，之后跟三方对接的活，都被我全部承包了；直到我后来办理离职手续，写的交接文档上，除了跟xxx对接，就是yyy对接；

后来想想，也没有那么不堪，我大致梳理了的下，分为以下几个点：

如果想做好对接，每个环节上都不允许出现问题；否则，由于某个环节拉胯，就会导致整盘对接停滞，最终，项目延期交付；

说到延期交付，那你就做好被开大会的准备吧；

会议上那是“八仙过海，各显神通”；大家各说各的，反正，并不是自己的问题；谁想背锅？背锅就是绩效问题，就是money问题；

【对接文档】
哦，在说对接文档之前，我还不得不提一下对接之前的事宜；

公司商务人员或业务人员可能会频繁的出差，有时候还会把你们技术老大叫上，为啥？还不是为了避免聊到技术问题，不会解答，让他兜底去的；

好吧，继续说回对接的事情；

一般拿到这种跟甲方对接的需求，对方会有文档抛过来的；至于这个文档是什么形式，反正五花八门，可真实有用的内容，也就那么几行；

在对接的文档中，我们主要关心的还是以下几个要点：加密方式、接口、传输形式；

首先，加密方式；每个对接的三方各有各的要求，一般都会对请求报文做加密、加签等处理，或者请求做授权处理；也不排除少部分不需要做处理；

请求报文加密：可以使用对称性加密，非对称性加密等方式；对称性加密，就是使用同一个密钥，对数据进行加解密，这样相对来说安全性差点；所以会使用非对称性加密的方式较多，非对称性加密，三方会生成一个密钥对，分为私钥和公钥，私钥三方保存，用来对数据解密；公钥提供给我们，我们通过公钥对数据进行加密；

请求报文加签：与上面一样，使用非对称性加密方式，对于原始数据进行加签；只不过这里需要注意的是，密钥对是自己生成的，自己保存私钥，用私钥对数据签名，把原始报文和签名后的报文，一起传给三方；然后三方通过我们提供的公钥进行验签；

如果用两种方式一起使用，是可行的；如果在实际情况下，那就根据甲方的要求，具体使用哪种方式吧；万一，他们要求不需要什么加密，这，也没毛病；

总结一下就是；

加密：保证数据不被泄露，公钥加密，私钥解密；

验签：保证数据不被篡改，私钥加签，公钥验签；

私钥：自己保存；

公钥：公开，可多人持有；

请求授权处理：有些三方接口，在你请求之前，需要对方开通apiKey和appSecret，然后拿到一个授权的token；在请求业务接口的时候，需要将这个token一并带过去，否则，请求无效；

这个不难理解，为的就是给系统接口多一层保障；看对方怎么要求，就怎么做吧；

最后还会有一层保障，在网络层面，双方运维会配置IP白名单；

第二个，传输形式；首先得看清接口的协议，常见是HTTP、HTTPS，少部分也是会用SOCKET，RPC等方式；

报文的格式：我觉得常见的还是两种，一种是JSON形式，另一种是XML形式；JSON格式主要搭配的是HTTP或HTTPS协议，常见的系统都是这么对接；XML格式一般会和SOCKET搭配，少部分会用这种形式，比如银行系统；

最后，接口本身；这个也是最重要的环节，言外之意就是接口的字段；包括字段的命名、类型、限制长度、业务意义等；

字段命名，这个没什么好讲；几乎所有系统都是英文命名，在英文命名的基础上，许多系统会采用驼峰命名法；

字段类型，一共几种形式；

字符串，这种类型想必大家都不陌生，是最常见和最常用的一种类型；

数值，主要是金额、年龄、数量等，会上该类型，包含浮点和整型；

对象，它是基础类型的综合，如字符串、数值、对象等，统一组合在一起，组成一种业务意义的类型；比方一个学生对象类型，包含姓名（字符串）、年龄（数值）、班级（对象）；

集合，就是一种或多种同类型的对象；还是学生的例子，把一个或多个学生对象放在一起，就组合成一个集合类型；

如果还需要三方将数据传输给我方系统的话，那就需要我们提供接口和接口文档了；

写接口，那是开发方面的事情，暂且不谈；提供接口文档，其实也是个技术活；

由于是我方的接口，一般上文讲的方面，都是我方决定的，但是，总有个别特例；

我曾经遇到过，明明是对方需要调用我方接口，可是，接口文档，传参，传输方式，协议等等，都已经“帮”我们定好了；

惊呆了，老铁！好吧，谁让你是甲方呢；

言归正传，正常流程是我们定义好自己的接口，然后再根据接口，拟定一份文档，文档内容无外乎就是上文提到过的内容；

编写接口文档的工具有很多，大家可以参考我之前写的《文档&工具》篇，里面具体列举了好用的一些工具；

总之，拿到对接文档，并且提取上面有用的内容，只是整个对接流程的第一步；

最后再说一遍，接口的字段很重要，千万别弄错了！

【对接沟通】
熟读对方提供的接口文档之后，其实还不能进入开发阶段；原因无他，就是这份文档并不是最终的版本，它需要在沟通的过程中不断去修改和完善；

需要沟通什么？总不会和别人去聊家常吧，当然是在看文档的过程中发现了你把握不住的问题，或者有疑问的业务场景；

和谁沟通？这时候你需要沟通的有两类人，一个是我方的业务经理或产品经理，另一个是三方的开发；

对应的问题找对应的人，当你觉得业务上有疑问，可以跟自家产品经理去进行battle；当你们产品经理不懂技术的时候，那么事情就变得简单多了；

在不影响最终功能的前提下，可以尽可能将技术实现变得简单点，这是跟自家产品讨论需求的核心要素；反正他不清楚技术实现，就使劲忽悠，总之自己要讲的有理有据，真假结合；场面堪比旺仔碰到奥姑，一个真敢说，一个真敢信；

但是有那么一小部分产品经理，他是懂点技术的，或者他就是开发转的产品，那就当我没说；

回归文档本身，当你觉得接口存在问题，那就不得不找到三方的开发了；

最后一顿沟通下来，如果对方文档是有问题的，就绕不开文档的修改和调整，务必让对方将调整过的文档发过来，记得做好文档变更，最好将上一版的文档也一并保留；

沟通途径：一般常见的有群聊、电话、会议、内部通讯软件等等；最后还有一种，叫口头沟通，这种方式水很深，坑很大，要小心提防，至于为何，懂的都懂；

在对接过程中，沟通是必不可缺的一个环节，良好的沟通能够提高效率和产出，与其说是和第三方对接，倒不如说和三方保持沟通；

【协调资源】
协调其实也是沟通的另一种表达方式，只不过协调过程中会涉及更广的方面，所以单独拿出来说说；

所谓协调，其实是对资源的协调，资源大致分为三种：人力、时间、成本；

人力资源：即参与对接流程的所有人；

我方人员主要涉及后端开发，运维，测试；这里的这几类人，包括我方和三方的人，这里没有将前端开发归类进去，因为一般不会涉及到前端开发；

整个对接流程环环相扣，一旦某个环节卡壳，就会导致下一步不能进行下去；

在不同的环节下，都会有不同的人去参与，如果你是主导开发，就需要合理发挥自己的协调能力，将每个环节的人合理利用起来，记住要保持高效的沟通；

时间资源：就是需要花费的时间；

一个优秀的主导人员，在人员协调的过程中，处理的得心应手，沟通起来也很顺畅，那么事情肯定是事半功倍的；

反之，团队中的人员不仅各个叫苦不迭，甚至到了后面都不愿配合，最后肯定是事倍功半的；

所以，要想得到更高效的时间，主要取决于上述的人力资源是否得到合理的协调，是否保持良好的沟通；看来，领头的尤为重要；

成本：顾名思义，就是需要的开销，这里一般指服务器资源；

服务器涉及到成本控制的问题，需要部署多少台服务，每台服务需要的配置，会不会涉及到中间件服务器等等；

从上级的角度考虑，他们肯定觉得花费越少的成本越好，服务资源越少越好，但是最终决定还得是甲方；

比如需要一个专项文件交互的FTP服务器，这时候不仅仅得有系统服务，还得额外加上中间件服务器；

大多数情况下，我们作为一名开发，只需要拧好我们的螺丝，别的，也确实跟咱无关；

但是，经历过跟三方的对接，你会打开新世界的大门，特别是这次对接需求全权由你作为主导的时候；

你会发现，开发仅仅只是占用了你一小部分时间，更多时间都用来沟通和协调去了；

曾经接到过一个紧急的对接任务，要求三天对接结束，一周内上线；上线后我发现，除去测试两天，剩余五天只有一天实打实坐在位置上开发，其他时间不是在跟对面会议群聊，就是在跟产品经理斗智斗勇，还有一天时间在运维那边配合他部署服务，并且连通与对方的网络；

【开发排期】
这是每次承接到需求都不得不去做的一份表格，为的是合理安排时间，做好开发计划；

但是也有一部分特例，好多流程都可以忽略，甚至不用测试；想必都猜到了，那就是传说中的紧急需求；如果需求中涉及到与三方的对接，在紧急也没用，上线时间全凭对方的配合度；

言归正传，其实开发排期是门技术活，它不仅需要你合理的安排好每个开发的时间，并且还要为测试预留好充足的时间，最后，还需要考虑到跟三方的沟通时间，联调时间等等；

如果排期评估的时间过长，上级脸色难免会不太好看，可是评估的时间过短，需要让每个成员做好加班的准备，这种极限拉扯，举棋不定，不得不说，难啊；

换做是我，我会将自己团队需要开发的部分按成员的能力分配，时间按难易程度调整，整体把控不超过上级默认的时间，最后加上附加情况，“由于涉及到三方部分，不能把控具体时间”；意思直接将这个锅甩到领导身上，他又不得不接，他会去主动协调三方资源；

【对接开发】
上文提到过，其实开发是整个对接流程中占用时间最少的，但却是最重要的环节，毕竟说的再多，最终还得代码逻辑和执行没问题；

在我承接的对接需求中，我通常会先确定好其中的接口、需求、排期等等没有异议了，再去做开发，因为只要熟知了其中的套路，开发起来并不难；

如果承接需求是一整个团队，而在整个对接的环节中，一不小心只被分配到了开发的活，那么就中奖了，这次任务你最轻松；

不过，大多数情况下，参与的人就那么两三个，那么得身兼数职，沟通、协调、对接等等都得你来，等你心力憔悴的时候，还需要穿插写点这次对接相关的接口；

今年体会过一个人承担整个流程，为何？人都被优化没了，只能独自抗下所有；

好好享受仅作为开发的时刻，回想起来，那会是你职业生涯中最开心的一段时光；

【流程提测】
费尽“九牛二虎”之力，完成对接联调，一切流程都感觉没问题，那就可以进入下个环节，提测；

在提交测试之前，还需要做一步操作：与测试一起过一遍要测试的范围，以及各自对需求的理解；

双方达成一致的共识，对业务需求保持统一的理解，这是非常有必要的，当然最终的解释权在于产品经理；

若是三方对接的测试需求，还需要额外提供一份模拟数据，以供测试同学能够模拟走完整个流程；

涉及到双方都参与的流程，无非是双方的接口交互，当测试走到这块流程的时候，更多情况下，是需要用到模拟数据的；

怎么准备模拟数据，分两种情况：我方请求三方，三方请求我方；

当三方将数据传输过来，可以让对方提供一份方便测试的未加密的请求报文，如果对方不提供，可以在平时的对接过程中，对三方解密后的报文进行入库存储，在提测时提供给测试同学即可；
当需要我方将数据传输三方的时候，一般我方测试会通过走流程的方式，去调对方的接口，可以不需要模拟的数据；但是以防万一，也可以将请求报文提供，特殊情况下，可以跳过流程，直接测对方接口；

在这个阶段，也会涉及到沟通，但更多的是测试同学和三方开发之间的沟通；但是当他们在沟通过程中，涉及技术方面的问题，也是需要咱开发去介入；

当按照双方约定的数据、报文格式等走完测试流程，是该到了发布的时刻，只需要双方沟通好，统一时间发布即可；

说了这么多，沟通才是三方对接的主旋律，保持高效的沟通，就是成功的第一步；

那么，问题来了；

遇上难以沟通的甲方，你会如何处理？