DataSnap 能夠解決的問題？

 

作者：吳祐賓

 

Delphi.KTOP 的資深版主 Jason Wang 及 Sryang 等網友提供了很多相關資料，整理了以下內容： 多層架構可以解決兩層的四大問題： 

 

1. 省錢。
2. 跨網際網路的安全性。
3. 資料庫連線數大量增加，造成效能低下。
4. 一致性的使用者端應用程式開發。

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

 

跨網際網路的安全性問題

 

沒有任何一家公司會希望自家的資料庫遭受攻擊，在資訊安全這方面，我們會採用：

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

 

防火牆的場合：

 

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

VPN 的場合：

 

資料庫並不直接連上網際網路，而是透過加密的 VPN 連線，進而讓使用者能夠存取資料庫的資源。

 

SecureBridge 是軟體 VPN 中的佼佼者。圖片來源： Devart

 

利用 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 再轉一手資料庫封包，這是無法避免的現實。

 

--- 未完待續 ---