交換平臺第二章：項目邊界與架構設計（上）

目錄

• 第二章：項目邊界與架構設計（上）
• 2.1 導讀
• 2.2 平臺邊界與系統目標
• 2.3 技術選型與目標實現
• 2.4 架構設計與總結（待補充）

第二章：項目邊界與架構設計（上）

author 妖生
date 2019-06-21
slogan：本是江湖客，曾把青鋒劍，不料入此坑，書下與或非。

2.1 導讀

上一章講了數據交換平臺的一些基本概念，也留下了一些疑問：

怎麼把數據變成文件上傳到前置機上去交換？怎麼在目標端下載下來？

怎麼保證大文件的傳輸完整呢？中途失敗了怎麼辦？

怎麼知道對面的主機收到了我發送的文件呢？網閘可不提供TCP的ACK功能。

怎麼保證數據的安全性呢？中途被篡改了怎麼辦？

怎麼保證數據的時序性呢？網閘可不按照時間順序給你傳遞文件。

怎麼監控數據流轉的狀況呢？丟包了怎麼辦？有沒有辦法能夠知道？

本章咱們來說講數據交換平臺的項目邊界與架構設計，並在咱們的架構設計裏回答部分上面的問題。

2.2 平臺邊界與系統目標

首先，讓咱們來問本身幾個問題：

一、咱們作的平臺，目的是什麼？
二、與業務系統的邊界在哪裏？

首先，咱們的目的是什麼？

咱們以前在作數據交換的工做的時候，把這部分功能融合在了業務系統中，好處是：開發快，用一個工具類就完成了文件的上傳、下載。

壞處呢？在業務系統漸漸繁雜的時候，全部的業務功能都要去調用這個工具類，進行文件打包、上傳的操做。與業務深度耦合，不能給其餘系統服用。
上傳以後，也不知道目標節點到底有沒有收到這個包。
在接收到文件時，也不知道在傳輸的過程當中，這個文件是否被篡改。

隨着國家對信息安全的要求愈來愈嚴格，網閘、文件加密都已經成爲了防火防盜的其中一把安全鎖。

那麼如今能夠說，咱們的目的是什麼？

一、是爲了能在跨網閘（關於網閘的概念詳見第一章數據交換平臺的一些基本概念）的狀況下傳輸文件，快速傳輸。
在以前的系統中，數據常常會有延遲一兩天的狀況纔到達目標節點的狀況。

二、能夠監控文件流轉狀況。
在沒法監控的狀況下，老是人工排查，常常耗費運維人員一成天的時間，也讓客戶對咱們產生了不信任感。

三、文件傳輸加密。
知足國家的信息安全要求。

四、保證文件入庫的有序性。
在業務的流轉中，有時會更新同一條數據，或者先插入再更新，怎麼保證這個前後順序呢？

五、與業務系統解耦。
將新的交換平臺從業務系統中剝離出來，爲各個業務系統提供數據交換的需求實現。

2.3 技術選型與目標實現

那麼，針對以上狀況，咱們要怎麼作架構設計？怎麼作技術選型呢？

2.3.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 架構設計與總結（待補充）

---

歡迎關注個人知識星球，星球目前免費哦。
這裏會有一些我在工做、生活的一些感悟與總結，固然，還有最新的一些技術分享（都是原創哦）。