在日常的開發過程中，本地代碼遠程調試一直是最理想的開發狀態。本文通過介紹京東集團內開發的一個輕量簡單的小工具”localhost”，從多角度的方案思考，到原理介紹，到最終的方案落地，在開發階段發現問題，解決問題。

背景

起源

在很早之前，我參加了一個技術分享大會，當時現場是分享了一個本地在遠程集群中的云原生開發方案，當時聽完了之后就對其中本地開發的同時可以遠程運行服務這部分非常感興趣，本身作為前端開發來說，確實每次驗證一些問題的時候，在本地開發階段無法在真實的環境中調試，需要本地測試，打包，發版，驗證，在處理一些兼容問題的時候，這個過程可能要重復很多次，會浪費很多時間。同時作為賽博云測的開發來說，在云測平臺上經常會遇到一些前端開發同學需要調試不同設備的兼容問題，有的甚至頂不住需要線下借設備。云測平臺存在的意義的就是能夠線上化解決一切移動端的問題，開發的問題也是問題。

痛點

試想這樣一個場景，測試同學上報了一個手機頁面打開白屏的問題，云測平臺上這個手機確實復現了這個問題，你搜索了一些可能的處理方式，然后修改發版驗證，發現并沒有用，這個時候該怎么辦。

或者后端同學提前開發完，發了測試環境給前端同學實時調試接口，需要不停的修改字段或者邏輯或者 debug 調試問題，這個時候該怎么辦。

又或者低代碼的開發同學，寫完物料組件之后想在實際設備中看看效果，但是不得不單獨找設備來看，或者等測試同學報 bug，時間都浪費在這個過程中，該怎么辦。

我想開發同學或多或少都經歷過這些場景，在聯調或者調試一些問題的時候，總是沒辦法做到本地改完代碼保存立馬就能查看。作為一個工具平臺，怎么去解決這個痛點并且能夠更好的和平臺結合，這個想法就一直在我心里存在著。

思考

從聽那場分享會的時候，我就已經在想有什么方案可以實現這個目的，當時分享中說到了云原生開發的本地代碼的處理部分，讓我沒想到的是，他們的方案非常直接，直接到將本地代碼 “搬” 到了遠程，實時在本地保存的時候將代碼同步到遠程的開發容器中，并且為了解決 http 協議傳輸的時間消耗，自定義了一套協議進行代碼的同步，當然這個方案對于我所設想的場景實在是大材小用了，不過真的非常膽大心細，也給我了很多思路。

在后面的時間，借著代碼同步的思路，我又設想了云 IDE 這個方案，本身代碼同步的目的就是希望本地代碼可以在遠程運行，那直接通過云 IDE 開發，并直接運行服務，這樣運行的服務也是在遠程的，可以直接訪問。這個思路是沒問題的，但是按照目前大家的開發習慣，云 IDE 不是長久之計，況且為了這個想法，開發一套云 IDE，為了一口醋包了一頓餃子，可以，但沒必要∠(? 」∠)＿。

之后又和有些同事聊前端開發的問題，聊到了這個想法，給我提供了一個新的思路，通過 whistle 代理和 webpack 插件的方式，webpack 插件以監聽模式打包，實時上傳編譯后的代碼到遠程服務器，whistle 代理用來解決調試過程中的一些問題。當然這個方案是公司其他的同學在很早之前就已經開發出來了，名字叫 Carefree，不過現在已經不維護了，比較可惜。這個方案只能解決前端開發同學的需求，并且云測平臺上我們對代理服務器有些單獨的處理，不是很適合。

中間又過了一段時間，我設想了一下這個需求的最終形態，之前的方案都非常重，如果我做為使用者，可能就是在難用和難受之間徘徊（沒有說之前方案不好的意思，只是不適合這個需求...），我想它足夠的簡單和輕量，沒有什么環境準備工作，拿來就能用。那最簡單的方式就是不在代碼上面下功夫，而是轉向服務，只要維護好服務上的請求和響應，能夠和本地進行交互，就可以達到我想法中所要求的。這個時候，我的想法聚集到了一個方向 —— 內網穿透。

市面上的內網穿透的應用有很多，這又涉及到了另一個問題，安全，如果內網穿透濫用的話，很可能會造成隔離的內網服務被映射到外網從而被攻擊，那損失就是把我賣了都賠不了... 并且私下使用內網穿透本身也不好控制和追溯，有很大的安全隱患。

糾結了很長時間，既然不讓偷偷用，那就光明正大的用，我可以自己實現一個應用，只要限制好功能和安全邊界就可以了（已經和安全部門報備過了，放心）。而且自己實現，可以滿足自己的所有想法，輕量簡單，和云測平臺結合等等，沒有什么可以比實現自己的想法還令人激動的事情啦。于是便有了下面的內容。

localhost 是什么

介紹

localhost 是一個使用 Go 語言編寫的輕量簡單的內網穿透工具。這個工具支持 web 服務的映射，會將啟動在本地 localhost 中的服務映射到遠程服務器上，在訪問遠程對應的服務時，實際請求會利用本地和遠程已經建立的隧道發送到本地服務中，達到訪問本地服務的目的。為什么要使用 Go 來寫呢，相對于其他的語言，Go 編譯簡單且編譯完沒有額外的運行環境要求，本地交叉編譯可以得到各類系統的可執行文件，對于使用者來說非常友好。

使用

