第二章:项目边界与架构设计(上)
author 妖生
date 2019-06-21
slogan:本是江湖客,曾把青锋剑,不料入此坑,书下与或非。
[TOC]
2.1 导读
上一章讲了数据交换平台的一些基本概念,也留下了一些疑问:
怎么把数据变成文件上传到前置机上去交换?怎么在目标端下载下来?怎么保证大文件的传输完整呢?中途失败了怎么办?
怎么知道对面的主机收到了我发送的文件呢?网闸可不提供TCP的ACK功能。
怎么保证数据的安全性呢?中途被篡改了怎么办?
怎么保证数据的时序性呢?网闸可不按照时间顺序给你传递文件。
怎么监控数据流转的情况呢?丢包了怎么办?有没有办法可以知道?
本章我们来讲讲数据交换平台的项目边界与架构设计,并在我们的架构设计里回答部分上面的问题。
2.2 平台边界与系统目标
首先,让我们来问自己几个问题:
1、我们做的平台,目的是什么?
2、与业务系统的边界在哪里?
首先,我们的目的是什么?
我们之前在做数据交换的工作的时候,把这部分功能融合在了业务系统中,好处是:开发快,用一个工具类就完成了文件的上传、下载。
坏处呢?在业务系统渐渐繁杂的时候,所有的业务功能都要去调用这个工具类,进行文件打包、上传的操作。与业务深度耦合,不能给其他系统服用。
上传之后,也不知道目标节点到底有没有收到这个包。
在接收到文件时,也不知道在传输的过程中,这个文件是否被篡改。
随着国家对信息安全的要求越来越严格,网闸、文件加密都已经成为了防火防盗的其中一把安全锁。
那么现在可以说,我们的目的是什么?
1、是为了能在跨网闸(关于网闸的概念详见第一章数据交换平台的一些基本概念)的情况下传输文件,快速传输。
在之前的系统中,数据经常会有延迟一两天的情况才到达目标节点的情况。
2、可以监控文件流转情况。
在无法监控的情况下,总是人工排查,经常耗费运维人员一整天的时间,也让客户对我们产生了不信任感。
3、文件传输加密。
满足国家的信息安全要求。
4、保证文件入库的有序性。
在业务的流转中,有时会更新同一条数据,或者先插入再更新,怎么保证这个先后顺序呢?
5、与业务系统解耦。
将新的交换平台从业务系统中剥离出来,为各个业务系统提供数据交换的需求实现。
2.3 技术选型与目标实现
那么,针对以上情况,我们要怎么做架构设计?怎么做技术选型呢?
2.3.1 文件传输工具选型
1、首先是文件传输。怎么去做技术选型?
先看看有什么能入我们的眼帘吧。我们的测试与生产的基础环境是什么?linux、java。
先看看linux下有哪些文件传输工具:rcp,scp,rsync,ftp,sftp,lftp,wget,curl。
再来看看我们的文件传输要求:
1)GB级大文件传输;
2)可上传、下载;
3)可断点续传;
4)防网络抖动;
5)最重要的一点,JAVA的API支持。
我们从以上工具中选几个常用的、有代表性的来看看吧:wget、scp、rsync、ftp、sftp。
工具名 | G+ | 双向传输 | 断点续传 | JavaAPI |
---|---|---|---|---|
wget | ✔ | wput上传 | ✔ | 不支持 |
scp | ✔ | ✔ | ✔ | 不支持 |
rsync | ✔ | ✔ | ✔ | 不支持 |
ftp | ✔ | ✔ | ✔ | 高 |
sftp | ✔ | ✔ | ✔ | 一般 |
以上这些工具的比较如果没有实际用过的同学可以参考这篇博文[linux下不同服务器间数据传输(rcp,scp,rsync,ftp,sftp,lftp,wget,curl)](https://blog.csdn.net/emili/a...。
这里要说句,上述的wget、scp等工具其实是有办法用java来调用的,java里有个ProcessBuilder类,可以调用外部命令,linux的shell、window的exe都可以。
一般的用法就是Runtime.getRuntime().exec()或ProcessBuilder(array).start(),感兴趣的可以自己百度,
或参考这两篇博文:ProcessBuilder、Runtime.getRuntime().exec()
当然,看到这里的小伙伴可能会发现我们的倾向已经很明确了,那就是FTP。
毕竟,这是一个可以跟HTTP相媲美的历史悠久的工具对不对?并且还有很成熟的javaAPI,Apache的common类都已经将其收入囊中。
说到这里,为什么不用简单的HTTP client来实现文件的传输管理呢?
其实也是可以的,可以模拟rsync,来实现分段管理、分片下载,类似迅雷、电驴这样的P2P下载工具。
还设想过,用socket来进行文件的传输,例如开通十个线程,每个线程对应一个socket长连接,轮询传输二进制流文件。
嗯,不过,论稳定性与简单易用,还是用FTP吧,至于http还是等HTTP2.0的普及吧。
还有个真实的想哭的原因,从项目启动到交付稳定版本,只给了一个月时间。呵呵,呵呵,呵呵……
稳定、简单、易用,满足需求、API丰富,重要的是快,这些理由还不够吗?妙蛙种子,不,FTP,就决定是你了。
当然,你以为选了FTP就结束了,后续会单独有一章说FTP的安装、调优及断点续传过程中遇到的坑的。
2.3.2 文件流转的监控设计
在物理隔离的情况下,无法直接用http、TCP访问,怎么通过文件交换实现文件流转的监控呢?
在这里,我们可以稍微简单重温下http是怎么进行数据交互的:我发个请求,你给个回执。就这么简单对不对?
http是基于TCP的,tcp是怎么连接的?三次握手的经典过程,我想大家应该是不会忘的。就算忘了,还是知道有握手这么个事情的(笑)。
好吧,简单回顾下,客户端的请求是第一次握手;在TCP第二次握手的时候,服务端会进行相应,此时产生一个ACK包返回客户端;第三次握手,客户端收到回执,又发出ACK给服务端,确认收包。
那么,这跟我们的文件流转监控有什么关系呢?聪明的你是不是已经想到了,对,没错,我们也可以在网闸那头收到包的时候返回一个ACK文件,证明我收到包了呀。
嗯,我们发个快递就行了,不用客气得像http一样来个电话连线。
这样一看,感觉很棘手的流转监控是不是瞬间就easy了。
可是,真的这么简单吗?
在多目标的时候,怎么保证将你的数据包正确发送给目标?
在到达网闸下一个节点,返回ACK的时候,又怎么知道原路返回呢?
这些问题后续会也会单独列个章节说,暂且叫数据链路生成与文件流转监控。
2.3.3 文件加密的选型(待补充)
2.3.4 文件时序的设计机制(待补充)
2.3.5 系统的解耦与深入(待补充)
2.4 架构设计与总结(待补充)
公众号注册的比较晚,没有评论功能,所以一般用来发长文。
知识星球相当于技术朋友圈,有问题大家可以提问,讨论。