常见的系统间接口方式(02)-中间件的数据接口模式

导读:

原文路径:https://mp.weixin.qq.com/s/uq9DfxE5_cvAsitqlcblBg

大家可以关注我个人公众号,所有分享内容,会在公众号第一时间推送,且阅读排版更好。

愿大家的学习,轻松且愉快。

如果大家觉得有用,希望转发关注,谢谢。

中间件的数据接口模式,也会被称为中间数据库的数据交互模式,或者叫数据平台的数据交互,总的来说,就是在各个业务系统间,建立一个独立的数据库,保证系统间的数据交互,或者叫数据接口。

 

为什么要使用中间数据库的接口模式?

 

对于很多企业来说,经常需要多个业务系统支持。如果采用系统间相互的函数调用模式,会导致接口过多,难以管理。基于此情况,多数企业会选择采用中间数据库,以满足多个系统间的数据流转。

企业很多时候不愿意大规模采用RFC调用的接口模式,常基于且不限于以下几个原因:

 

1.很明显,基于上图中只有5个系统,但其接口的复杂性已经较高了对于企业来说类似上图中的接口模式,是不易管理的。而且,实际业务中,少有规模的企业,都存在多个系统,并且各个系统之间接口业务不一样。在类似此种情况下,当企业的接口较多时,如果均采用点对点的相互调用接口,对接口以后的维护成本会很大。随着业务发展,很有可能最后谁也不知道某个接口的是否被使用,或者某个接口到底如何被使用。

 

2.点对点的RFC调用接口,必须要求接口两端的功能均可用,这就有可能会影响业务的及时性。比如,常见的生产管理系统,一般其业务及时性要求很高,生产上发生一笔业务,通过RFC调用传输给ERP,但是ERP系统可能因为财务账期、其他程序锁表等,导致RFC接口无法立刻被调用成功。但生产管理系统又不可能一直等待ERP系统的执行,这样就会出现难以调和的矛盾。

 

3.其实,很多时候,基于数据安全、信息安全等多方面的考虑,很多系统并不愿意给其他调用自己系统功能的权限,这样也就限制了RFC接口模式的使用。

 

 

基于上述弊端,企业为了降低系统接口统一管理的难度,以及接口后期的维护成本,结合从安全及业务及时性等角度的综合考虑,一般会采取建立中间数据库的接口方式。

 

那么,中间数据库接口模式的工作机制是什么?

如果两个业务系统,采用建立中间数据库的模式进行数据交互,其工作原理可以简单理解为:

首先,会部署一个专门的数据库或者数据系统,也有称为数据平台等,实际上,就是个专门用于存储系统间交互数据的数据库。

业务系统不会直接将要传输的数据,传输给其他业务系统,而是会传输给这个中间的数据库,要使用数据的业务系统,会主动去中间数据库取自己需要的数据。

如下图所示,A系统会将数据写入至中间数据库,B系统会取中间数据库去取需要的数据,反之亦然。

 

 

采取中间数据库接口的方式,在实际使用中,一般是存在多个系统之间有数据交互的业务情况,如下图所示。

基于下图,我们对比之前多系统接口采取RFC方式的图例,我们很容易看出来,采取中间数据库接口的交互方式,其接口更加容易管理,且交互方式更加安全。

当然,采用中间数据库的接口方式,其弊端也比较明显,可能会导致一些常见问题,比如:

 

1. 数据接受的系统,不能够及时处理数据,不能够在第一时间验证数据的业务及系统层面的准确性。

很有可能出现,传输数据的系统将数据写入中间数据库,但是,需要接受数据的系统,在中间数据库读取数据时,发现数据有问题,并无法正常使用。

此种情况,作为接收数据的系统,很难在第一时间对数据进行管控和校验。

比如,我曾在项目中遇到过一个情况,某企业针对SAP系统与MES系统的所有接口,采取了中间数据库的接口模式。当发生原材料领用的业务时,首先,MES系统出库过账,进而将数据传输给中间数据库,SAP系统会取中间数据库的数据,完成过账。但是,实际执行中,某物料的库存只有10个,MES系统中的程序计算错误,显示库存有12个,用户执行领用12个,且在MES系统中领用成功。此时,当领用12个的数据传输给SAP,由于SAP中的库存数量只有10个,无法针对领用量12进行过账,最终出现问题。

