第二章：項目邊界與架構設計（上）
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 架構設計與總結（待補充）
歡迎關注我的知識星球，星球目前免費哦。
這里會有一些我在工作、生活的一些感悟與總結，當然，還有最新的一些技術分享（都是原創哦）。
