目錄

  • 第二章:專案邊界與架構設計(上)
  • 2.1 導讀
  • 2.2 平臺邊界與系統目標
  • 2.3 技術選型與目標實現
  • 2.4 架構設計與總結(待補充)

第二章:專案邊界與架構設計(上)

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 架構設計與總結(待補充)


歡迎關注我的知識星球,星球目前免費哦。
這裡會有一些我在工作、生活的一些感悟與總結,當然,還有最新的一些技術分享(都是原創哦)。
相關文章