上善若水,不进则退

姚毛毛

左手代码,右手写诗

linuxido.com

交换平台第二章:项目边界与架构设计(上)

第二章:项目边界与架构设计(上)

author 妖生
date 2019-06-21
slogan:本是江湖客,曾把青锋剑,不料入此坑,书下与或非。

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/article/details/6858818)。

这里要说句,上述的wget、scp等工具其实是有办法用java来调用的,java里有个ProcessBuilder类,可以调用外部命令,linux的shell、window的exe都可以。

一般的用法就是Runtime.getRuntime().exec()或ProcessBuilder(array).start(),感兴趣的可以自己百度,
或参考这两篇博文:ProcessBuilderRuntime.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 架构设计与总结(待补充)


欢迎关注我的知识星球,星球目前免费哦。
这里会有一些我在工作、生活的一些感悟与总结,当然,还有最新的一些技术分享(都是原创哦)。

posted @ 2019-06-21 01:13  姚毛毛  阅读(1459)  评论(0编辑  收藏  举报