引言

項目需求，要求在瀏覽器端進行遠程桌面的訪問，如圖所示：

實現(xiàn)遠程桌面，需要依賴VNC協(xié)議：

VNC（Virtual Network Computing），為一種使用RFB協(xié)議的屏幕畫面分享及遠程操作軟件。此軟件借由網(wǎng)絡，可發(fā)送鍵盤與鼠標的動作及即時的屏幕畫面。

相關的參考比較少，去谷歌搜索出來的文章大多都是如何使用客戶端進行VNC的搭建與訪問，很少有將其內(nèi)嵌到web里的，騰訊云有相關的功能，但因為業(yè)務安全性，咱也看不著人家咋實現(xiàn)的。

再見，百度。用百度查了一次之后，我才知道原來VNC是口紅。

所以VNC實踐之路就是如下流程：

從整體的最開始設計，到最終落地方案，大約經(jīng)歷了以下七個方案的迭代：

實現(xiàn)

思想

整體思想如下圖所示：nginx轉發(fā)前臺的websocket連接，為了實現(xiàn)外網(wǎng)轉發(fā)，添加開發(fā)的node.js服務器作為代理，將瀏覽器端no-vnc的websocket數(shù)據(jù)報在運輸層轉發(fā)給目標主機。

why nginx ?

如果思考過的話，其實發(fā)現(xiàn)不用nginx也能實現(xiàn)功能，這里使用nginx主要是減少了前臺對后臺架構的耦合。

添加網(wǎng)關轉發(fā)所有請求，對前臺只暴露一個端口，不管后臺用什么技術，用什么架構，用什么微服務，在前臺看來，就好像在訪問單體應用一樣。

就像目前的華軟項目一樣，后臺用了spring-boot、.net、node.js，各語言各框架發(fā)揮各自的優(yōu)勢，通過nginx的轉發(fā)將各模塊連接起來，無論后臺的架構怎么變，對前臺毫無影響，這應該是微服務架構的最佳實踐。

這是spring官方推薦的微服務架構圖，我們學習并實踐了api網(wǎng)關，spring推薦netflix zuul，我們用的nginx，在請求轉發(fā)上，二者性能不相上下。

隨著業(yè)務需求的增長，我們肯定也會服務拆分，服務注冊，服務發(fā)現(xiàn)，消息隊列，RPC調(diào)用。然后用上eureka、zookeeper、hystrix、feign等一個個優(yōu)秀的開源組件，一起探索spring-cloud的最佳實踐。

websocket

之前一直不了解websocket，就是知道個名，具體細節(jié)沒有學習。

http協(xié)議：請求響應，客戶端請求，服務器響應，一次請求就結束。服務端無法主動向客戶端推送數(shù)據(jù)。

為了解決這個問題，websocket應運而生。如果所示，不做贅述。