有关一种面向双中台双链架构的内生性数据安全交互协议毕业论文写作资料-论文写作网

简介:该文是有关数据和架构专科开题报告范文和生性有关论文如何写.

数据和架构论文范文

摘要：自“数据+业务”的双中台架构被提出以来,中台间数据进行安全交互的效能显得尤为重要,基于此,本研究提出了一种高效的交互式协议,在借助区块链双链结构保证数据安全可信的情况下,改善了内生性数据在中台间交互效率低的问题,对新协议中核心的门限签名技术进行实验模拟的结果表明新协议在链下签名、链上验签过程中比传统单一链上签名及验签的方法节省了42.1%的时间成本,新协议对中台融合区块链技术、加快中台与区块链的广泛实践均具有积极推动作用.

关键词：双中台双链架构：高效数据交互协议：链下门限签名：链上验证签名：区块链

中图分类号：TP301 文献标志码：A DOI：10.3969/j,issn,1000-5641.202091014

0引言

传统的数据中台主要服务于数据的分层与属性分离,具有沉淀公共数据的能力,数据中台是通过数据技术对海量数据进行采集、计算、存储、加工,同时统一标准和口径的一种共享平台,其最早由阿里巴巴于2016年的研究报告中提出,目的是帮助实现全局数据规范,力图将技术平台开发的功能充分反哺到前端应用,阿里巴巴数据中台出现的缘由则是来源于其内部众多业务部门千变万化的数据需求和高速时效性的要求,既要满足多个业务前台的数据需求,同时还要应对大规模数据的线性可扩展问题以及复杂活动场景业务系统的解耦问题等,不过,数据中台的概念目前仍过于宽泛,业界亦无行业性标准,在国内科技公司竞相展开大中台规划的时候,阿里巴巴首席信息官张建锋近些年则在不同场合提出了业务中台的架构思想,所谓的业务中台是指所有应用系统都必须与之建立联系,以便更好地实现企业核心业务运行机制的一种整合型体系系统,张考虑使用业务中台与数据中台融合创新的新思路来进一步细化中臺职能,但是,数据中台和业务中台融合过程中存在的突出问题是数据交互的效能问题,在中台间多股业务流和数据流交互传输时,很难明晰出一条完整的业务与数据处理过程,内生性的业务信息与数据信息的杂糅,导致业务流的溯源、数据流的调度变得烦琐,数据交互的安全性也面临着一定的挑战,因此,如何确保在安全情况下提升中台间内生性数据交互效能以推动中台建设是亟待研究的问题.

针对上述问题,本研究使用区块链技术来对交互的数据进行拆分,区块链技术作为一种点对点的新兴计算机技术,可以在解决业务溯源困难、数据调度粗略问题方面提供可能途径,借助区块链技术特性,一方面赋能“数据+业务”的双中台系统在数据安全流转和数据安全存储方面的隐私保护;另一方面借助共识机制和经济模型,融合区块链生态的资源来对实际落地场景进行技术融合创新,区块链技术融于双中台,但并不会侵入相关中台业务,而是类似作为中台系统的底层技术进行赋能,避免了区块链技术直接对海量数据进行处理的低效率问题,利用区块链公开透明、难被篡改等优势,能够对已经处理过的有价值数据进行流转、存储及追溯,从而最终服务于数据交互效能的提升.

本研究根据中台中交互数据源的不同,将业务流信息和数据流信息放置于基于区块链的业务链和数据链上分别进行存储,进而提出了一种面向双中台双链架构的内生性数据交互协议,通过该协议,核心数据信息通过集合中台中一定数量的信息主体对上链数据信息进行授权,将合法信息批量传人指定区块链,同时,抽离协议中核心的门限签名算法构造内生性数据交互流转的模型,通过实验,分析算法在进行数据交互时的时间开销,并与传统的链上单一签名、验签进行比较,证实了该协议在改善数据交互效能上具有一定的优势.

1研究基础

1、1数据中台现状

不少学者为推动中台的发展做了相关的研究,概括而言,目前的数据中台的阶段模式可以分为以下三种.

第一种是阿里巴巴最初提出的数据中台,主要是为了在“大中台,小前台”的业务战略下进行数据化的实践,通过划分不同业务边界然后进行业务建模,进而指导系统的服务化建设,在延续阿里巴巴提出的数据中台战略思想的基础上,邓立君提出紧跟大数据时代的发展潮流,通过融合数据中台到大数据中心的建设中,实现对所有业务进行数据化处理,以充分发挥数据资产价值.

