精华内容
下载资源
问答
  • 2020-04-08 22:44:51

    这里说的单点登陆,不是正规的那种有个中间服务做的,(如CAS).差不多是一种假的单点登陆.

    但是在工作需求有时候会遇到, 尤其是做定制化产品. 一个客户买了我们公司一个产品, 同时买了另外一个公司的产品.现在想让这两个产品进行单点登陆,一般是这A系统需要打开到B系统做一些操作,或者调用B系统的一些接口等操作.基于开发成本,一般不会集成一个单点登陆中心.而是用两边的sessionId共享来解决.

    方案:

    1.在A系统需要调用B系统的界面时,先调用B系统的接口,把A系统中的当前用户信息传过去

    2.B系统接口获取到用户信息, 在B系统中进行登陆操作.(此处省去用户信息同步的逻辑,按需求开发)

    3.B系统完成登陆后,把该用户在B系统的sessionId.返回给A系统

    4.A系统接收到来自B系统的sessionId, 作为一个token,在缓存/内存中也存下来,例如用一个map结构. key:A系统中的sessionId, value:B系统返回的sessionId(token).

    5.随后A系统调用B系统的任何请求和界面,都带上token.

    6.B系统中则根据系统自身的认证拦截来调整逻辑,实现免登陆

    7.A系统用户登出时, 同时调用B系统. 作登出操作

    以上是大概的流程.具体代码后面再补充

     

     

    更多相关内容
  • 软件系统平台对接接口方案
  • 系统对接梳理

    千次阅读 2021-05-23 16:18:52
    1、含义 消除信息孤岛,利用资源(资源整合、业务间的合作),或者优化性能、安全性...尽管从不同角度有不同的划分,但是这些类型之间的划分是有关联的,他们的依赖关系通常如下: 6、通讯方式、通讯协议 无论..

    1、含义

    消除信息孤岛,利用资源(资源整合、业务间的合作),或者优化性能、安全性、稳定性,产生价值(不一定更高,也可能亏)

    2、按系统类型

    同类系统、异构系统

    3、按通讯类型

    通讯协议划分、通讯方式划分

    4、按架构类型

    应用系统间、应用系统与中间件、中间件与中间件、应用系统与操作系统、中间件与操作系统

    5、按用途

    IT优化、业务需求、合规监管、新旧改造

    尽管从不同角度有不同的划分,但是这些类型之间的划分是有关联的,他们的依赖关系通常如下:

    6、通讯方式、通讯协议

    无论何种系统间的对接,都存在通讯,经过通讯才能将信息共享,将通知送达。采用哪种方式跟系统所处的领域有关,tcp/ip目前广泛应用于互联网领域,而嵌入式和移动领域,更多是根据硬件标准协议,如蓝牙、NFC等等。对于互联网领域,基本上是基于TCP传输协议,在此基础上有着各种应用层协议,如RPC、HTTP是目前两大主流的协议。

    RPC

    PRC协议即为远程过程调用,其通讯过程对于两边是透明的,不同的开发语言和系统需要定制他们的PRC协议,如JAVA的RMI,webservice,dubbo的tcp内部传输协议,这些协议根据自身需求将请求和响应的数据封装,那么业务代码就可以像调用某个本地方法那样调用对方的方法,从而达到简化对接的目的,由于是定制的,通常是为了满足内部通讯、高效、安全等特性,但是这些协议欠缺灵活性,甚至有的是很重量的,都没有一个统一的标准,有的是自家对tcp的封装,有的是基于http协议实现的,所以一直都没法通用。

    HTTP

    http协议即为超文本传输协议,早期出身于web,协议本身比较臃肿,因为不像rpc协议那样对通讯过程做了封装和精确设计,所以有很多不得不实现的公约,还需要系统对报文做解析等处理。其实这个时期http协议也没有一个统一的解析规范,但是后来随着xml,json这些文本序列化协议流行并形成了统一之后,使用这些文本协议的报文变得简洁和通用,http协议经过精简,逐步成为大多数公司内部统一协议,因其学习和维护成本低,前后端统一技术栈提高了开发和沟通效率,但不少老系统仍然需要RPC,因为这个东西改造很麻烦的,另一个可能是极端的性能要求。

    连通性

    再简单的分布式系统,每个集群的服务器数量都应当不少于3台,不同集群不大可能都处于相同的网段内,因此,系统对接的底层实际是物理上的连接,如果应用层已经开发完毕,但是物理连接却是不通的,这就十分尴尬了。轻量级的应用群通常不会有太复杂的拓扑,测试环境和生产环境只需要简单的验墙即可(服务器防火墙),而大量级的应用群,拓扑是非常庞大的,通常我们会有一套隔离系统来负责各个应用群之间的转发和隔离,确保安全性以及实现高效管理,另外还需要一套负载均衡的系统来分发请求,也就是有两道墙(网关),一个是隔离网关,一个是微服务网关(通常用nginx),通常情况下,处于同一个微服务的内部系统,走通nginx即可,而处于不同应用群的系统想要对接,由外到内需要先通过隔离网关,再通过nginx集群,外部系统还需先经过网关防火墙。

    对于非分布式的系统对接,那就比较随缘了。

    7、同类系统、异构系统

    同类系统对接难度系数通常最小,因为无需考虑异构差异,在这个层面更关注的是原本功能以及业务上的差异,功能实现的划分职能问题。而且怎么定义为同类系统,其实与异构的划分界限是模糊的,即使采用相同的开发语言,实现架构也可能存在很大的差异,所以这里所谓的同类是指采用相同的开发语言和架构类似的系统。在这种背景下,双方可以有机会根据需求和生存周期做一个统筹,针对对接的部分指定统一处理的规范,对双方都有利。

    异构系统间的对接,要考虑性能、兼容性等方面的问题,虽然有RPC和http协议可以作为统一标准通讯,但是系统其本身的工作原理差异需要双方去协调,最典型的例子就是业务系统和中间件系统的对接,如redis、MQ等中间件,调用方(业务系统)需要根据中间件运作规则,对调用这些中间件的方法进行封装,以达到简化的目的。另一个很典型的例子就是应用系统间的对接,涉及的数据结构差异和业务状态更改与同步,都是非常复杂多样的问题。

    但是多样化是互联网的特性,绝大部分系统间都是异构的,在搭建系统考虑对接扩展时,应当以异构为背景去分析和考量,使系统具有更好的扩展和兼容性。

    8、应用系统间

    目前最常见的系统对接应该是应用系统间的对接了,应用系统通常指实现某一领域业务功能的系统,在微服务架构下,如银行APP账户管理的后端模块通常对应的是一个名为acct的应用,在这个应用下有划分为许多个子服务,如query查询、tran转账、auth鉴权、whithhold代扣等等,另外还有许多支撑应用,如会员认证系统、大数据ETL、风险侦测等等,而在银行APP外部,有各类商户的开户渠道、购物平台的支付渠道,还有许多第三方机构如公安部联网核查、生物特征平台、人脸认证等等,与之关联。所以这些系统相对应的,又可分为内部系统对接和外部系统对接。

    应用系统间的对接关键点:接口文档、测试报告、上线计划、投产验证、降级方案

    8.1、内部系统间

    在一些小型的企业小型的微服务架构,内部形成统一的对接规范是相对简单的,但是那些大型应用的后台微服务,众多的内部系统,往往也会形成诸侯割据的局面,有着形形色色的接口规则,形成统一的规范非常困难。

    授权

    授权方式有的是分配秘钥,有的则是简单的核对访问标识,有的是利用接口管理平台进行注册和投产,内部系统如果都处于dubbo这类分布式结构内,通常是简单的核对访问标识(如应用ID,组件ID)即可,而架构外的通常需要专门的中转对接平台负责注册投产,当然这是服务达到较大的量级就需要这么做。

    字段差异

    你可以想象,如accountNo账户号这一字段,根据对方接口定义修改为acctNo、acctNumber、accId诸如此类的命名,维护成本是X3甚至更多的,甚至自身系统不同接口也有不一致的定义。出现这种情况,其原因往往在于项目开荒阶段,对后续发展评估不足,或者预算是短期的,认为项目是不稳定的,甚至根本没有内部系统对接这部分的统筹,后续项目业务扩展翻了好几番,系统的量级也翻了几倍十几倍,盘子大了,再也没有任何人能全局的把控。但是,在国内这种现象是再常见不过了,本质上,是根本不会给你足够的时间去维持一些规范,因为普遍的观念认为,与其去维护这些东西,不如重开一个项目,然后再重复循环着。另一方面,也确实不缺人,只要有人接手,再乱也能玩下去。这就有点像印度没有形成统一的市场经济体系一样,每个省份每个地区都要收税,极大的制约的经济的发展。

    数据结构差异

    一些上古系统,为了节省开支(当时或许还没出现json,以及对性能影响),传输的时候喜欢使用字符分隔符,如“id|12|name|tomcat|”,而现在流行文本序列化规范是使用json字符串,而一些重量系统,接口报文定义也很重量(规范),字段的定义嵌套好几层,精细到长度、类型,甚至还有自创的数据类型......等等,所以对接会产生额外的转换成本,但是数据结构层面的相对容易解决,也不属于公共组件范围,风险较小,换而言之,各种差异问题,有可能最开始只是局部的规范性问题,当将它提升到公共处理场景,就有可能是是一个很大的风险隐患,对维护和扩展是否不利需三思。

    通讯协议差异

    如dubbo、springcloud这类微服务框架下的子系统,都可以使用自身统一的通讯协议,但是因为诸多应用网络、硬件拓扑结构的差异,对接的协议往往不止一种,通常我们需要构建一个专门用于对接的这些第三方协议的应用或组件(如接口映射平台、隔离网关等)来承担这些任务,将差异化屏蔽掉,并且实现对一些数据结构的校验和授权,但是实际会有更恶心的情况下,就如某HTTP接口,其认证方式被定义在header中某个标签,公共组件就无法做特殊处理了,这些接口通常来自一些遗留系统、或者边缘系统。

    同步调用

    这是最常见的处理方式,因为大多数业务场景或者功能功能依赖都是有序的,没人愿意将其打乱给自己增加难度。采用这种方式在逻辑设计和实现阶段都能很好的和业务对应上,通常一个流程图加几个接口文档就搞定了,关键的问题在于应对意外发生。

    容错其实是一项平衡工作,在微服务架构中,一个业务流程涉及的接口超过10个是正常的,没人能保证所有接口的正常,出现的意外通常是接口没有响应、返回的信息错误、网络抖动繁忙等等,因此建立超时机制、熔断是非常有必要的,在业务上主要体现在降级处理,保证关键业务流程的正常,就是我们常说的弃卒保帅。

    异步调用

    事实上,客户所认知的业务办理都是即时的,即使处理时间较长,那就等待处理结束,但是没有客户愿意中途转向的处理其他操作,这足以说明对于客户来说有序的操作才是简洁之道,复杂度高的流程没人愿意接受。

    但是在接口层面这样的长时间等待是系统无法接受的,即便是业务流程上等待时间也有个限度,例如开通支付的人脸扫描、证件照的核对都是敏感度高的操作,如果接口是高耗时的类型,也应当支持异步返回,我们只能提前发起接口的调用,在最后客户的操作阶段再反查结果,在这期间客户可以完成其他操作。

    也有一些情况下会使用到单次请求的异步,也就是一个业务请求中,后台的处理利用像java的future这样的线程池做异步,而实际上很少这么做,通常整个业务流程响应的时间限制也就5-6秒,后端在等待接口返回期间能做的处理很少,应该说,通常是无事可做,所以收益甚微,如果说这期间还有其他接口或者耗时操作,这的确能提高不少响应,但是这种设计风险可能会比较大,建议在业务层面上进行分步,而不是所有规则都在后端发生。不过一些保守的团队,他们可能会考虑,这样可以减少那些hold住复用线程的风险。

    8.2、外部系统

    对于外部系统,通常情况下已经不再涉及微服务架构、公共组件的范畴了,而且为了方便外部对接,争取更多的合作,现在的外部系统开放接口设计也是向着轻量化发展的,json数据交换格式已经是业内规范,当然也有比较落伍的接口,暂时没遇到过。对接外部系统,关键点在于API的设计,需要考虑暴露敏感字段、防越权操作、防遍历、注入等问题。当然,这些API设计原则对于内部系统参考也同样适用。外部接口频繁更改,对使用方非常不友好,但有时候就是会遇到一些“领导条线”项目,对方频繁修改,你也只能跟着改,这就比较锻炼心智了。

    9、应用系统与中间件

    其实这种类型还好,毕竟中间件大多都是规范的成品,不会像外部接口那样各种不确定性。这中类型的对接往往更加考验对中间件客户端的封装水准。例如redis就有几种客户端开发包,按需选用。

    在大型结构系统,中间件一般也是独立的机器,网络连接就肯定要涉及连接池了。有的客户端是基于连接池的,也就是内置了连接池,有的只提供池但不提供连接,也就是多线程连接是不安全的,需要我们自己处理并发问题,有的是原生单连接的,连池都需要我们去封装。再一个就是连接的释放和关闭,得结合实际处理。

    中间件似乎与高可用脱离不了关系,有流传的一句话,业务可以重启,中间件不能挂。还好我们有集群,而连接转移的问题就来了,例如redis主从模式下,master挂了,我们如何连接到新的机器上,这也需要客户端和中间件的支持,例如redis有哨兵模式,可以通知应用调用新的机器。

    展开全文
  • 商广告平台与媒体广告平台之间对接标准,避免多种不同接口带来集成代价和效率上的 浪费。以提升媒体收益能力管理的效率,增强库存控制权;有利于广告主及代理商使用统 一标准对接多个优质媒体池,获得有保证的...
  • 应用系统之间的几种数据传输方式
  • 系统对接的实现方案

    千次阅读 2021-07-19 03:35:45
    也出现了向钉钉、企业微信、飞书等分发的微应用,多个系统的同时出现发挥了不同的优势,可是系统平台越多也意味着"信息孤岛"越严重,数据中台和异构系统集成的出现就是为了解决信息孤岛,把多样化的系统整合到一起,...

    随着信息化的发展,以及互联网、万物互联的逐渐普及和大数据时代的来临,数据资产已经成为企业的战略武器,越来越多的企事业单位不断上线了各种软件系统,另外随着移动互联网的发展,又出现了移动端多端应用,既出现了手机、PDA、Pad、移动智慧大屏等多类硬件设备,也出现了向钉钉、企业微信、飞书等分发的微应用,多个系统的同时出现发挥了不同的优势,可是系统平台越多也意味着"信息孤岛"越严重,数据中台和异构系统集成的出现就是为了解决信息孤岛,把多样化的系统整合到一起,让数据一体化、标准化,让所有系统能够贯通,这样既减少了重复的工作量,又大大提高了数据的共享能力,实现了数据资产的高度治理。

    未来企业会不断走向多元化的发展,从生产经营提升到生产服务一体化运营,从单一产品供应提升为总体方案的建设,从局部服务提升为全方位整合。企业应用的信息化系统也越来越多,截至目前没有任何一套软件能够解决企业的所有的问题,每款系统平台都有他的特性,在管理的某些方面,发挥着比其他产品更加优秀的作用。

    未来是一个大融合的时代,大数据时代的信息化建设将单一的系统建设向多系统应用发展,产业互联网的时代将从企业内控管理的内循环会提升为产业协同的外循环异构系统的数据集成是把不同来源、格式、特点性质的数据在逻辑上或物理上有机地集中采集进来,进行规则的映射,再分发到不同的系统,从而为企业提供全面的数据共享

    比如下图的场景中可以将SAP强大的企业资源管理和OA强大的审批流程结合起来,实现ERP业务数据流程的严谨管控的同时可以实现合同、付款等重要节点的评审会签和流程审批,同时也可以将采购端、销售端供销商的自主下单和订单跟踪,物流跟进、款项发票对账分发到钉钉、企业微信、公众号、小程序等多端应用中去。甚至针对一些电商的用户,可以将电商系统和企业内部ERP集成起来形成业务闭环,把企业生产出来的商品即时发布到电商平台,把电商平台的订单、发货、收款数据再取回来,在ERP形成了线上业务数据和线下B端批发业务数据的整合,打通了企业的外循环。

    要实现企事业单位异构系统的集成也不是一件简简单单的小事,企业普遍的做法是找自己的软件服务商去二次开发,最终会发现A软件厂商说我的接口没问题对方系统有问题,或者是双方的系统都会出现二次开发的可能,每个软件供应商尽可能要保障自己系统的稳定、流程顺畅,把一些疑难问题跑给对方软件公司,有很多客户方也不具备全面的整合能力,其实是甲乙双方打比赛缺少了裁判和评委。数据中台的出现就是要把各方系统中不一致、不标准的数据规范统一标准化,不能标准化的通过抽取双方系统的主数据及相关枚举列表数据做映射关系实现标准化,同时分发给各个系统的数据结构经加工后保证符合对方系统接收的要求。

    那么如何实现数据中台多系统的集成呢?我们长期的研发和客户案例中总结出来有以下几种思路可供参考:

    1. 通过BusData企业数据总线实现数据集成  

    BusData数据总线集成是通过在数据中台中间件上统一进行规则制定、采集抽取、映射转换、管道调度和定向分发,它是一个中心辐射型的星型结构或总线结构,因此把它成为BusData数据总线。采用总线架构可以明显减少编写的专用集成代码量,提升了集成接口的可维护性和可管理性。不同连接对象如果连接方式有差异,可以通过总线完全屏蔽掉,做到对连接对象透明,无需各个连接对象关心。通过总线结构,把原来复杂的网状结构变成简单的星形结构,极大提高了硬件的可靠性和可用性。

    BusData数据总线集成可分为:EDI-电子数据交换ESB-企业服务总线

    EDI是按照国际标准消息格式发送信息,接收方也需要按国际统一规范的语法规则,对消息进行处理,并引起其他相关系统的EDI综合治理。标准化的EDI数据交换保证了不同国家、地区、企业的各种商业文件(如单证、回执、载货清单、验收通知、出口许可证、原产地证等)的无障碍电子化交换,促进了国际贸易和交互的发展。

    ESB企业服务总线的使用标志着数据治理的应用集成进入了SOA面向服务集成的时代。其主要特征是基于一系列Web标准或规范来开发接口程序,包括UDDI、SOAP、WSDL、XML、Json,并采用支持这些规范的中间件产品作为集成平台,从而实现了一种开放而富有弹性的应用集成方式。ESB是对web服务(WebService和Web )的注册、调度和管理,WebService/WebAPI是一种跨编程语言、跨操作系统平台的远程调用技术,是web的一种标准。它向外界暴露了一个能通过Web调用的API接口。各个软件的接口说明文件规定本系统有什么服务可以对外调用和回调,提供了什么服务,本服务中有哪些方法,方法入参是什么,返回值是什么,服务的相关参数及调用方式等等。

    2. 通过点对点现实现数据集成  

            点对点数据集成的情况常见于2个系统之间的集成,主要场景有端到端(内网部署的两套系统,C/S系统之间的通信等)、端到云(一端部署在企业内部、另一套软件在云端)、云到云(两套系统均在云端)。有些客户会找2套软件中的一家软件供应商去做二次开发,这种方式软件开发方一般采用在原有系统中做接口获取对方数据或者发送给对方系统数据,这种方式应对2个系统对接也许可以,但是难以应对多个系统复杂的数据流向,同时如果任意乙方系统升级、更换其他系列产品等情况发生后,可能导致对接工作需要重新开展。

    因此我们看出点对点的集成架构不能集中管理和监控接口服务,仅支持一对一的数据交换,如果交换协议不一致,开发则变得困难,另外这种集成是紧耦合的,当一个对双方系统紧密关联的接口变化时,所有与其相关的接口程序都需要重新调试或开发,从企业长期信息化规划发展来看,这种方式反而成本会比较高,可用性和可维护性差。

    3. 批量数据集成

    离线批量数据集成,一般是基于ETL工具的离线数据集成,ETL即数据的提取(Extract)、转换(Transform)和加载(Load),。

    ETL常用的实现有有三种:ETL工具抽取、数据库同步(数据实时单向同步或双向同步)、ETL和SQL混合同步。

    ETL工具抽取,常用到的工具有Talend、DataX、Kettle、Informatic等,借助ETL工具快速建立数据抽取规则定制、调度任务机制,省去了复杂的编程工作,提高了数据治理的效率。

    数据库同步是借用数据库自带的同步、订阅、分发的功能进行,但前提是源数据库表和目标系统数据库表结构和字段属性需要保持基本一致,它一般应用与分布式数据库系统,有中央数据库和各终端对称数据库的场景下,对不同的两个系统来说,要保证数据结构的一致性,这种可能性很小,还得搭建中间库,两个系统还得做一些开发才能实现异构系统的集成,另外有很多云端Saas版的系统以及对安全性要求很高的系统不可能开放数据库供对方系统调用。

    ETL和SQL混合同步综合了前面二种的优点,会极大地提高ETL的部署速度和效率。 

    4.流数据集成

    流数据集成也叫流式数据实时数据采集,通常是采用Kafka、Kinesis、Flume等流式数据处理工具对NoSQL非关系型数据库进行实时监控和复制,根据应用场景做相应的处理(去重、去噪、预处理运算),之后再写入到对应的数据存储中。

    以Kafka为例,它能够通过KafkaConnectAPI实现流数据管道的构建。ConnectAPI利用了Kafka的可扩展性,kafkaconnect是围绕kafka构建的一个可伸缩,可靠的数据流通道,通过kafkaconnect可以快速实现大量数据进出kafka从而和其他源数据源或者目标数据源进行交互构造一个低延时的数据通道。它可通过KafkaStreamsAPI实现数据转换,它用于在Kafka上构建高可分布式、拓展性,容错的应用程序。它建立在流处理的一系列重要功能基础之上,比如正确区分事件事件和处理时间,处理迟到数据以及高效的应用程序状态管理。KafkaStreams包含了ConsumerAPI和ProducerAPI的功能,增强了对数据流的处理能力。使用Kafka作为流处理平台能够消除为每个目标sink、数据存储或系统创建定制化(很可能是重复的)抽取、转换和加载组件的需求。来自数据源的数据经过抽取后可以作为结构化的事件放到平台中,然后可以通过流处理进行数据的转换。

    5.爬虫数据采集

    爬虫数据采集是通过网络爬虫或网站公开API等方式从网站上获取数据信息的过程,它一种按照一定的规则,自动地抓取互联网信息的程序或者脚本,一般分为通用网络爬虫和聚焦网络爬虫两种。网页爬虫从一个或若干初始网页的URL开始,获得初始网页上的URL,在抓取网页的过程中,不断从当前页面上抽取新的URL放入队列,直到满足系统的一定停止条件。聚焦爬虫的工作流程较为复杂,需要根据一定的网页分析算法过滤与主题无关的链接,保留有用的链接并将其放入等待抓取的URL队列。常见的网络网页爬虫有Octoparse、WebCopy、HTTrack、Getleft、Scraper等,支持文本文件、图片、音频、视频等非结构化数据、半结构化数据从网页中提取出来,存储在本地的存储系统中。

    1624643963330040.png

    文章来源:http://www.zipyun.cn/vip_doc/20951444.html

    展开全文
  • IT系统对接方案汇总

    千次阅读 2021-02-07 09:28:46
    如果系统之间存在权限限制或技术限制,可采用接口以保证数据的安全和对接的规范性等等,不同的场景下有不同对接方案,以下对常用的对接方案做出汇总。 技术方案 接口 接口对接方式是比较常用,且安全规范的传输...

    目录

    概述

    技术方案

    接口

    消息服务传输

    文件共享

    socket传输

    数据库传输

    数据爬取


    概述

    IT系统对接是很多企业、项目必须面对的问题;通常,多个系统之间如果完全企业自主定制开发,且有源代码、服务器的所有权,可以选择数据库直传的方式,方便快捷。如果系统之间存在权限限制或技术限制,可采用接口以保证数据的安全和对接的规范性等等,不同的场景下有不同的对接方案,以下对常用的对接方案做出汇总。

    技术方案

    接口

    接口对接方式是比较常用,且安全规范的传输方式,一般需要根据详细需求开发定制接口,以满足系统间信息的对接。
    一、传统WebService与Restful
    接口一般可分为两种方式实现,一是传统web service接口,二是restful 风格的web service接口,二者区别主要由以下几点:
    1. Restful Web Service的开发是面向资源的,而WebService则是面向方法。
    2. Restful Web Service以Http协议作为应用协议,对资源的操作基于Http协议的几个关键方法“Get,Post,Put,Delete(204),Head,Patch,Options”,而Web Service则将方法信息封装在SOAP信封里经由Http的Post方法发送给服务端。这一区别的结果就是Restful Web Service利于缓冲(符合Web方式,利于GET缓冲),而Web Service在缓冲方面则表现出了极大的短板,因为缓冲服务器根本不知道SOAP里边的方法是不是Get,以及真实的请求资源是什么。
    3.有关安全控制方面,对于基于代理服务器实现的安全控制,一般代理服务器是根据URL以及请求方法来确定该用户是否拥有相关操作权限的,很明显Restful Web Service贴近Web方式满足要求,而基于SOAP的Web Service实际的方法信息无从知晓,不具备实现安全控制的条件。
    总结:WebService比较成熟,在涉及到复杂的业务逻辑,事务例如转账,用户等级划分等业务逻辑的处理上要优于Restful Service。而Restful Web Service由于是无状态的,在构建分布式应用的时候不用考虑用户Session,所以在构建分布式应用时灵活度更高,但在涉及到授权方面则略逊于前者(借助OAuth实现授权)。此外由于Restful Web Service以Http为应用协议其资源状态的转变方法有限(Http的七种方法),如果需要其他的方法只能借助已经实现方法扩展的第三方框架实现复杂操作而Web Service则可以定义自己的方法。总体来看Restful Web Service更易于构建简单的基于资源的分布式应用,而Web Service则适用于业务逻辑复杂,对系统安全性要求更高的大型企业级应用构建。

    二、接口设计-共通

    如果采用SOA体系架构,通过服务总线技术实现数据交换以及实现各业务子系统间、外部业务系统之间的信息共享和集成,因此SOA体系标准可作为采用的接口核心标准。主要包括:
    服务目录标准
    服务目录API接口格式参考国家以及关于服务目录的元数据指导规范,对于W3C UDDI v2 API结构规范,采取UDDI v2 的API的模型,定义UDDI的查询和发布服务接口,定制基于Java和SOAP的访问接口。除了基于SOAP1.2的Web Service接口方式,对于基于消息的接口采用JMS或者MQ的方式。
    交换标准
    基于服务的交换,采用HTTP/HTTPS作为传输协议,而其消息体存放基于SOAP1.2协议的SOAP消息格式。SOAP的消息体包括服务数据以及服务操作,服务数据和服务操作采用WSDL进行描述。
    Web服务标准
    用WSDL描述业务服务,将WSDL发布到UDDI用以设计/创建服务,SOAP/HTTP服务遵循WS-I Basic Profile 1.0,利用J2EE Session EJBs 实现新的业务服务,根据需求提供SOAP/HTTP or JMS and RMI/IIOP接口。
    业务流程标准
    使用没有扩展的标准的BPEL4WS,对于业务流程以SOAP服务形式进行访问,业务流程之间的调用通过SOAP。
    数据交换安全
    与外部系统对接需考虑外部访问的安全性,通过IP白名单、SSL认证等方式保证集成互访的合法性与安全性。
    数据交换标准
    制定适合双方系统统一的数据交换数据标准,支持对增量的数据自动进行数据同步,避免人工重复录入的工作。
    2.1接口规范性设计
    系统平台中的接口众多,依赖关系复杂,通过接口交换的数据与接口调用必须遵循统一的接口模型进行设计。接口模型除了遵循工程统一的数据标准和接口规范标准,实现接口规范定义的功能外,需要从数据管理、完整性管理、接口安全、接口的访问效率、性能以及可扩展性多个方面设计接口规格。

    1)接口定义约定

    客户端与系统平台以及系统平台间的接口消息协议,本次以基于HTTP协议的REST风格接口实现为例,如下图-接口消息协议栈示意图:

    系统在http协议中传输的应用数据采用具有自解释、自包含特征的JSON数据格式,通过配置数据对象的序列化和反序列化的实现组件来实现通信数据包的编码和解码。

    在接口协议中,包含接口的版本信息,通过协议版本约束服务功能规范,支持服务平台间接口协作的升级和扩展。一个服务提供者可通过版本区别同时支持多个版本的客户端,从而使得组件服务的提供者和使用者根据实际的需要,独立演进,降低系统升级的复杂度,保证系统具备灵活的扩展和持续演进的能力。

    2)业务消息约定

    请求消息URI中的参数采用UTF-8编码并经过URLEncode编码。

    请求接口URL格式:{http|https}://{host}:{port}/

    {app name}/{business component name}/{action} ;其中:

    协议:HTTP REST形式接口

    host:应用支撑平台交互通信服务的IP地址或域名

    port:应用支撑平台交互通信服务的端口

    app name:应用支撑平台交互通信服务部署的应用名称

    business component name:业务组件名称

    action:业务操作请求的接口名称,接口名字可配置

    应答的消息体采用JSON数据格式编码,字符编码采用UTF-8。

    应答消息根节点为“response”,每个响应包含固定的两个属性节点:“status”和“message”。它们分别表示操作的返回值和返回消息描述,其他的同级子节点为业务返回对象属性,根据业务类型的不同,有不同的属性名称。

    当客户端支持数据压缩传输时,需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip),如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回,Content-Length为压缩后的数据长度。详细参见HTTP/1.1 RFC2616。

    应答消息根节点为“response”,每个响应包含固定的两个属性节点:“status”和“message”。它们分别表示操作的返回值和返回消息描述,其他的同级子节点为业务返回对象属性,根据业务类型的不同,有不同的属性名称。

    当客户端支持数据压缩传输时,需要在请求的消息头的“Accept-Encoding”字段中指定压缩方式(gzip),如消息可以被压缩传输则平台将应答的数据报文进行压缩作为应答数据返回,Content-Length为压缩后的数据长度。详细参见HTTP/1.1 RFC2616。

    3)响应码规则约定

    响应结果码在响应消息的“status”属性中,相应的解释信息在响应消息的“message”属性中。解释消息为终端用户可读的消息,终端应用不需要解析可直接呈现给最终用户。响应结果码为6位数字串。根据响应类型,包括以下几类响应码。如下表中的定义。

    响应码

    描述

    0

    成功

    1XXXXX

    系统错误

    2XXXXX

    输入参数不合法错误

    3XXXXX

    应用级返回码,定义应用级的异常返回。

    4XXXXX

    正常的应用级返回码,定义特定场景的应用级返回说明。

    4)数据管理

    ①业务数据检查

    接口应提供业务数据检查功能,即对接收的数据进行合法性检查,对非法数据和错误数据则拒绝接收,以防止外来数据非法入侵,减轻应用支撑平台系统主机处理负荷。

    对于接口,其业务数据检查的主要内容有以下几个方面:

    •数据格式的合法性:如接收到非预期格式的数据。包括接收的数据长度,类型,开始结束标志等。

    •数据来源的合法性:如接收到非授权接口的数据。

    •业务类型的合法性:如接收到接口指定业务类型外的接入请求。

    对于业务数据检查中解析出非法数据应提供以下几种处理方式:

    •事件报警:在出现异常情况时自动报警,以便系统管理员及时进行处理。

    •分析原因:在出现异常情况时,可自动分析其出错原因。如是数据来源非法和业务类型非法,本地记录并做后续管理,如是数据格式非法,分析网络传输原因或对端数据处理原因,并做相应处理。

    •统计分析:定期对所有的非法记录做统计分析,分析非法数据的各种来源是否具有恶意,并做相应处理。

    ②数据压缩/解压

    接口根据具体的需求应提供数据压缩/解压功能,以减轻网络传输压力,提高传输效率,从而使整个系统能够快速响应并发请求,高效率运行。

    在使用数据压缩/解压功能时,应具体分析每一类业务的传输过程、处理过程、传输的网络介质、处理的主机系统和该类业务的并发量、峰值及对于所有业务的比例关系等,从而确定该类业务是否需要压缩/解压处理。对于传输文件的业务,必须压缩后传输,以减轻网络压力,提高传输速度。

    在接口中所使用的压缩工具必须基于通用无损压缩技术,压缩算法的模型和编码必须符合标准且高效,压缩算法的工具函数必须是面向流的函数,并且提供校验检查功能。

    5)完整性管理

    根据业务处理和接口服务的特点,应用系统的业务主要为实时请求业务和批量传输业务。两类业务的特点分别如下:

    1.实时请求业务:

    (1)采用基于事务处理机制实现

    (2)业务传输以数据包的方式进行

    (3)对传输和处理的实时性要求很高

    (4)对数据的一致性和完整性有很高的要求

    (5)应保证高效地处理大量并发的请求

    2.批量传输业务:

    (1)业务传输主要是数据文件的形式

    (2)业务接收点可并发处理大量传输,可适应高峰期的传输和处理

    (3)要求传输的可靠性高

    根据上述特点,完整性管理对于实时交易业务,要保证交易的完整性;对于批量传输业务,要保证数据传输的完整性。

    2.2接口双方责任

    1)消息发送方
    遵循本接口规范中规定的验证规则,对接口数据提供相关的验证功能,保证数据的完整性、准确性;
    消息发起的平台支持超时重发机制,重发次数和重发间隔可配置。
    提供接口元数据信息,包括接口数据结构、实体间依赖关系、计算关系、关联关系及接口数据传输过程中的各类管理规则等信息;
    提供对敏感数据的加密功能;
    及时解决接口数据提供过程中数据提供方一侧出现的问题;
    2)消息响应方
    遵循本接口规范中规定的验证规则,对接收的数据进行验证,保证数据的完整性、准确性。
    及时按照消息发送方提供的变更说明进行本系统的相关改造。
    及时响应并解决接口数据接收过程中出现的问题。
    3)异常处理
    对接口流程调用过程中发生的异常情况,如流程异常、数据异常、会话传输异常、重发异常等,进行相应的异常处理,包括:
    ·对产生异常的记录生成异常记录文件。
    ·针对可以回收处理的异常记录,进行自动或者人工的回收处理。
    ·记录有关异常事件的日志,包含异常类别、发生时间、异常描述等信息。
    ·当接口调用异常时,根据预先配置的规则进行相关异常处理,并进行自动告警。

    2.3接口可扩展性规划与设计

    各个系统间的通信接口版本信息限定了各个系统平台间交互的数据协议类型、特定版本发布的系统接口功能特征、特定功能的访问参数等接口规格。通过接口协议的版本划分,为客户端升级、其他被集成系统的升级、以及系统的部署提供了较高的自由度和灵活性。

    系统可根据接口请求中包含的接口协议版本实现对接口的向下兼容。系统平台可根据系统的集群策略,按协议版本分别部署,也可多版本并存部署。由于系统平台可同时支持多版本的外部系统及客户端应用访问系统,特别是新版本客户端发布时,不要求用户强制升级,也可降低强制升级安装包发布的几率。从而支持系统的客户端与系统平台分离的持续演进。

    2.4接口安全性设计

    为了保证系统平台的安全运行,各种集成的外部系统都应该保证其接入的安全性。

    接口的安全是平台系统安全的一个重要组成部分。保证接口的自身安全,通过接口实现技术上的安全控制,做到对安全事件的“可知、可控、可预测”,是实现系统安全的一个重要基础。

    根据接口连接特点与业务特色,制定专门的安全技术实施策略,保证接口的数据传输和数据处理的安全性。

    系统应在接口的接入点的网络边界实施接口安全控制。

    接口的安全控制在逻辑上包括:安全评估、访问控制、入侵检测、口令认证、安全审计、防(毒)恶意代码、加密等内容。

    1)安全评估

    安全管理人员利用网络扫描器定期(每周)/不定期(当发现新的安全漏洞时)地进行接口的漏洞扫描与风险评估。扫描对象包括接口通信服务器本身以及与之关联的交换机、防火墙等,要求通过扫描器的扫描和评估,发现能被入侵者利用的网络漏洞,并给出检测到漏洞的全面信息,包括位置、详细描述和建议改进方案,以便及时完善安全策略,降低安全风险。

    安全管理人员利用系统扫描器对接口通信服务器操作系统定期(每周)/不定期(当发现新的安全漏洞时)地进行安全漏洞扫描和风险评估。在接口通信服务器操作系统上,通过依附于服务器上的扫描器代理侦测服务器内部的漏洞,包括缺少安全补丁、词典中可猜中的口令、不适当的用户权限、不正确的系统登录权限、操作系统内部是否有黑客程序驻留,安全服务配置等。系统扫描器的应用除了实现操作系统级的安全扫描和风险评估之外还需要实现文件基线控制。

    接口的配置文件包括接口服务间相互协调作业的配置文件、系统平台与接口对端系统之间协调作业的配置文件,对接口服务应用的配置文件进行严格控制,并且配置文件中不应出现口令明文,对系统权限配置限制到能满足要求的最小权限,关键配置文件加密保存。为了防止对配置文件的非法修改或删除,要求对配置文件进行文件级的基线控制。

    2)访问控制

    访问控制主要通过防火墙控制接口对端系统与应用支撑平台之间的相互访问,避免系统间非正常访问,保证接口交互信息的可用性、完整性和保密性。访问控制除了保证接口本身的安全之外,还进一步保证应用支撑平台的安全。

    为了有效抵御威胁,应采用异构的双防火墙结构,提高对防火墙安全访问控制机制的破坏难度。双防火墙在选型上采用异构方式,即采用不同生产厂家不同品牌的完全异构防火墙。同时,双防火墙中的至少一个应具有与实时入侵检测系统可进行互动的能力。当发生攻击事件或不正当访问时,实时入侵检测系统检测到相关信息,及时通知防火墙,防火墙能够自动进行动态配置,在定义的时间段内自动阻断源地址的正常访问。

    系统对接口被集成系统只开放应用定义的特定端口。

    采用防火墙的地址翻译功能,隐藏系统内部网络,向代理系统提供翻译后的接口通信服务器地址及端口,禁止接口对端系统对其它地址及端口的访问。

    对通过/未通过防火墙的所有访问记录日志。

    3)入侵检测

    接口安全机制应具有入侵检测(IDS)功能,实时监控可疑连接和非法访问等安全事件。一旦发现对网络或主机的入侵行为,应报警并采取相应安全措施,包括自动阻断通信连接或者执行用户自定义的安全策略。

    实施基于网络和主机的入侵检测。检测攻击行为和非法访问行为,自动中断其连接,并通知防火墙在指定时间段内阻断源地址的访问,记录日志并按不同级别报警,对重要系统文件实施自动恢复策略。

    4)口令认证

    对于需经接口安全控制系统对相关集成系统进行业务操作的请求,实行一次性口令认证。

    为保证接口的自身安全,对接口通信服务器和其它设备的操作和管理要求采用强口令的认证机制,即采用动态的口令认证机制。

    5)安全审计

    为了保证接口的安全,要求对接口通信服务器的系统日志、接口应用服务器的应用日志进行实时收集、整理和统计分析,采用不同的介质存档。

    6)防恶意代码或病毒

    由于Internet为客户提WEB服务,因此,对于Internet接口要在网络分界点建立一个功能强大的防恶意代码系统,该系统能实时地进行基于网络的恶意代码过滤。建立集中的防恶意代码系统控制管理中心。

    7)加密

    为了提高接口通信信息的保密性,同时保证应用支撑平台的安全性,可以对系统平台与接口集成系统间的相关通信实施链路加密、网络加密或应用加密,保证无关人员以及无关应用不能通过网络链路监听获得关键业务信息,充分保证业务信息的安全。

    三、wsdl接口设计

    WSDL是一个用于精确描述Web服务的文档,WSDL文档是一个遵循WSDL-XML模式的XML文档。WSDL 文档将Web服务定义为服务访问点或端口的集合。在 WSDL 中,由于服务访问点和消息的抽象定义已从具体的服务部署或数据格式绑定中分离出来,因此可以对抽象定义进行再次使用。消息,指对交换数据的抽象描述;而端口类型,指操作的抽象集合。用于特定端口类型的具体协议和数据格式规范构成了可以再次使用的绑定。将Web访问地址与可再次使用的绑定相关联,可以定义一个端口,而端口的集合则定义为服务。

    一个WSDL文档通常包含8个重要的元素,即definitions、types、import、message、portType、operation、binding、service元素。这些元素嵌套在definitions元素中,definitions是WSDL文档的根元素。

    WSDL文档外层结构图示:

    WSDL 服务进行交互的基本元素:

    Types(消息类型):数据类型定义的容器,它使用某种类型系统(如 XSD)。

    Message(消息):通信数据的抽象类型化定义,它由一个或者多个 part 组成。

    Part:消息参数

    PortType(端口类型):特定端口类型的具体协议和数据格式规范。,它由一个或者多个 Operation组成。

    Operation(操作):对服务所支持的操作进行抽象描述,WSDL定义了四种操作:

    1.单向(one-way):端点接受信息;

    3.要求-响应(solicit-response):端点发送消息,然后接受相关消息;

    4.通知(notification[2] ):端点发送消息。

    Binding:特定端口类型的具体协议和数据格式规范。

    Port:定义为绑定和网络地址组合的单个端点。

    Service:相关端口的集合,包括其关联的接口、操作、消息等。

    外层结构里面也可能有多层结构。

    四、Restful风格接口设计

    4.1协议

    API与用户的通信协议,通常使用HTTP/HTTPs协议(特别是web)

    4.2域名

    应该尽量将API部署在专用域名之下。

    https://api.example.com

    如果确定API很简单,不会有进一步扩展,可以考虑放在主域名下。

    https://example.org/api/

    4.3版本

    API的版本号放入URL

    https://api.example.com/v1/

    另一种设计方式将版本号放在HTTP头信息中,但不如放入URL方便和直观,Github采用这种做法。

    4.4路径

    路径又称"终点"(endpoint),表示API的具体网址。

    在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的"集合"(collection),所以API中的名词也应该使用复数。

    举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。

    • https://api.example.com/v1/zoos
    • https://api.example.com/v1/animals
    • https://api.example.com/v1/employees

    4.5HTTP动词

    对于资源的具体操作类型,由HTTP动词表示,常用的HTTP动词有下面五个(括号里是对应的SQL命令)。

    • GET(SELECT):从服务器取出资源(一项或多项)。
    • POST(CREATE):在服务器新建一个资源。
    • PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
    • PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。
    • DELETE(DELETE):从服务器删除资源。

    两个不常用的HTTP动词:

    • HEAD:获取资源的元数据。
    • OPTIONS:获取信息,关于资源的哪些属性是客户端可以改变的。

    举例如下:

    • GET /zoos:列出所有动物园
    • POST /zoos:新建一个动物园
    • GET /zoos/ID:获取某个指定动物园的信息
    • PUT /zoos/ID:更新某个指定动物园的信息(提供该动物园的全部信息)
    • PATCH /zoos/ID:更新某个指定动物园的信息(提供该动物园的部分信息)
    • DELETE /zoos/ID:删除某个动物园
    • GET /zoos/ID/animals:列出某个指定动物园的所有动物
    • DELETE /zoos/ID/animals/ID:删除某个指定动物园的指定动物

    4.6过滤信息

    如果记录数量很多,服务器不可能都将它们返回给用户。API应该提供参数,过滤返回结果,常见的参数如下:

    • ?limit=10:指定返回记录的数量
    • ?offset=10:指定返回记录的开始位置。
    • ?page=2&per_page=100:指定第几页,以及每页的记录数。
    • ?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
    • ?animal_type_id=1:指定筛选条件

    参数设计允许存在冗余,即允许API路径和URL参数偶尔有重复。比如,GET /zoo/ID/animals 与 GET /animals?zoo_id=ID 的含义是相同的。

    4.7状态码

    服务器向用户返回的状态码和提示信息,常见的有以下一些(方括号中是该状态码对应的HTTP动词)。

     200 OK - [GET]:服务器成功返回用户请求的数据,该操作是幂等的(Idempotent)。

    201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。

    202 Accepted - [*]:表示一个请求已经进入后台排队(异步任务)

    204 NO CONTENT - [DELETE]:用户删除数据成功。

    400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行新建或修改数据的操作,该操作是幂等的。

    401 Unauthorized - [*]:表示用户没有权限(令牌、用户名、密码错误)。

    403 Forbidden - [*] 表示用户得到授权(与401错误相对),但是访问是被禁止的。

    404 NOT FOUND - [*]:用户发出的请求针对的是不存在的记录,服务器没有进行操作,该操作是幂等的。

    406 Not Acceptable - [GET]:用户请求的格式不可得(比如用户请求JSON格式,但是只有XML格式)。

    410 Gone -[GET]:用户请求的资源被永久删除,且不会再得到的。

    422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时,发生一个验证错误。

    500 INTERNAL SERVER ERROR - [*]:服务器发生错误,用户将无法判断发出的请求是否成功。

    4.8错误处理

    如果状态码是4xx,就应该向用户返回出错信息。一般来说,返回的信息中将error作为键名,出错信息作为键值即可。

    {

        error: "Invalid API key"

    }

    4.9返回结果

    针对不同操作,服务器向用户返回的结果应该符合以下规范:

    GET /collection:返回资源对象的列表(数组)

    GET /collection/resource:返回单个资源对象

    POST /collection:返回新生成的资源对象

    PUT /collection/resource:返回完整的资源对象

    PATCH /collection/resource:返回完整的资源对象

    DELETE /collection/resource:返回一个空文档

    4.10Hypermedia API

    RESTful API最好做到Hypermedia,即返回结果中提供链接,连向其他API方法,使得用户不查文档,也知道下一步应该做什么。

    比如,当用户向api.example.com的根目录发出请求,会得到如下文档:

    {"link": {

          "rel":   "collection https://www.example.com/zoos",

          "href":  "https://api.example.com/zoos",

          "title": "List of zoos",

          "type":  "application/vnd.yourformat+json"

        }}

    文档中有一个link属性,用户读取这个属性就知道下一步该调用什么API了。rel表示这个API与当前网址的关系(collection关系,并给出该collection的网址),href表示API的路径,title表示API的标题,type表示返回类型。

    Hypermedia API的设计被称为HATEOAS。Github的API采用次设计方式,访问api.github.com会得到一个所有可用API的网址列表。

        {

          "current_user_url": "https://api.github.com/user",

          "authorizations_url": "https://api.github.com/authorizations",

          // ...

        }

    如果想获取当前用户的信息,应该去访问api.github.com/user,然后就得到了下面结果:

     

        {

          "message": "Requires authentication",

          "documentation_url": "https://developer.github.com/v3"

        }

    上面代码表示,服务器给出了提示信息,以及文档的网址。

    4.11其它

    1)API的身份认证应该使用OAuth 2.0框架。

    2)服务器返回的数据格式,应该尽量使用JSON,避免使用XML。

    消息服务传输

    Java消息服务(Java Message Service)是message数据传输的典型的实现方式。系统A和系统B通过一个消息服务器进行数据交换。系统A发送消息到消息服务器,如果系统B订 阅系统A发送过来的消息,消息服务器会消息推送给B。双方约定消息格式即可。目前市场上有很多开源的jms消息中间件,比如 kafka,ActiveMQ, OpenJMS。

    一、消息服务设计

    目前需要导入一个大文件到系统A,系统A保存文件信息,而文件里面的明细信息需要导入到系统B进行分析,当系统B分析完成之后,需要把分析结果通知系统A。

    1)系统A先保存文件到文件服务器。

    2)系统A 通过webservice 调用系统B提供的服务器,把需要处理的文件名发送到系统B。由于文件很大,需要处理很长时间,所以B不及时处理文件,而是保存需要处理的文件名到数据库,通过后台定时调度机制去处理。所以B接收请求成功,立刻返回系统A成功。

    3)系统B定时查询数据库记录,通过记录查找文件路径,找到文件进行处理。这个过程很长。

    4)系统B处理完成之后发送消息给系统A,告知系统A文件处理完成。

    5)系统A 接收到系统B请求来的消息,进行展示任务结果。

    二、消息服务优缺点

    消息服务优点

    1)由于jms定义了规范,有很多的开源的消息中间件可以选择,而且比较通用。接入起来相对也比较简单

    2)通过消息方式比较灵活,可以采取同步,异步,可靠性的消息处理,消息中间件也可以独立出来部署。

    消息服务缺点

    1)学习jms相关的基础知识,消息中间件的具体配置,以及实现的细节对于开发人员来说还是有一点学习成本的

    2)在大数据量的情况下,消息可能会产生积压,导致消息延迟,消息丢失,甚至消息中间件崩溃。

    文件共享

    对于大数据量的交互,采用文件的交互方式是最佳方式之一。

    一、文件共享设计

    系统A和系统B约定文件服务器地址,文件命名规则,文件内容格式等内容,通过上传文件到文件服务器进行数据交互。

    最典型的应用场景是批量处理数据:例如系统A把今天12点之前把要处理的数据生成到一个文件,系统B第二天凌晨1点进行处理,处理完成之后,把处理 结果生成到一个文件,系统A 12点在进行结果处理。这种状况经常发生在A是事物处理型系统,对响应要求比较高,不适合做数据分析型的工作,而系统B是后台系统,对处理能力要求比较 高,适合做批量任务系统。

    以上只是说明通过文件方式的数据交互,实际情况B完成任务之后,可能通过socket的方式通知A,不一定是通过文件方式。

    二、文件共享优缺点

    优点:

    1 在数据量大的情况下,可以通过文件传输,不会超时,不占用网络带宽。

    2 方案简单,避免了网络传输,网络协议相关的概念。

    缺点:

    1 不太适合做实时类的业务

    2 必须有共同的文件服务器,文件服务器这里面存在风险。因为文件可能被篡改,删除,或者存在泄密等。

    3 必须约定文件数据的格式,当改变文件格式的时候,需要各个系统都同步做修改。

    socket传输

    Socket方式是最简单的交互方式,适用于c/s 交互模式,一台客户机,一台服务器。

    一、socket传输设计

    服务器提供服务,通过ip地址和端口进行服务访问。而客户机通过连接服务器指定的端口进行消息交互。其中传输协议可以 是tcp/UDP 协议。而服务器和约定了请求报文格式和响应报文格式。如下图所示:

    目前常用的http调用,java远程调用,webserivces 都是采用的这种方式,只不过不同的就是传输协议以及报文格式。

    二、socket传输优缺点

    优点:

    1)易于编程,目前java提供了多种框架,屏蔽了底层通信细节以及数据传输转换细节。

    2)容易控制权限。通过传输层协议https,加密传输的数据,使得安全性提高

    3)通用性比较强,无论客户端是.net架构,java,python 都是可以的。尤其是webservice规范,使得服务变得通用

    缺点:

    1)服务器和客户端必须同时工作,当服务器端不可用的时候,整个数据交互是不可进行。

    2)当传输数据量比较大的时候,严重占用网络带宽,可能导致连接超时。使得在数据量交互的时候,服务变的很不可靠。

    数据库传输

    一、数据库传输设计

    系统A和系统B通过连接同一个数据库服务器的同一张表进行数据交换。当系统A请求系统B处理数据的时候,系统A Insert一条数据,系统B select 系统A插入的数据进行处理。

    二、数据库传输优缺点

    优点:

    1)相比文件方式传输来说,因为使用的同一个数据库,交互更加简单。

    2)由于数据库提供相当做的操作,比如更新,回滚等。交互方式比较灵活,而且通过数据库的事务机制,可以做成可靠性的数据交换。

    缺点:

    1)当连接B的系统越来越多的时候,由于数据库的连接池是有限的,导致每个系统分配到的连接不会很多,当系统越来越多的时候,可能导致无可用的数据库连接

    2)一般情况,来自两个不同公司的系统,不太会开放自己的数据库给对方连接,因为这样会有安全性影响

    数据爬取

    数据爬取可根据不同环境做不同方案,C/S模式可用数据抓包工具进行抓包数据,B/S模式可定制开发网络爬虫实现数据爬取。获取到的数据传输到指定位置,再进行使用处理。不过爬取的数据获取方式比较“非主流”,并且存在安全问题及对服务器的压力,不建议使用此种方式。

    展开全文
  • 不同应用系统之间数据交互的几种方式

    万次阅读 多人点赞 2020-05-12 23:59:30
    信息系统的普及应用导致原有系统间的信息孤岛需要通过系统间接口进行数据交互,信息交互的接口常见有以下几种: (1)数据库交互:服务方提供表或存储过程,由调用方控制commit或rollback。 (2)文件交互:双方对请求...
  • JAVA实现两个系统数据对接

    千次阅读 2021-04-20 18:35:56
    前言 最近做了两个系统,现在有一个需求,需要做数据对接,这个有很多方法实现,我这里用的是接口对接。由于是第一次做这种功能,也踩了不少坑,所以在这里记录一下。 提示:以下是本篇文章正文内容,下面案例仅供参考 ...
  • 从理论上来说,大数据分析应用,接入不同数据源的数据,搭建大数据模型,对数据进行多角度的深度发掘,可以应用在各行各业。 通常,我们提及的大数据,即指数据量巨大,也指数据来源众多。不难理解,数据源是大数据...
  • 系统常用的通信对接方式

    千次阅读 2021-07-18 23:47:52
    系统之间接口对接的方式主要有以下几种: 方式一:ftp/文件共享服务器方式 方式二:Socket方式 方式三:数据库共享方式 方式四:message方式 二 常用接口对接方式 2.1 ftp/文件共享服务器方式 方式说明: 系
  • 不同系统之间的交互认证

    千次阅读 2017-07-28 23:21:27
    1、SHA256 2、时间戳 3、key 4、待续
  • 一个商城系统和多个卖家系统 现在需要做卖家在商城中有了新的订单时 在该卖家系统中也生成一条订单信息 这个数据对接的过程需要用啥技术解决 给点思路
  • 系统测试常见类型及说明

    千次阅读 2019-12-29 23:30:12
    功能测试(Functional Testing)是系统测试中最基本的测试,它不管软件内部的实现逻辑,主要根据产品的需求规格说明书和测试需求列表,验证产品的功能实现是否符合产品的需求规格。 2、性能测试 性能测试...
  • 系统对接 各个方案

    万次阅读 2015-11-26 11:53:22
    系统对接 各个方案
  • 列举系统对接技术的几种常见方式

    千次阅读 2019-09-18 05:21:02
    系统对接最常见的方式是接口方式,运气好的情况下,能够顺利对接,但是接口对接方式常需花费大量时间协调各个软件厂商。 因此当前各行业数据孤岛林立,对接业务软件或者是获取软件中的数据存在较大困难,尤其是CS软件...
  • 企业中系统间的几种对接方式

    千次阅读 2020-04-27 23:12:19
    主要对接方式: 文件传输(共享); 共享数据库; RPC(远程过程调用); 消息队列。
  • MES管理系统处于生产现场的执行层,主要是优化管理生产过程,收集精确的实时数据。
  • 医院叫号系统与his系统对接(二)

    千次阅读 2019-03-26 16:52:05
    1.要和his系统信息对接 但人家厂家又不给提供接口,只能自己写,真心想直接刷表 ,走形式: 首先得写一个单独的webservice 提供数据,供此项目调用,没写过,简单查了一些资料了解:WebService接口与HTTP接口的...
  • 引言 近年来,随着“一网一门一次”改革的大力推进,我国政务信息化迅猛发展,服务渠道不断...二是突出系统整合共享。解决传统上“各自为政、条块分割、烟囱林立”的信息孤岛现象,更加突出信息共享、业务协同,强调
  • 对接第三方系统实操经验分享

    千次阅读 2020-06-13 12:58:47
    对接第三方系统实操经验分享,erp系统、oa系统、邮件系统,任何系统都避免不了与第三方系统打交道
  • 应用系统数据对接几种方案

    万次阅读 2018-03-12 09:21:59
    应用系统之间数据传输的几种方式第一种方案:socket方式 Socket方式是最简单的交互方式。是典型才C/S交互模式。一台客户机,一台服务器。服务器提供服务,通过IP地址和端口进行服务访问。而客户机通过连接服务器...
  • 系统对接的痛点

    千次阅读 2019-09-22 04:46:00
    对接的目的是什么? 对接的数据是什么? 对接数据的流向是什么? 对接数据的时效性是什么? 对接的正确性如何保证? 对接的一致性如何保证? 系统间的传递如何保证? 传递间的性能如何保证? 传递间的安全...
  • 我们在软件成本估算时,对于系统集成类项目,各系统之间的接口设计怎么计算呢?在这种情况下,系统集成接口开发该怎么算就怎么算,外部接口文件+基本过程等等,计算出来的是集成接口开发总费用,一般不再分解到各个...
  • 企业应用用友财务系统核算财务数据,而业务系统是利用用友之外的第三方系统来做业务的核算。但是财务系统和业务系统是分开管理的,数据的来源是没有衔接的,主要是通过业务系统的单据打印后传递给财务人员,再由财务...
  • 做过B端业务的同学都知道,我们在工作中难免会遇到系统之间对接问题。为此,我们不仅需要了解对方系统所能提供的内容,还需要知道双方之间可以交互的节点。对接的顺畅,可以大大提升自己系统的扩展...
  • 企业内部系统产品人员对接规范

    千次阅读 2018-02-20 11:48:29
    前言: 企业内部由于业务之间存在相关关联关系,通常需要进行系统层面的接口对接,为了保证对接可以高效、准确的的完成,结合自身经历,分享相关经历,撰文如下。目录: 正文:一、 对接前1、 明确对接目的 ...
  • 精维对接信使白皮书

    2020-07-08 12:14:12
    精维对接信使作为应用中间件的增强构件,是基于J2EE体系结构采用Java语言开发的支持国际多种XML对接协议标准的数据交换平台软件,支持不同信息系统之间进行跨越平台、行业、时区、语言等多维度的数据交换与数据共享...
  • 系统对接用友U8

    千次阅读 2019-09-21 14:51:42
     它是U8早期版本就提供的一种企业数据集成模式,它比较适合用于内网系统与U8之间的数据集成,比如:WMS系统、MES系统等。  具体的实现方式有两种:  1、通过调用COM组件的方式实现与U8系统的通信;  2、通过...
  • 万维易化精维对接信使是基于J2EE 体系结构采用Java 语言开发...万维易化为满足不同信息系统之间建立实时数据交换与数据共享的需求,自主研发了精维对接信使,是消除信息孤岛、提升应用系统业务处理能力的最佳解决方案。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 66,045
精华内容 26,418
关键字:

不同系统之间如何对接