精华内容
下载资源
问答
  • NFS是Network File System的缩写,中文称为网络文件系统,它的主要功能是通过网络(一个局域网)让不同的主机系统之间可以共享文件或目录,NFS的客户端(一般为应用服务器,例如web)可以通过挂载(mount)的方式将...

    NFS 文件系统搭建

    NFS是Network File System的缩写,中文称为网络文件系统,它的主要功能是通过网络(一个局域网)让不同的主机系统之间可以共享文件或目录,NFS的客户端(一般为应用服务器,例如web)可以通过挂载(mount)的方式将NFS服务器共享的数据目录挂载到NFS客户端本地系统中(就是某一个关在点下),从客户端本地看,NFS服务器端共享目录就好像是客户端自己的磁盘分区或者目录一样,而实际上却是远端的NFS服务器的目录。
    NFS网络文件系统很像Windows系统的网络共享、安全功能、网络驱动器映射,这也和linux的samba服务类似,只不过一般情况下,Windows网络共享服务或samba服务用户办公局域网共享,而互联网中小型网站集群架构后端常用NFS进行数据共享,若是大型网站,那么有可能还会用到更复杂的分布式文件系统Moosefs(mfs)、GlusterFS。

    在企业集群架构的工作场景中,NFS网络文件系统一般被用来存储共享视频、图片、附件等静态资源文件,通常网站用户上传的文件都会放到NFS共享中,例如BBS产品的图片、附件、头像(网站BBS的程序不要放在NFS共享中),然后前端所有节点在访问这些静态资源时都会读取NFS存储上的资源。
    NFS是当前互联网系统架构中最常用的数据存储服务之一,特别是中小型网站应用频率更高。

    实验环境:

    CentOS7.2 NFS server 服务器(IP: 10.0.0.30)
    CentOS7.2 NFS 客户端1(IP: 192.168.200.4)
    windows 10 NFS 客户端2(IP:192.168.10.56)

    1、安装NFS 服务器

    nfs-utils:nfs服务的主程序,包括rpc.nfsd、rpc.mountd两个daemons和相关的文档说明及执行命令文件等
    rpcbind:centos6下面的rpc主程序(centos5下的是portmap)
    
    [root@nfs-server ~]# yum install nfs-utils rpcbind -y
    
    [root@nfs-server ~]# systemctl start rpcbind
    
    [root@nfs-server ~]# systemctl start nfs
    
    
    [root@nfs-server ~]# vi /etc/exports
    
    /data 192.168.100.10(rw,sync,all_squash)
    /data 192.168.10.0/24(rw,sync,all_squash)
    
    [root@nfs-server ~]# systemctl restart rpcbind
    [root@nfs-server ~]# systemctl restart nfs
    [root@nfs-server ~]# systemctl enable nfs-server
    Created symlink from /etc/systemd/system/multi-user.target.wants/nfs-server.service to /usr/lib/systemd/system/nfs-server.service.
    [root@xiandian mnt]# systemctl enable rpcbind
    到此 NFS  搭建完成

    2、nfs配置文件的格式
    NFS共享的目录 NFS客户端地址(参1,参2,……) NFS客户端地址2(参1,参2,……)

    /data 10.0.0.30(rw,sync)   /data  192.168.10.0/24(rw,sync)

    常用格式说明 实例
    配置案例1 /data 172.16.1.0/24(rw,sync) 允许客户端读写,并且数据同步写到服务器的磁盘里
    配置案例2 /data 172.16.1.0/24(rw,sync,all_squash,anonuid=888,anongid=888) 允许客户端读写,并且数据同步写到服务器的磁盘里,并且指定客户端的uid和gid,早期生产环境中的一种配置,适合多客户端共享一个NFS单目录,如果所有服务器的nfsnodoby账户的UID相同,则本案例就没什么意义了
    配置案例3 /data 172.16.1.0/24(ro) 只读共享,用途:例如在生产环境中开发人员有查看服务器日志的需求,但是又不希望给开发服务器的权限,那么就可以给开发提供从某个测试服务器NFS客户端上查看某个生产服务器日志目录(NFS共享目录)的权限,但是,这不是唯一的方法.
    客户端地址 具体地址 说明
    授权单一客户端访问NFS 172.16.1.41 一般情况下,生产环境中此配置不多
    授权整个网段访问NFS 172.16.1.0/24 指定网段为生产环境中最常见的配置,配置简单、维护方便
    授权整个网段可访问NFS 172.0.0.* 指定网段的另外写法(不推荐使用)
    授权某个域名客户端访问 nfs.lzhnb.com 生产环境中一般不使用
    授权整个域名客户端访问 *.lzhnb.com 生产环境中一般不使用

    NFS配置参数权限,具体如下表

    参数名称 参数用途
    rw(熟记) 表示可读写权限
    sync(熟记) 请求或写入数据时,数据同步写入到NFS Server的硬盘后才返回,优点:数据安全不会丢,缺点:性能比不启用该参数要差
    async(熟记) 写入数据时会先写到内存缓冲区,直到硬盘有空档才会在写入磁盘,这样可以提升写入效率。风险是若服务器宕机或不正常关机,会损失缓冲区中未写入硬盘的数据(解决办法:服务器主板电池或UPS不间断电源)
    all_squash(熟记) 不管访问NFS Server共享目录的用户身份如何,它的权限都将被压缩为匿名用户,同时它的UID和GID都会变成nfsnobody账号身份,在早期多个NFS客户端同时读写NFS Server数据时,这个参数很有用,在生产环境中配置NFS的重要技巧:1)确保所有客户端服务器对NFS共享目录具备相同的用户访问权限,all_squash把所有客户端都压缩成匿名用户(UID相同),就是anonuid,anongid指定的UID和GID相同,2)所有的客户端和服务器端都需要有一个相同的UID和GID的用户,nfsnodoby(UID必须相同)
    anonuid(熟记) 参数以anon*开头即值anonymous匿名用户,这个用户的UID设置值通常为nfsnobody的UID值,当然我们也可以自行设置这个UID值。但是,UID必须存在于/etc/passwd中。在多个NFS Clients时,如多台web server共享一个NFS目录时,通过这个参数可以使得不同的NFS Clients写入的数据对所有NFS Clients保持同样的用户权限,即为配置的匿名UID对应用户权限,这个参数很有用。一般默认就好
    anongid(熟记) 同anonuid,区别是把uid(用户id)换成gid(组id)

     

    ro 表示只读权限

     2、分别使用centos 7.2,windows10对NFS进行测试。

    centos7.2:

    [root@test ~]# mount -t nfs 192.168.200.4:/mnt /opt/
        
    [root@test ~]# mount -t nfs 192.168.200.4:/mnt /mnt/
    
    [root@test ~]# cd /mnt/
    [root@test mnt]# ls
    volume-8487f7db-f628-42ab-b9c4-2ebf2693166b
    
    [root@ceph-1 mnt]# df -Th
    Filesystem         Type      Size  Used Avail Use% Mounted on
    /dev/vda1          xfs        20G  1.2G   19G   6% /
    devtmpfs           devtmpfs  984M     0  984M   0% /dev
    tmpfs              tmpfs    1001M     0 1001M   0% /dev/shm
    tmpfs              tmpfs    1001M   17M  985M   2% /run
    tmpfs              tmpfs    1001M     0 1001M   0% /sys/fs/cgroup
    /dev/vdb1          xfs        50G  7.2G   43G  15% /opt/osd1
    192.168.200.4:/mnt nfs4       50G   33M   50G   1% /mnt

    windows 10:

     

     

     

    然后等待安装完成,安装完成后打开cmd:

     

     

    1、对接 openstack   cinder-volumes

    [root@xiandian ~]# vi /etc/cinder/nfs_shares 
    192.168.200.4:/mnt
    
    [root@xiandian ~]# chmod +755 /etc/cinder/nfs_shares 
    
    [root@xiandian ~]# vi /etc/cinder/cinder.conf 
    [DEFAULT]
    rpc_backend = rabbit
    auth_strategy = keystone
    my_ip = 127.0.0.1
    enabled_backends = nfs
    glance_api_servers = http://xiandian:9292
    volume_driver = cinder.volume.drivers.nfs.NfsDriver
    nfs_shares_config = /etc/cinder/nfs_shares
    
    [lvm]    //启用多后端的话就不要注释
    #volume_driver = cinder.volume.drivers.lvm.LVMVolumeDriver
    #volume_group = cinder-volumes
    #iscsi_protocol = iscsi
    #iscsi_helper = lioadm
    
    [root@xiandian ~]# cinder service-list
    +------------------+--------------+------+---------+-------+----------------------------+-----------------+
    |      Binary      |     Host     | Zone |  Status | State |         Updated_at         | Disabled Reason |
    +------------------+--------------+------+---------+-------+----------------------------+-----------------+
    | cinder-scheduler |   xiandian   | nova | enabled |  down | 2019-05-14T21:23:17.000000 |        -        |
    |  cinder-volume   | xiandian@lvm | nova | enabled |  down | 2019-05-14T21:23:04.000000 |        -        |
    |  cinder-volume   | xiandian@nfs | nova | enabled |   up  | 2019-05-14T21:24:43.000000 |        -        |
    +------------------+--------------+------+---------+-------+----------------------------+-----------------+
    [root@xiandian ~]# cinder create --name a 1
    +--------------------------------+--------------------------------------+
    |            Property            |                Value                 |
    +--------------------------------+--------------------------------------+
    |          attachments           |                  []                  |
    |       availability_zone        |                 nova                 |
    |            bootable            |                false                 |
    |      consistencygroup_id       |                 None                 |
    |           created_at           |      2019-05-14T21:25:00.000000      |
    |          description           |                 None                 |
    |           encrypted            |                False                 |
    |               id               | 97b712dc-a82f-4f7f-ae1b-fbe0597d5889 |
    |            metadata            |                  {}                  |
    |        migration_status        |                 None                 |
    |          multiattach           |                False                 |
    |              name              |                  a                   |
    |     os-vol-host-attr:host      |                 None                 |
    | os-vol-mig-status-attr:migstat |                 None                 |
    | os-vol-mig-status-attr:name_id |                 None                 |
    |  os-vol-tenant-attr:tenant_id  |   0ab2dbde4f754b699e22461426cd0774   |
    |       replication_status       |               disabled               |
    |              size              |                  1                   |
    |          snapshot_id           |                 None                 |
    |          source_volid          |                 None                 |
    |             status             |               creating               |
    |           updated_at           |                 None                 |
    |            user_id             |   53a1cf0ad2924532aa4b7b0750dec282   |
    |          volume_type           |                 None                 |
    +--------------------------------+--------------------------------------+

     

    2 、对接nova.

    [root@xiandian  ]# mount 10.0.0.30:/mnt/ /var/lib/nova/instances/
    
    [root@xiandian ~]# nova boot --flavor 1 --image a  --nic net-id=bd923693-d9b1-4094-bd5b-22a038c44827 test
    
    [root@xiandian instances]# nova list
    +--------------------------------------+------+--------+------------+-------------+----------------------+
    | ID                                   | Name | Status | Task State | Power State | Networks             |
    +--------------------------------------+------+--------+------------+-------------+----------------------+
    | 6c6c6ba8-f3b0-46c1-b0d7-d2e5223119ca | ll   | ACTIVE | -          | Running     | sharednet1=10.0.0.32 |
    +--------------------------------------+------+--------+------------+-------------+----------------------+
    
    [root@xiandian instances]# pwd
    /var/lib/nova/instances
    [root@xiandian instances]# ls
    6c6c6ba8-f3b0-46c1-b0d7-d2e5223119ca  _base  locks
    
    

     

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

    千次阅读 2021-02-07 09:28:46
    IT系统对接是很多企业、项目必须面对的问题;通常,多个系统之间如果完全企业自主定制开发,且有源代码、服务器的所有权,可以选择数据库直传的方式,方便快捷。如果系统之间存在权限限制或技术限制,可采用接口以...

    目录

    概述

    技术方案

    接口

    消息服务传输

    文件共享

    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模式可定制开发网络爬虫实现数据爬取。获取到的数据传输到指定位置,再进行使用处理。不过爬取的数据获取方式比较“非主流”,并且存在安全问题及对服务器的压力,不建议使用此种方式。

    展开全文
  • 非结构化数据正以前所未有的速度...尽管非结构化数据并不是什么新鲜事,但IT团队承受着巨大压力,他们希望以简单和易于使用的方式快速、一致地存储和管理非结构化数据,但传统文件系统有很多的限制:❶ 元数据和数据...
    非结构化数据正以前所未有的速度增长。IDC的预测表明,到2025年,全球将有80%的数据是非结构化的文件协议是存取非结构化数据最普遍的使用方式,根据IDC统计,2019年度,中国的软件定义存储市场约60%是文件存储

    c45e963c7ef597bb133f6a9f730fb726.png

    尽管非结构化数据并不是什么新鲜事,但IT团队承受着巨大压力,他们希望以简单和易于使用的方式快速、一致地存储和管理非结构化数据,但传统文件系统有很多的限制:

     ❶ 元数据和数据使用本地存储,无法横向扩展,不具备节点级高可用;❷ 受限于元数据的存储空间和性能,实际可保存的文件数有限,一般小于1亿,存储空间为TB级别;❸ 非统一命名空间,多个挂载目录之间无法互通,使用复杂;❹ 文件存储网关不可扩展,无法提升带宽,造成访问瓶颈;❺ 不支持大数据和容器等新业务。

    分布式文件架构,如何和硬件与时俱进?

    数字化转型下的软件定义存储架构,可以很好的满足用户各种需求,如在标准服务器上的敏捷部署,可灵活扩展,性能和容量随服务器节点数增长而线性增长,硬件升级与更换无需跨存储系统迁移数据,硬件升级换代红利即时享用,业务层无感知、无影响等。

    17cc8969a7911e6677a41f0b76518c3f.png

    但是软件定义,也需要充分利用最新的硬件技术,与时俱进。分布式文件存储,最复杂的就是元数据的保存和处理。根据统计,大部分的AI/ML分析应用,90%的I/O都是请求元数据操作上一代的分布式文件系统,由于当时的硬件限制,为了解决元数据的容量瓶颈,部分产品(如CephFS)将元数据保存在后端的RADOS集群里,I/O路径长,并且由于复杂的同步和互锁机制,性能损耗较高,性价比并不理想;部分产品(如HDFS)采用内存来保存所有的元数据,虽然元数据性能较好,但由于内存的容量有限,系统支持的文件数比较少,扩展能力有限。 有没有一种架构,能够以较低的成本,极简的架构,满足现代文件系统元数据处理的性能和容量要求?现在,大容量高速SSD的普及,使得鱼和熊掌兼得变成现实。NVMe协议的出现,大大降低接口协议的开销,SCM(存储级内存)的出现,大大提升介质的性能,加上颗粒成本的下降,使得5TB以上的大容量NVMeSSD较为普遍

    77de71e01f6d107111c15913018040d7.png

    这些SSD新技术的发展,加上CPU的核数越来越多,使得全闪存元数据节点完全可以应对大规模文件系统的需求,比如,只需要5TB的NVMe SSD的元数据空间,就可以轻松保存和处理百亿规模文件。 

    XGFS重新定义下一代分布式文件系统

    XGFS(XSKY Global File System)是XSKY提供的新一代分布式文件存储系统,具有单一全局的命名空间。XGFS基于灵活的SDS架构,支持NFS、SMB、FTP、POSIX、HDFS、Kubernetes CSI(容器存储接口)等丰富的协议,不仅可以用于企业的文件共享,备份归档通用场景,也可以应用于视频监控、媒资管理、高性能计算等高性能、大带宽、大容量的场景, 还支持最新的大数据和容器场景。

    44f9826f5839bb60aa3c4561520641ce.png

    XGFS企业级分布式存储系统架构图XGFS创新利用最新的多核CPU、大容量和高性能NVMe SSD,只需要3个全闪存元数据高可用节点(可以共用数据节点),就可以高效保存和处理100亿数量文件规模的数据,同时提供每秒上百万元数据读写请求处理能力,具有极高的性价比。而XGFS的数据节点,则充分利用XSKY久经市场考验的可靠自主分布式存储集群,成熟稳定,可以轻松扩展到上千个节点。

    b01860c41c6bace28f3c253c4d599cd7.png

    XGFS企业级分布式存储系统用户界面XGFS元数据服务的架构具有如下优势:▪  基于最新一代NVMe/SCM存储介质设计,充分发挥出新兴介质近百万级IOPS和数GB带宽的性能优势,轻松满足对于文件系统的高频率元数据访问需求;▪  利用高性能LSM存储引擎,结合XSKY独有专利技术的键值设计,构建出完全自主的元数据服务;既兼容POSIX文件语义和S3对象语义,又支持用户/用户组、权限/ACL、扩展属性等;▪  元数据在本节点的日志保护和节点间的强一致性复制,使得元数据集群轻松应对慢盘、网络异常、节点重启/掉电等故障场景,提供RPO=0的元数据通路;▪  使用XSKY自研的高速网络传输模块,原生为RoCE/RDMA高性能网络量身打造,大大降低节点间元数据复制包的传输时延,使得整个元数据集群拥有更高的IOPS性能。XGFS分布式文件存储系统由元数据服务集群和混合盘数据服务共同组成,使得该产品继承了XSKY多年在分布式混合盘上的深厚积累以及大规模存储运维能力:多级缓存技术、支持副本与EC纠删码、支持延展集群双活、硬盘和网络亚健康处理等,成熟稳定,特性丰富且运维简单

    产品特点

    1、全局命名空间▪  单一命名空间:提供统一持续高性能的文件单一全局命名空间,使用简单;▪  丰富的协议支持:支持NFS, SMB, POSIX, FTP, HDFS,Kubernetes CSI等协议,简化业务IT架构的同时解除对业务的锁定;▪  新兴业务场景支持:支持HPC、大数据和容器等新兴负载。2、灵活扩展▪  软件定义,可自定义节点属性,并支持各种品牌的通用x86服务器和国产服务器;▪  灵活部署,可从3个节点扩展到4096个节点,满足不同业务需求;▪  按需扩展,性能和容量随节点数增加而增长,满足不断增长的业务对性能和容量的需求。3、丰富的企业级功能▪  数据冗余:支持多副本和EC不同冗余策略,提供基于服务器、机架、数据中心的三个级别故障域管理。支持快照保护;▪  支持文件网关负载均衡和HA保护,支持AD域、LDAP域对接,本地认证等多种认证方式。支持配额管理;▪  通过内嵌X3DS可以实现文件和对象间的复制、迁移、备份、归档等丰富的数据管理功能,并且支持阿里云和百度云等公有云平台。 

    典型应用场景

    XGFS可以作为企业级分布式文件系统,支持丰富的大容量非结构化数据保存和分析场景:1、文件共享、企业办公存储单一全局命名空间,使用简单。支持文件共享、网盘、FTP等办公场景。2、视频监控、流媒体、CDN存储横向扩展,滚动升级,数据永久保存。3、大数据、HPC后端存储兼容HDFS, 高效文件元数据处理机制,灵活应对AI/ML数据分析要求。4、容器共享存储支持Kubernetes CSI接口,支持多个PODs共享数据。5、集中灾备资源池利用X3DS(XSKY立体数据管理系统)ODPF(开放数据保护框架),可以作为大容量的共享灾备资源池。6、企业数据湖底座支持Hadoop存算分离部署,接口协议丰富,可以扩展到上千节点。XSKY XGFS充分利用SDS优势,适配最新的NVMeSSD新技术,支持最新的HDFS和Kubernetes CSI协议,性价比高,无需在性能和容量之间做出妥协,是企业的数据湖建设的理想底座。 b2385f4bbdef1292a39da86d51930ec5.gif

    XSKY发布X3DS立体数据管理系统,解决海量非结构化数据管理难题

    性能最高提升225%!XSKY发布新一代 SDS一体机

    5年融资7.52亿,XSKY星辰天合重金布局信创战略

    UCloud发布新一代归档存储产品,存储成本直降80%

    紫光华智视图云存储US3060全新亮相!

    欢迎新闻投稿特大牛平台入驻企业优先发布email:tdm@itxxxl.com

    a095f6ac5d272afe64bfdb29ef81c520.png

    展开全文
  • 企业中系统间的几种对接方式

    千次阅读 2020-04-27 23:12:19
    主要对接方式文件传输(共享); 共享数据库; RPC(远程过程调用); 消息队列。
    主要对接方式:
    文件传输(共享);
    共享数据库;
    RPC(远程过程调用);
    消息队列。
    
    展开全文
  • 目标:使用天猫精灵自定义技能对接教务系统,获取课程表,通过语音方式反馈课程基本信息。加入开发者平台在AliGenie开发者平台申请账号,登录后转到智能应用下的技能页面创建技能点击创建语音技能,技能名称自定,...
  • 系统间数据传输的方式主要有接口传输、数据库传输、文件共享传输、消息队列方式传输等,以上在另一篇文章中已经有所介绍。本文仅关于获取数据之后的运算逻辑、异常机制等,在这里做具体的举例探讨。一、触发式和定时...
  • 前言最近在和一个档案管理系统对接,需要把我方系统文件压缩成zip格式,通过ftp的方式upload到指定的服务器上,考虑到Java的平台无关性,一开始便使用Java自带的类库java.util.zip来实现文件的压缩,谁曾想传送过去...
  • 系统间数据交换的5种方式

    千次阅读 2018-04-12 19:58:00
    工作中常会遇到系统对接,交换数据,将用过的对接数据交换方式简要回顾一下。 一,原始的方式,直接文件交换 通过定义csv,xml,json等文件,一方支持数据导出,另一方支持数据导入。最开始是人手工完成,做的好点的...
  • 而这往往是多数据源的,如果单单的使用Kafka构建多个生产者使用文件流的方式向主题写入数据再供消费者消费的话,无疑非常的不方便(这里通俗的讲他们对接的好处也就是采集日志文件给多个系统来使用)。 2.Flume可以...
  • 通常我们的系统在与第三方系统对接的时候,有许多种方式实现:系统api接口、共享缓存、数据库共享、调用消息队列、页面跳转、共享数据文件等,在实际生产中,系统api接口的对接方式是占了很大部分的。 最近,我...
  • 比较头疼是供应商G提供的数据都是在Windows下使用Excel存储的,而客户K先前与我们相关对接人员商定的数据类型必须使用utf-8的txt文件,并且由于客户K程序处理的需要,并附带生成一个与该数据文件匹配的校验文件数据...
  • 活动流数据的这种处理方式对实时性要求越来越高的场景已经不在适用并且这种处理方式也增加了整个系统的复杂性,为了解决这种问题,分布式开源消息系统Kakfa已被多家不同类型的公司 作为多种类型的数据管道和消息系统...
  • 1. Spark Streaming 对接Flume ...以下将介绍Flume采集日志后直接对接Spark Streaming 两种方式 – push 和 poll。(使用的spark streaming版本为1.6.1, 使用flume版本为1.6.0) 1.1 Flume通过pus
  • 文件流的接收通常涉及到预定义变量函数 $HTTP_RAW_POST_DATA 和 file_get_contents我在哪些方面用到了文件流在开发微信公众平台系统的时候用到过,主要是数据的接收在和APP做对接开发的时候用到过,主要是文件数据的...
  • TSM项目介绍对接第三方接口SDKtsm, Third Services Manager 第三方服务管理器, 通过配置的方式管理多个第三方服务,适用于较为复杂的多系统交互场景安装教程下载tsm包到项目任意目录require ThirdServiceManager.php...
  • 文件流的接收通常涉及到预定义变量函数 $HTTP_RAW_POST_DATA 和 file_get_contents我在哪些方面用到了文件流在开发微信公众平台系统的时候用到过,主要是数据的接收在和APP做对接开发的时候用到过,主要是文件数据的...
  • UI设计师过完稿和开发对接时,需要标注设计稿和切图,把标注切图文件给到开发。这个时候就犯难了,那么多尺寸怎么切图,iPhone就有8个版本,更别提安卓那一堆尺寸。不用在意那么多设备不管iOS和Android手机型号有...
  • 新老系统数据对接,需要把老系统的附件放到新系统中,新系统的表结构和文件的存储位置与老系统都不同,存储方式也不一样。现需要把老系统的附件做做调整
  • 前言最近在和一个档案管理系统对接,需要把我方系统文件压缩成zip格式,通过ftp的方式upload到指定的服务器上,考虑到Java的平台无关性,一开始便使用Java自带的类库java.util.zip来实现文件的压缩,谁曾想传送过去...
  • 系统调用

    2021-04-21 14:37:25
    系统调用:应用程序通过系统调用请求操作系统的服务,系统中的各种共享资源都由操作系统统一掌管,因此在用户程序中,凡是与资源有关的操作(如存储分配、I/O操作、文件管理等)都必须通过系统调用的方式向操作系统...
  • 实现方式:将金蝶K3开票信息通过sql语句按照百望九赋软件导入格式要求拼接成xml格式文件,再通过税控软件批量开票接口调用导出的XML文件实现自动开票。 工具:金蝶K3 WISE版本;百望九赋金税系统V2.0以上版本(商品...
  • 系统已加入防掉线处理,只要不断网支付宝不会掉线的。 5、本程序经测试,可在2003、xp和win7正常运行且几乎不占内存,如有软件问题,请联系技术解决 6、目前为免费测试,如要使用请联系购买正版。以资鼓励! 7、注意...
  • 数据对接是进行数据沟通、整合信息的最佳方式,能够让不同领域中相同专业的软件系统彼此互补,进而让企业信息化系统整体运作效能达到相对最佳化。 接口主要是解决两个系统数据相互交换读写的问题。以下是进行数据...
  • 最近有一个系统对接需求,采用了古老的ftp交换文件方式来对接。于是我用了commons-net包的3.6版本来进行ftp的连接和文件的传输。连接ftp成功,登录也没问题,但是在传输文件的时候会卡住,程序没有往下走,一段时间...
  • 作为企业的数据存储和流转中心,可通过浏览器、HTTP RESTful API 、S3 API 、 SDK 和 FTP 等方式高效存取和管理文件,支撑企业丰富的上层业务和数据分析系统使用。本文,青云QingCloud 开发工程师丁皓将从核心概念...
  • 有一种方式是PDA与公司的进销存系统对接,PDA逐个对卖场货品进行扫描,及时上传至系统,完成盘点。也有公司不这样操作,店铺可能面积较大,配置若干台PDA,每人负责一块盘点区域,各区域盘点完生成相应的文本文件,...
  • 使用本组件可以轻松将几G文件上传到服务器,良好的兼容性和通用的接口,可以直接与您的系统整合或对接,大大缩短整个系统的开发时间,降低系统的开发成本,提高产品的质量和用户体验。 二、组件特点: 1. 支持在线...
  • 摘要:.NET源码,上传下载,上传组件,文件上传 基于Silverlight框架的大文件上传组件,支持断点续传、兼容各大浏览器、支持分布式文件存储,可以轻松将几G文件上传到服务器,与您的系统整合或对接。  组件特点:  1....
  • 前言最近在和一个档案管理系统对接,需要把我方系统文件压缩成zip格式,通过ftp的方式upload到指定的服务器上,考虑到Java的平台无关性,一开始便使用Java自带的类库java.util.zip来实现文件的压缩,谁曾想传送过去...
  • 二个系统接口对接中,其中一方需要进行文件传输,另一方接受保存。 二.思路 首先了解接口接受的参数类型, 方式选择以文件流的形式打开文件,转换为byte进行存储,然后通过接口传送,对方接受后存在目录中即可。 三....

空空如也

空空如也

1 2 3 4 5 ... 14
收藏数 261
精华内容 104
关键字:

文件方式系统对接