系统孤岛时代已终结，数据必须流动才有价值；本文用一张思维导图、五大传输方式、四类处理机制，帮你三分钟把接口、MQ、文件、数据库同步全链路拆解到手，让产品经理也能秒懂后端对接的选型与避坑。

世界最遥远的距离，是我站在你对面，你却在另一台服务器里。世界最温暖的举例，是我在internet的另一端，而你挑着一筐刚刨出来的数据来看我。——做产品的柏拉图

一个系统装再多数据，不与其他系统交互，那也是孤岛系统，孤独没女朋友。

一个系统若很外向，不断撩拨周围的系统，也乐意被撩拨，成为了众系统中的“交际花”，那么这货基本就是中台的性质。

而更多的系统是介于上述两种极端之间的。像人一样，自己搞生产，也要参与社交——就是系统之间的数据对接。

对接的本质是为了实现数据信息的传输。

在后端产品的世界里，各子系统之间，或与外部系统之间的对接非常常见。

作为产品经理，不仅要知道数据从哪来，还要理清楚获取数据之后的握手方式、运算逻辑、异常规则、容错机制、数据日志等等。

本文尝试聊聊如下话题：

• 数据传输的场景和意义
• 数据传输的方式
• 数据传输的处理机制
• 数据传输的注意事项

1 数据传输的场景和意义

1、数据传输的应用场景

1）前端和后端本身无时不刻的数据互动。

2）公司的各个系统之间的信息共享。

比如，式系统部署之后，就需要各个系统模块之间进行数据的配合，比如订单系统的库存扣减数据要同步给备货系统进行采购。

3）与第三方平台的对接

比如入驻第三方销售平台亚马逊之后，店家可能自己需要管理自己的订单，这时候就要从亚马逊平台获取订单数据，也就是抓取。

4）调用现成的公共插件

避免重复造轮子，市场上很多开放性的功能插件可以调用或接入，比如接入百度地图的API，接入微信小程序的二次开发。

2、数据传输的意义

1）不重复生产数据库，避免资源和功能的浪费。

2）统一数据的维护或生产源头，避免数据不同步。

比如同一个公司的两个系统都要用人员信息架构数据，如果各自都能维护，势必出现不一致，也浪费资源。

3）别人家的数据，自己没办法生产。

4）复用现成的轮子，API或SDK共享（可能自己也发明不出来）。

2 数据传输的方式

数据传输的方式，作为产品经理我将其分为：接口传输、中间件传输、message方式传输等。散开了说，比如：MQ（队列）、HTTP接口、otter、文件共享传输等。每一种又有细分的方式和适合的场景。

1、接口

这是一种传统的问答式的传输方式，是典型才c/s 交互模式。

相当于一台客户机，一台服务器（注：这里的客户机或服务器根据数据的提供方和接收方相对而言的，并不一定是实际的）。

目前我们常用的http调用、java远程调用、webserivces 都属于这种方式，只不过，不同的就是传输协议以及报文格式的区别。

1）接口的作用

通过接口，可以调用成熟的第三方功能插件为我所用（一般就是API接口），也可以根据实际需求由开发写具体的接口代码解决具体场合的信息传输问题（一般所说的http接口）。

对后端产品经理来说，http接口的使用场景最多。比如：公司先上线了OA系统，后上线了订单系统，订单系统需要同步OA系统的人员组织结构信息。那么一个可行做法就是OA系统创建一个接口，订单系统请求，获取最新的人员结构信息。

这个笼统的方案描述中，包含了这么些信息：创建接口、请求接口、获取最新信息等，那么分别是什么以及有什么原则呢？下面分别讨论。

2）哪一方负责创建接口？

在讨论需求的时候，开发会问哪方创建接口呢？有时候产品经理只知道需要建接口，不知道哪个系统来建。

可以这样理解，如果把数据源比成一缸水，那么接口就像是凿的一个口，口只能是在缸上面的。

所以接口必须是在被请求的数据源这边，由被请求的一方定义接口。

注意，这里的数据源是相对的数据源，就是被请求的一方就是数据源方。

实际上可能目标数据在请求方。比如例子中也可以是OA系统请求订单系统，但是如果这样的话，接口就是订单系统创建了。因此确切说是被请求的一方创建接口。

通俗的讲就像是求婚：男方去求婚带一百万，女方接到后就把姑娘嫁过去，这是一来一回。

女方也可以去求婚，只是是直接带着姑娘去敲开男方的门，而后男方才把一百万送到女方，这也是一来一回。

3）什么是定义接口

定义接口，其实就是定义缸上的出水口。口的大小、滤网、放水的频率等，就是个规则。

这个规则约定了哪些数据是需要流过去，以及流过去的条件（像门禁密码一样）。

定义接口就是设定口令、数据范围、推送前的筛选、转化运算规则等，这是接口的核心内容。