第二种是业务中台,根据业务需求的不同,划分不同业务边界然后进行业务建模,进而指导系统的服务化建设,对于业务中台的作用,宫志奇认为业务中台能够解决效率问题,同时也能降低业务创新成本,而赵冠东等学者则是考虑基于业务中台技术对全渠道运营支撑平台架构进行改良设计,主要包括运营活动、运营渠道管理以及监督预警,并研究了部署方式和面向电力营销的运营支撑平台的业务内容.

第三种是碎片化中台,在前两种数据中台的基础之上,根据业务或职能进行更细粒度的拆分,使得中台碎片化,以降低成本,进一步提高组织效率,在此类中台实践中,付威认为数据中台遵循高度集中化与可复用原则,可在中台基础上将服务组件快速封装起来,提供给前台便利使用,

传统数据中台功能过于集中化,而在真实的业务场景下,系统往往需要通过不同的业务服务来获取业务所需要的数据,这种方式即便考虑用分布式系统架构来实现传统的数据中台相关功能,技术上仍然存在缓存穿透、造成雪崩效应的问题,为解决这一痛点,通常的做法是进行数据治理,可以实现更高效地提升高并发业务场景下的计算和存储能力,但考虑到业务的需求分析会随着不同时间点动态变化,如果不能对新业务进行及时处理,也无法做到在技术上根据需求的特性进行持续功能迭代和技术更替,那么数据治理的效益将会大打折扣,因此“数据+业务”形式的双中台架构逐渐进入产业界中.

1、2“数据+业务”双中台

典型的“数据+业务”双中台架构将数据处理与业务服务按照逻辑顺序及处理对象属性进行并列设计,使得业务上的需求分析能够及时得到反馈,有助于缓解现有数据平台中单一数据中台业务冗余的技术痛点,达到有效进行数据治理的目的,同时业务中台的剥离,还有助于一部分业务信息能提前进行预处理,从而提升业务处理效能,具有普适性的“数据+业务”双中台架构如图1所示.

结合图5所示的算法流程图,首先,算法第一步是根据公式（1）生成密钥协商的多项式;其次,根据公式（2）构造出分片密钥d,通过匿名信道分发给业务主体或者数据主体,

在此基础上,给出业务记录或者数据信息的门限签名,并判断签名人数是否达到门限规定数量,如果没有,则授权失败,无法进行下面的操作;如果达到门限规定数量,就根据公式（4）-（6）计算一个聚合的签名sigM;接着就按照公式（7）交由合约验证,判断签名的合法性,如果不合法,业务记录或数据信息就会上链失败;如果合法,即调用加密函数encryted（等）进行业务记录或数据信息的加密上链操作,加密方式如下.

从上述形式化证明中可以看出,数据上链前经过了两輪质询,一是数据传输时签名人数的核验;二是聚合签名的核验,保证了数据的安全传输,而数据上链后是经过特定算法函数加密处理的,调用时只需要用对应的解密函数进行解密,就可以获得完整可信的数据明文信息.

3、2通用算法设计

本节将从算法层面介绍链上链下数据协同的过程,数据交互调用的伪代码如下,

Begin

Input：

callerId;//调用者ID

算法的第一步需要载人调用者的相关操作信息流;第二步需要验证聚合签名的有效性,判断聚合签名者的身份是否合法,以及聚合签名中签名人数是否达到指定标准,即判断有多少签名分片;第三步检查具体的操作内容,根据operationId分析具体的操作是业务操作还是数据操作,然后再分发到不同的链上合约进行处理;第四步是业务记录或数据信息的上链存储操作,通过智能合约添加新的内容到区块链上进行安全保存.

3、3内生性数据交互过程的仿真模拟

为了进一步说明内生性数据交互协议的可行性,抽离出协议中对提升内生性数据交互效能起关键作用的门限签名算法进行模拟仿真实验,以业务中台和业务链之间的交互为例,设定门限为6.进行签名的业务主体签名人数为13的方案,进行相应的编码测试,在此次测试中,主要硬件环境如下：英特尔双核i7处理器2.5 GHz、内存8 GB、Win10系统64位.

对于单次内生性数据交互,基于改进的协议签名编码测试结果如图6所示,

从图6中可以看出,消息m、聚合签名、模n后的聚合签名、消息摘要都是以大数形式展现的数字流,且根据前面的验签公式（7）不难看出,聚合签名e次幂模n后的签名数字流和消息摘要模n后的数字流内容一致,从而证实了图6中的验签过程合法有效.

虽然在图6中给出了加密消息m、聚合签名等签名、验签过程中的关键数据内容,但并未阐明这些数据与业务链之间的交互关系,图7给出在同样硬件环境中用开源智能合约开发环境Remix测试基于业务链的数据上传及下载的两个主要函数接口.