基于这一案例,如果我们采取的是RFC的接口模式,一旦领用数量大于库存数量,在SAP端就无法过账,直接就反馈给MES了,但是,采用中间数据的接口方式,其校验就会比较滞后,容易产生问题。

2.接受数据的系统,什么时候去数据库取数据;

 

其实,基于列举的第一个问题,我们不难看出,中间数据库的接口模式,对于数据接收方的系统来说,有一个问题:应该在什么时候去取数据?

 

因为基于上述工作机制,数据发送方的系统在给中间数据库写入数据时,数据接收方的系统并不知道。

 

所以,我们常见的处理方式就是定义自动的系统后台Job,也有的系统会称为后台timer。

 

简言之,我们就会在系统中定义一个程序,每个一段时间自动去中间数据库取一次。根据业务的及时性要求不同,我们可以定义不同的时间段,比如每十分钟取一次,或者每小时取一次,或者每天取一次等。

 

采取自动后台Job的方式,可能带来的问题,也比较明显:数据发出方的系统,在某天只写入了三次数据,如果数据接收方定义每小时取一次,那么,实际取数据的次数是24次,对于系统服务器来说,为了3次数据,却需要执行24次程序,这就有些占用服务器资源了。

 

对于一些业务较多、系统交互较多的企业,排程系统后台Job就变成了一项非常重要的工作。这要基于业务要求本身,系统程序大小等因素,去决定job的执行频率及执行顺序。

比如,实际情况中,很多取数程序的本身必须有先后顺序,必须得先取某数据,才能取其他数据;有的程序太大、所取数据太多,就不能排在工作时间去取数,因为其很有可能占用过多服务器资源,导致其他业务难以顺利执行,所以,一般此类Job,会被安排在凌晨执行,等等。

 

3.鸡蛋被放在了一个篮子里。

 

基于中间数据库的接口模式,我们很容易就能看出来,如果过于集中地使用中间数据库或者数据平台等,意味着我们把核心数据都放在了一个数据库中。如果这个数据库出现问题,就有可能大面积影响相关系统的正常运转。基于这种情况,如果采取中间数据库的方式,其系统安全策略及相关灾备系统等的措施,就非常重要了。

4.非企业本身的外部系统,如果需要与企业自己的系统进行数据交互,那么,基于安全层面的考虑,不会建议外部企业的系统直接访问内部数据库。

那么,如果外部系统与企业内部系统有数据交互需求的话,应该采用哪种方式呢?

 

这个就要基于我们下一篇要介绍的“文件传输的系统接口模式”。

 
 

  • 8
    点赞
  • 102
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
本项目是一个基于Java编程语言和消息中间件ActiveMQ的企业粮食管理平台和区粮食管理平台接口数据收发项目。在该项目中,我们主要实现了以下功能: 1. 实现了数据的收发功能:通过ActiveMQ实现了企业粮食管理平台和区粮食管理平台之数据收发功能,确保数据的可靠性和实时性。 2. 实现了区平台的数据上传功能:通过AOP技术和适配器,对区平台的数据进行适配和转换,然后将数据向企业平台上报。同时,我们还在上传记录和上传结果页面提供了重新上传功能,以便用户进行数据的纠错和补充。 3. 实现了企业平台的数据校验和落功能:通过策略模式,对不同业务的数据进行校验和落操作,确保数据的准确性和完整性。 在该项目中,我们还进行了一些优化和拓展: 1. 优化了数据的传输效率:通过对消息队列的配置和优化,提升了数据的传输效率和稳定性,确保数据能够及时准确地传输到目标平台。 2. 拓展了数据的处理能力:通过引入分布式处理技术和云计算技术,提升了系统的处理能力和扩展性,满足了不同规模企业的需求。 3. 引入了数据分析和挖掘技术:通过对数据的分析和挖掘,提供了更全面和准确的数据分析和报表功能,帮助企业进行更好的决策和管理。 总的来说,该项目通过使用Java编程语言和消息中间件ActiveMQ等技术,实现了企业粮食管理平台和区粮食管理平台之数据收发和处理,为企业提供了更好的数据管理和决策支持。同时,通过优化和拓展,该项目还具备了较高的扩展性和适应性,能够满足不同规模企业的需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值