zoukankan      html  css  js  c++  java
  • 常见的系统间接口方式(02)- 中间件的数据接口模式

    导读 

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

    正文 

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

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

     

    企业很多时候不愿意大规模采用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了,MES系统也会停止出库领用,用户会去查询具体数据原因。但是,采用了中间数据的接口方式,其校验就会比较滞后,容易产生问题。 

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

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

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

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

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

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

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

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

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

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

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

     

     那么,如果外部系统与企业内部系统有数据交互需求的话,应该如何进行数据接口呢?

     这个问题就引出了我们下一篇要介绍的内容:“文件传输的系统接口模式”。

     转自:https://mp.weixin.qq.com/s/uq9DfxE5_cvAsitqlcblBg

  • 相关阅读:
    Codeforces Round #592 (Div. 2)C. The Football Season(暴力,循环节)
    Educational Codeforces Round 72 (Rated for Div. 2)D. Coloring Edges(想法)
    扩展KMP
    poj 1699 Best Sequence(dfs)
    KMP(思路分析)
    poj 1950 Dessert(dfs)
    poj 3278 Catch That Cow(BFS)
    素数环(回溯)
    sort与qsort
    poj 1952 buy low buy lower(DP)
  • 原文地址:https://www.cnblogs.com/turnip/p/13999431.html
Copyright © 2011-2022 走看看