幫助文檔在這里：localhost 幫助文檔，可以在幫助文檔里或者在賽博云測平臺的云真機使用頁面內進行工具下載。

就如上面說到的，localhost 是輕量簡單的，使用方式非常簡單，它是一個獨立的可執行文件，啟動的參數只有兩個，啟動方式如下：

# windows

localhost.exe -token xxxxxxxx -port xxxx

# mac

localhost -token xxxxxxxx -port xxxx

-token 這個參數是當次使用的 token，可以在賽博云測平臺的云真機使用頁面上申請，每次的有效期半小時。

-port 這個參數是當前本地啟動的服務的端口。

在設計客戶端這部分的時候，為了盡可能降低大家的使用門檻，特意將參數設計的盡可能少，port 端口參數是必不可少的，那為什么還設計需要一個 token 參數呢，這個參數的初衷是為了識別用戶的身份，類似于 ssh 協議的 key，使得行為可追溯，后來利用 token 來控制使用行為，比如單次使用有效期等等。其他的參數在不影響功能和安全的前提下，都被我排除掉了，希望它使用足夠簡單。

原理

整體工具分為三個部分：服務端，客戶端，web 端。服務端和客戶端是進行服務映射的主要部分，包含了建立通道，通道轉發之類的邏輯。web 端提供了一些交互的接口，路由聚合代理轉發的處理。

核心邏輯

localhost 最核心的部分就是內網穿透，它是由服務端和客戶端共同完成實現的。眾所周知本地啟動的服務，只能本地或局域網內訪問到，遠程設備無法訪問本地服務，但是本地的設備可以訪問遠程的服務，通過本地訪問遠程時建立的隧道進行通信，來達到遠程設備能夠訪問本地服務的目的。

整體流程圖如下：

localhost工具：本地代碼的遠程之路

首先在服務器中，啟動了 web 端部分的服務，是整體服務中的底層服務的調度部分，其中提供了一些 client 端調用的 web 接口以及用戶請求時的反向代理等功能，web 端服務是長期運行在遠程服務器上，在下面會詳細說明這部分做了什么。

client 端會分發給內部同學下載使用，在運行 client 端的時候，client 調用 web 的服務，啟動對應的 server 端，并且將相關參數信息傳入，并返回給 client 端。

server 端啟動的時候，會啟動監聽兩個端口服務，一個是監聽用戶請求的端口，一個是監聽 client 端這邊的隧道連接端口，當 client 端主動發起和遠程服務器進行連接時，通過當前這個連接打通通信隧道，當用戶請求進來時，通過已經建立的通信隧道，將請求報文轉發到本地 client 端。

client 端啟動完成，并且調用 web 端服務成功返回之后，client 端拿到相關信息連接對應的 server 端，隧道建立成功之后，等待服務端轉發過來的請求信息。當監聽到請求過來時，client 端會主動連接啟動的指定端口的本地服務，并且將請求報文轉發給當前的本地服務，同時，響應報文也會通過已有的鏈路原路返回，最終回到開始的請求方。

通過這種方式，就可以達到遠程訪問本地服務的目的，通過中轉服務器進行服務的穿透，并且這種方式不需要用戶關注中間過程，只需要啟動提供的 client 端服務，使用簡單，基本沒有使用成本，不會影響代碼。

路由聚合反向代理

使用過程中可能有的同學會有這樣一個疑問，在 client 端啟動完成之后，會返回顯示訪問的鏈接，為什么訪問這個鏈接就可以直接訪問到自己本地的服務呢？在 client 端啟動時，會調用 web 端的接口服務，這個時候會記錄當前的用戶身份，并且在啟動 server 端時，將啟動的 server 端口與當前的用戶 erp 形成一個映射關系，并且根據當前這個 erp 建立一個反向代理的規則。在 web 端啟動的服務中，有一個監聽當前請求的服務，當任何地方訪問 web 端的服務時，會對訪問的路由進行監聽判斷，如果能匹配到已有連接的 erp 信息，就會將當前訪問請求報文轉發到對應的 server 端服務中，然后 server 端再將請求轉發到對應的 client 端。

流程圖如下：

localhost工具：本地代碼的遠程之路

另外，在通過第一次通過聚合的 erp 路由訪問之后，會記錄當前訪問的 ip，將 ip 與 erp 映射關系也對應上，這樣，在后續的訪問中，路由可以不用攜帶 erp 信息，也同樣能夠映射到當前自己的本地服務，這樣可以解決一些靜態資源的訪問路徑的問題，也可以用來解決 history 路由訪問的情況。

未來

history 路由處理

當前端工程的路由采用的 history 模式的時候，在上述的 erp 聚合的路由就會出現 history 路由訪問不對的情況，雖然可以通過第一次訪問 erp 路由之后去除 erp 來訪問，但是總體來說還是會帶來一些困擾，后續計劃采用泛域名解析，去除路由上的處理，將用戶標識通過域名來解析，路由回歸用戶原本的樣子，這樣不會造成額外的困擾和理解上的成本。

支持 https

當前 localhost 工具在交互的過程中整體流程上還是 http 協議，目前只能通過把本地工程的 https 配置去除才能使用，但是和有的同學溝通下來發現有的工程中 https 請求是必須的，所以后續將會支持 https，后續設想在訪問時只要是 https 的請求，就默認訪問本地項目的 https，不需要額外的顯式配置或聲明。