4）数据在哪一方做转义？

某些时候，数据从源头到应用端不是原封不动的，而是转化了。比如80分、90分都是及格，可能使用者只需要两个值：及格or不及格。

那么这就涉及到是在接收之前就转化为是否及格，还是接收之后自己转化的问题。

考虑的依据主要是：该数据获取之后是否还有其他用处，只要有可能被二次使用，最好是取原数据。

提前转化的好处是，流转的数据会变得简单直接。但是需要注意的是转化后数据量不一定会少，比如：数据源是订单维度的，而目标是转化为订单+商品维度的数据，这就可能一条变多条了。

5）是主动获取还是对方推送

有时候开发还会问是对方推，还是我们主动去取，这就是接口的post/ get方式问题。

get是从服务器方请求数据，post是向服务器方传送数据。前面也提到了，接口交互数据可以是主动推送，也可以是请求获取。

主动推送一般是数据生产方一旦更新，则触发推送，将所需字段对应值传递过去。

请求获取就是数据需求方传递请求参数（请求参数一般是若干条件，比如：账号+密码）。数据生产方则按照协议响应，给出满足条件的数据到请求方（也就是返回参数）。

所以可以看出来，如果对时效要求高的，则建议生产方主动推。比如产生一个新用户，那么就可以理解把用户的信息主动推送给运营方使用。

如果是时效不高或者数据量大，则可以按一定频率主动请求，有利于系统负荷压力稳定。

在具体使用的时候，如果你对接的系统比较多，那么建议做一个公共接口，以后谁想用他们自己来对接就好了，不然就要来一个对接一次，麻烦还有风险。

另外，选择post/ get，最终由双方开发权衡决定，但是一般而言：

get传送的数据量较小，不能大于2KB。post传送的数据量较大，一般被默认为不受限制。get安全性非常低，post安全性较高。

6）接口定义是开发的事情，但产品经理需要给出轮廓

在输出方案的时候，接口定义的规则是什么？传参和返回参数是什么？重复传参时是跳过还是再次获取（一般都再获取）？必传参数是什么？是否回传接收结果给数据生产方？这些都是要有大致明确并传达给开发测试的。

比如：每小时/次取对方表中第一页最新的50条数据。超过的数据下个小时继续取。可以这样设计：

因为一些关键参数牵扯到业务的唯一性维度，这些都在产品经理调研的时候获知的，而这些可能开发根本不知道。因此产品经理要给出轮廓和大概方向。

7）数据流转的时效

接口创建之后，如果是接收的对方数据库中的信息，那么上线之后，要考虑先进行数据的初始化（保持基础数据一致）。然后确保后续双方是同步的。

同步的机制和要求是在定义方案的时候就确定的。那么怎么确保同步呢?方法是两种：触发式和定时任务。

触发式就是一旦一个参数值满足条件，则触发同步。

定时任务式一般用在不知道数据源什么时候更新，需求方就要设置一个定时任务的脚本，隔一段时间查询一次。请求的频率需要与更新的频率相协调。

8）总结接口的特点

优点：时效性强，可以触发式实时问答。容易控制权限，通过传输层协议https，加密传输的数据，使得安全性提高。通用性比较强，无论客户端是.net架构，java，python 都是可以的。

缺点：服务器和客户端必须同时工作，当服务器端不可用的时候，整个数据交互是不可进行。当传输数据量比较大的时候，严重占用网络带宽，可能导致连接超时。使得在数据量交互的时候，服务变的很不可靠。

9）相关概念扩展

API：即“应用程序编程接口”，是一些预先定义的函数，无需访问源码或理解内部工作机制的细节，即可调用的对象。比如和Windows系统沟通，需要调用Windows提供得API。和新浪微博进行沟通，需要调用新浪微博提供得Api。其实它就是一个软件系统对其他软件系统提供得服务。

• open api：是指对外开发的接口，比如百度地图API、facebook的API等。
• SDK（“软体开发工具包”）：可以理解为api的集合，也就是封装后的API为，功能更完善。
• http接口：是基于接口的传输方式（HTTP协议）来命名的，当然也有基于其他协议传输的接口。

比如：

• 和Windows系统沟通，需要调用Windows的API（CreateWindowEx, bitblt,等等），是C语言函数形式的接口。
• 和.Net框架进行沟通，需要调用.Net提供得Api，是以C#，VB函数/类形式的接口。和新浪微博进行沟通，需要调用新浪微博提供得Api，是以Http请求形式的接口。
• API接口的叫法相对http接口叫法更笼统和概念化一些。因此在写方案的时候，http接口和API接口都可以，在具体的场景开发都可以理解的。

本文由人人都是产品经理作者【产品参赵】，微信公众号：【产品参赵】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于 CC0 协议。