交换平台第二章：项目边界与架构设计（上）
第二章：项目边界与架构设计（上）
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)
这里要说句，上述的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 架构设计与总结（待补充）
欢迎关注我的知识星球，星球目前免费哦。
这里会有一些我在工作、生活的一些感悟与总结，当然，还有最新的一些技术分享（都是原创哦）。
