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