系统之间的数据对接和传输，产品经理视⾓的万字总结
编辑导语：⼀个孤⽴的系统即使录⼊了再多的数据，其本⾝的作⽤也是有限的，只有和其他系统产⽣关联，互相之间进⾏数据对接和传输，才能发挥其真正的功能和作⽤。本篇⽂章中，作者为我们分析总结了数据传输的场景和意义、数据传输的⽅式、数据传输的处理机制以及数据传输的注意事项。
⼀个系统装再多数据，不与其他系统交互，那也是孤岛系统。⼀个系统若很外向，不断撩拨周围的系统，也乐意被撩拨，成为了众系统中的“交际花”，那么这货基本就是中台的性质。
⽽更多的系统是介于上述两种极端之间的，像⼈⼀样，⾃⼰搞⽣产，也要参与社交——就是系统之间的数据对接。对接的本质是为了实现数据信息的传输，在后端产品的世界⾥，各⼦系统之间，或与外部系统之间的对接⾮常常见。
作为产品经理，不仅要知道数据从哪来，还要理清楚获取数据之后的握⼿⽅式、运算逻辑、异常规则、容错机制、数据⽇志等等。
本⽂尝试聊聊如下话题：
•数据传输的场景和意义
•数据传输的⽅式
•数据传输的处理机制
•数据传输的注意事项
⼀、数据传输的场景和意义 1. 数据传输的应⽤场景
•前端和后端本⾝⽆时不刻的数据互动；
•公司的各个系统之间的信息共享：⽐如，式系统部署之后，就需要各个系统模块之间进⾏数据的配合，⽐如订单系统的库存扣减数据要同步给备货系统进⾏采购；
•与第三⽅平台的对接：⽐如⼊驻第三⽅销售平台亚马逊之后，店家可能⾃⼰需要管理⾃⼰的订单，这时候就要从亚马逊平台获取订单数据，也就是抓取；
•调⽤现成的公共插件：避免重复造轮⼦，市场上很多开放性的功能插件可以调⽤或接⼊，⽐如接⼊百度地图的API，接⼊⼩程序的⼆次开发。
2. 数据传输的意义
•不重复⽣产数据库，避免资源和功能的浪费；
•统⼀数据的维护或⽣产源头，避免数据不同步：⽐如同⼀个公司的两个系统都要⽤⼈员信息架构数据，如果各⾃都能维护，势必出现不⼀致，也浪费资源；
•别⼈家的数据，⾃⼰没办法⽣产；
mysql下载哪个盘
•复⽤现成的轮⼦，API或SDK共享（可能⾃⼰也发明不出来）。
⼆、数据传输的⽅式
数据传输的⽅式，作为产品经理我将其分为：接⼝传输、中间件传输、message⽅式传输等。散开了说，⽐如：
MQ（队列）、HTTP接⼝、otter、⽂件共享传输等，每⼀种⼜有细分的⽅式和适合的场景。
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，加密传输的数据，使得安全性提⾼。通⽤性⽐较强，⽆论客户端是架构，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接⼝都可以，在具体的场景开发都可以理解的。
2. 数据库对库同步
接⼝完成的是信息的传输，相对来说⽐较保守，易于保护敏感信息。⽽数据库同步实际就是表对表的共享，相对接⼝就⼤⽅多了，因此多发⽣在企业内部两⼩⽆猜的系统之间。
数据库同步有这么⼏种办法：
1）使⽤中间表
例如：B系统要⽤A系统的数据，可以新建⼀个数据库DB，A系统将数据写⼊DB，B系统再到数据库中读取数据。
也就是将数据放进⼀个中间表中，A、B两个系统都对这个表有访问权限，这样的好处就是选择性地将⼀⼤批数据共享出去。
2）直接调取对⽅数据表
这个⽅式就是在B系统在开发时，在代码中加载A系统的数据表，直接从数据表中取数据。这就是实时拉取对⽅的数据，B系统⾃⼰本地不做表保存。⽐较省，事但是耦合性较⼤，数据量⼤的时候不建议。
3）同步对⽅的数据表
直接将对⽅的数据表copy⼀份过来，并保持实时同步，otter技术就是常⽤的⼀个⽅法。
otte可以将mysql的数据同步⾄另外mysql或者oracle，也⽀持双向同步（即A库同步给B库，B库也同步给A库）、⽂件同步等，主要应⽤应⽤是多数据中⼼、BI系统抽取数据、灾备。
该⽅式需要DB协助配置。也就是做了⼀个mysql的同步平台（带WEB管理界⾯），在界⾯上，你可以定义相应的映射规则，otter进程就会根据你定义的规则读取binlog，并更新到⽬标库中去。
该⽅式主要⽤于内部系统之间（⼀般⼀个公司的才这样）库对库的传输，可以实现数据的相互同步更新。建议应⽤在数据量⼤的时候，或者基础数据对周边兄弟系统提供基础⽀持的时候。优点是占⽤资源少，交互更加简单可靠。
当连接B的系统越来越多的时候，由于数据库的连接池是有限的，导致每个系统分配到的连接不会很多，当系统越来越多的时候，可能导致⽆可⽤的数据库连接。
这时候otter⽐较适合。⽽两个不同公司的系统，不太会开放⾃⼰的数据库给对⽅连接，因为这样会有安全性影响。
3. ⽂件包共享⽅式
⼀些第三⽅公司为了保密，不愿意提供接⼝，那么会把⽂件存在类似⽹盘或⽹页上，供需求⽅下载。
双⽅系统约定⽂件服务器地址、密码、⽂件命名规则、⽂件内容格式等，通过上传⽂件到⽂件服务器，进⾏数据交互，对⼤数据量的也很适合。这就是⼀种异步的上传下载机制，双⽅的操作割裂开，并且⼀旦上传可以被多个需求⽅使⽤。
⽐如：第三⽅⽀付公司与需求⽅约定好SFTP服务器（⼀种⽂件服务器，可以理解为⽹盘）的账号密码，然后⽀付公司将账单数据上传到SFTP服务器上，那么需求⽅就可以登陆SFTP客户端，进⾏下载、解析，然后保存使⽤。这也实现了数据在服务器之间的传输。
实际上这些数据本⾝也是加密的，所以只有协议的公司才能拿到解码钥匙。长期合作的公司就会持续更新，授权的公司就可以持续下载和解析。这⾥就有⼀个下载频率的问题，⼀般使⽤定时任务按⼀定频率去下载。并且要考虑丢包的机制。
案例：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。