第二章：项目边界与架构设计（上）
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 架构设计与总结（待补充）
公众号注册的比较晚，没有评论功能，所以一般用来发长文。
知识星球相当于技术朋友圈，有问题大家可以提问，讨论。
欢迎关注我的公众号：姚毛毛的博客
欢迎加入我的知识星球，目前免费哦。
知识星球：姚毛毛的私密花园