图7中,数据上传的主要函数接口为addMessage（）,需要由指定业务主体将对应授权之后的聚合签名的字节码值以及经过加密函数encrypted（等）处理后的加密消息m的字节码值传人该函数接口,然后在函数接口内部判断签名无误后,再把加密消息m的字节码值上传到业务链上指定区块中进行存储,等到需要下载时再通过另外的函数接口getMessage（）,输入需要查询的相应区块信息的映射编号,接着就可以获取之前上链存储的指定聚合签名以及链上待解密的消息m,最后再调用decrypted（等）函数对加密消息进行解密,即可获得相关的业务记录,此外,返回值中还可以获取先前指定业务主体的地址信息,方便业务中台内部跟踪数据源主体,以便进行有效监管.

为了证实协议应用的门限签名算法能够有效提升内生性数据交互的效能,本文分别设置了三组签名验签对照组,依次为链下签名及验签对照组、链上签名及验签对照组以及基于改进的协议签名、验签对照组,通过设定20次单体测试,对每组的签名、验证的开销进行了详细分析,每次测试的时间开销如表1所示,在此测试中,主要硬件环境如下：英特尔双核i7处理器2.5 GHz、内存8 GB、Winl0系统64位.

从表1中可以看到,在20次单体测试中,链下签名及验签实验对照组的签名和验签时间总体来说时间开销最短,但是因为如果内生性数据交互在链下签名、验签,则并未涉及区块链结构,那么在业务溯源、数据安全方面就没有很好的保障,也不具备实际应用价值,所以主要分析后面两个对照组的签名、验签方面时间开销的结果,链上签名及验签对照组将中台间内生性数据的签名、验签的过程全部交由区块链进行处理,虽然在业务溯源、数据安全方面有所保障,但是由于签名和验签时间普遍较长,因此相应地,数据交互处理的效能便会有所偏低,所以,综合来看,采用协议设计的签名方案,在链下签名后交由链上进行验签处理,就可在提升中台间数据交互效能的同时,借助区块链双链结构实现中台业务溯源、数据调度精准的目标,并且保障数据可信安全.

为了更直观地对比在使用区块链技术的前提下,协议中的门限签名方案与传统单一链上签名、验签方案的时间开销,分别计算20次单体测试中两种方案各自签名与验签总花费时间开销的平均值,给出如图8所示的柱形图,从图8中可看出链上签名及验签算法的签名和验签总时间开销平均为32067.9 ms,而基于改进的协议签名算法链上签名及链下验签算法的签名和验签总时间开销平均为18563.3 ms,相比之下,协议签名算法节省了近42.1%的时间成本.

综上,实验结果表明该协议算法在内生性数据交互过程中签名效率较高,验签效率相对较低,相对于传统单一链上签名、验签方式,协议在对内生性数据的交互处理上具有较高的效能,

4讨论

本研究从“数据+业务”的双中台架构设计出发,结合区块链双链技术,切入双中台数据上链到区块链中传输信道中内生性数据的交互效率问题,给出了一个高效交互的协议设计,主要的创新点如下.

（1）通过将区块链技术导人中台,提升了内生性数据的交互安全,保证了中台数据上链前的可信性,构建了一种改进的舒普门限内生性数据交互协议来保障数据在上链前的安全性.

（2）在上述工作的基础上设计了一个融合链下签名、链上验签的交互机制,提升了双中台双链的数据交互效率,实验结果表明,该机制降低了42.1%的时间开销,提升了中台与区块链两个体系间数据交互的效率.

当然,新协议仍然面临着以下挑战：首先,在技术层面上,还必须要融合其他技术,如大数据、人工智能等新技术,来持续优化中台技术结构,其次,在政策层面,要有国家对区块链技术的支持,鼓励实施优良技术标准和发布相关可信规范,在宏观调控上尽量避免技术作恶,最后,在业务层面上,需要继续细分业务结构,使得业务中台在提取数据中台相关信息时能更高效,从而增强业务处理能力.

5结论

本文提出了面向双中台双链架构的内生性数据交互协议,从算法公式推导上证实了协议的可实现性,针对中台与区块链两个体系间的数据协同给出了形式化验证,对协同的关键机制进行了实验模拟,结果表明该机制能够提升系统内生性数据间的交互效率,这种双中台双链体系架构下的新协议将会对“区块链+中台”的落地应用有一定的启示作用,当然,中台也仍然还是一个发展中的概念,中台在落地应用实践中还会不断产生新的问题与需求,这将是未来持续研究的方向.

总结：点评,本文是一篇关于生性方面的大学硕士和本科毕业论文范文,可作为数据和架构相关论文开题报告写作参考和职称论文写作文献资料.

生性引用文献: