Translate

2015/02/09

DataSnap 能夠解決的問題?

Delphi.KTOP 的資深版主 Jason Wang 及 Sryang 等網友提供了很多相關資料,整理了以下內容:

多層架構可以解決兩層的四大問題:
1. 省錢。
2. 跨網際網路的安全性。
3. 資料庫連線數大量增加,造成效能低下。
4. 一致性的使用者端應用程式開發。

先談談如果要解決上述問題,除了 DataSnap 外,兩層架構下有沒有其它解決上述問題的方法?

跨網際網路的安全性問題:
沒有任何一家公司會希望自家的資料庫遭受攻擊,在資訊安全這方面,我們會採用:

1. 防火牆。
2. 軟體或硬體 VPN。
3. 遠端桌面連線。

防火牆的場合:
資料庫仍然需要掛上網際網路,也無法避免 Port Seek (埠位掃描)的攻擊,故實務上更改 Port 的方式也很少被採用,頂多是暫時性的權宜做法。

VPN 的場合:
SecureBridge 是軟體 VPN 中的佼佼者。圖片來源: Devart
資料庫並不直接連上網際網路,而是透過加密的 VPN 連線,進而讓使用者能夠存取資料庫的資源。

利用 VPN 加密封包及分散處理的效果,達到資料安全性傳輸的功能。

只是連線數造成的資料庫效能低下仍不可避免,以及網路持續連接的能力讓人緊張,如果是跨國連線,恐怕網路穩定性會讓使用者抓狂。

遠端桌面連線的場合:
Windows 內建的遠端桌面有較佳的幀率

離資料庫越近的主機越好!只要網路連接有基本良率,就算斷線也只是畫面中斷,下次連線仍然可以接續上次中斷點使用。

最重要的是這種連線方式具有最佳的執行效能。

Citrix 的遠端桌面對網路頻寬的要求極低
但因為是畫面傳遞,所需的頻寬必須要有一定的水準,版權數和主機承載能力(兩者指的都是「財力」)是評估的重點。

而且,資料庫在大量連線時的效能損失的問題依然存在,可以保證的是使用者不會因資料庫連線異常導致輸入資料流失。

實戰上也有看到 VPN + 遠端桌面連線的雙保險機制同時被使用,提供給開發人員作為參考。


DataSnap 如何能解決兩層開發的問題?
1. 提供 HTTP / HTTPS 及 TCP/IP 兩種通協定,並且可以自定封包格式內容,被破解機率在這一關就大幅下降,等同 VPN 的防護機制。

2. 資料庫連線數問題,連線數太多會造成資料庫效能降低;但太少時所花在連線交握的時間也不會讓使用端占上太多便宜。這部份的微調可視實際場合使用「連接池」( Connection Pool )來降低連線消耗。

3. 連線不穩定的問題,如果 DataSnap 採用「無狀態」(Status-Less)設計模式,在離線狀態下仍能進行編輯工作,等到連線狀態穩定後再與資料庫同步即可;這和微軟提出的「公事包」概念有異曲同工之妙。

只是 DataSnap 要做到上述的功能,大都需要自己額外寫程式,看到這裡想打退堂鼓的人應該不少。

按照 DataSnap 歷史路線來看,想要省力開發也不是沒有方法,RemObject Data Abstract 就是其中一個很好的合作伙伴。
RO DataSnap Server 端設計畫面。圖片來源:RemObjects

所謂的歷史路線指的是:Borland 一直到現在的 Embarcadero 本身沒有足夠的資源可以完善 DataSnap Server 端,所以讓 3rd-Party 廠商來合作完善,各位可以驗證看看現在的路線是不是依然使用合作策略方式。

當然不甘寂寞的高手們(沒錯!指的就是現在看這篇的你!),DataSnap 也提供原始碼讓開發者來設計符合自己需求的 Service ,喜歡全架構運籌帷幄的開發者們快來挑戰吧!


雖然能解決這麼多問題,但在少量用戶端的場合時,傳輸效能上並沒有更優於(趨近於)現有兩層架構下各 DataSet (ADO, BDE, FireDAC) 的功能。

畢竟就是要透過 DataSnap 再轉一手資料庫封包,這是無法避免的現實。

--- 未完待續 ---

沒有留言:

張貼留言

Delphi 自動化 JSON 格式相容性分析

Delphi 自動化產出的 JSON 格式一直被詬病著,因為它的 JSON 格式在起始處一定會強制寫入「Meta Data」,它看起來像是: "table":[["EmpNo",6,0,0,0,4,0,0,false,false,...