雲端開發環境，「開發者上雲」新起點

點選連結瞭解詳情

導語

Cloud Studio 團隊日常開發實戰案例自舉分享

本文著重分享Cloud Studio產研團隊是如何使用騰訊雲「雲端開發環境 Cloud Development Environment - 簡稱CDE」來改進日常開發-除錯-構建-執行的關鍵階段的開發者體驗。

Cloud Studio 產品是基於雲端開發環境的開發平臺，旨在化繁為簡解決本地開發諸多問題。

作者從團隊最初決定上雲實戰所遇到的挑戰、遷移上雲過程中的痛點、進而講解架構重構帶來的優缺點以及如何重點提升開發環境啟動效能、降低成本方面，並分享取得的進展。

最後，作者將給您留下一些關於「雲端開發環境」在當下及對於未來的機遇與想法。

01 初始痛點

Cloud Studio 的核心程式碼庫狀況

Cloud Studio 的業務場景相比於傳統業務專案是極其複雜的，各個模組形態不同，vscode 核心、外掛、各類檔案系統管理程式、動態的容器程式等多種形態的應用程式、十餘種程式語言、數十種後臺服務及針對各類程式的配套構建與配置工具。

久而久之，碎片化成為了 Cloud Studio 團隊大開發人員最大的痛點。具體來講，即依賴混亂、各模組版本難以統一、多工具碎片化使用成本高、難以協作及程式碼共享等。

移動到 Monorepo

為解決這些問題，我們制定了程式碼庫轉移策略，逐步將所有的程式碼庫轉移到統一的程式碼倉庫中，並建立了基於主幹的開發模型。

monorepo 的模式提供瞭如下的優勢：

更好的依賴管理
一致化的各元件、模組版本管理
集中式統一管理的構建平臺(由 CODING CI、 Bazel 等構成）
更便利的協作、文件共享、統一的目錄管理等。

Monorepo 挑戰

切換到 monorepo之後，我們發現另一個問題：雖然monorepo對穩定統一的開發流程奠定了堅實的基礎，但它使日常膝上型電腦上完成DevOps的完整研發流程（從程式碼編輯-提交-構建-執行-測試）變得具有挑戰性，如圖1：

構建更大，花費的時間更長
需要將幾 GB 的經常變化的工件下載到膝上型電腦或在本地構建
離開辦公環境，快速進行開發是一項挑戰。有時，克隆一個新專案並從頭開始配置本地開發環境，會花費數小時甚至一天的時間。

除了所有這些之外，維護一套一致的工具，並保持膝上型電腦上的本地開發也是需要我們關注並解決的問題。

圖1 workspace剖析圖

02 使用 Cloud Studio 進行遠端開發及自舉

我們問自己，既然我們做的是雲端開發平臺的事情，說了那麼多優點（可擴充套件性、享受雲資源、隔離性、隨用隨取等特點），可否把自己的大倉庫跑在雲端開發環境裡，用Cloud Studio產品特性來進行日常開發，從而不斷反哺產品體驗，不好用的體驗，自己發現自己嘗試去修復問題。於是我們進行了自舉道路。

什麼是騰訊雲-雲端開發環境？

當我們尋找解決方案來為我們的開發人員提供更快、更輕鬆和更安全的開發體驗時，我們開始關注遠端開發作為替代方案。在騰訊雲更快的機器上構建雲端開發環境，幾秒鐘內拉取，並將所有程式碼庫和工具儲存在安全、受控的環境中的想法。

這就是Cloud Development Environment 的初衷：基於Cloud Studio開發平臺構建CDE雲上開發環境。

什麼是 Cloud Studio？

Cloud Studio 是基於瀏覽器的整合式開發環境（IDE），為開發者提供了一個永不間斷的雲端工作站。使用者在使用 Cloud Studio 時無需安裝，隨時隨地開啟瀏覽器就能使用。雲端開發體驗與本地幾乎一樣，上手門檻更低；具有極強的開放性，第三方平臺透過我們提供的 SDK，則可以方便地整合Cloud Studio雲端開發能力。

>>優勢

ChatGPT 爆火之後，企業級雲端開發環境如何書寫未來？

三月我們釋出了騰訊云云端開發環境白皮書之後，我們把Cloud Studio產研程式碼和日常開發搬上騰訊雲 CDE 中。在白皮書中，我們定義了DevOps、容器化、程式碼化定義CDE的零設定門檻、安全性是遠端開發環境的主要優勢。我們透過在最新的穩定版本核心及隔離環境之上，來執行每個開發者的程式碼，從而大大提高安全性，譬如，我們定製了自動指令碼，使得易受攻擊的應用程式程式碼可以在非工作時間進行修補和更新。監控遠端開發環境的許多不同方面是相當簡單的，我們可以隨時檢測和識別惡意行為，譬如挖坑、翻牆等。由於在雲端開發環境中（背後是Kubernetes叢集）執行的 Kubernetes pod 沒有電腦的電池和資源限制，因此在下班時間掃描磁碟以查詢惡意工件或活動是微不足道的，但價值是巨大的。

>>效能第一

透過利用強大的騰訊雲資源——每個環境彈性提升到最多 32 個核心和 128 GB RAM 以及許多附加功能，更快的 Git、構建和 IDE 體驗，如圖2：

雲端IDE啟動：預熱常用的開發映象，秒極啟動雲端IDE，並根據雲端開發環境（CDE）的程式碼定義，安裝配置開發常用的language server、外掛等，讓開發者的體驗獲得最佳。同時我們保持核心常新。
\>>持續調優的 IDE 啟動鏈路，透過測試，平均2-3秒即可開啟，如下圖所示

圖2：分層架構

內網下載依賴構建：設定國內中央倉庫，找到最近的最快的網路下載位置；針對團隊內部開發，我們最佳化了網路方案，在產品上設定團隊依賴庫的快取能力，實現秒級掛載，無需額外重新下載。
透過以下方式改進了 Git 效能：
\>>採用Linux 檔案系統，與膝上型電腦檔案系統相比，效能更好
\>>Git 網路代理，內網訪問加速
\>>最佳化 Git 配置
透過以下方式改進了雲端開發效能：預載入所需的開發環境裡的外掛、預熱了映象啟動，預熱了依賴庫等；同時還提供了：
\>>提供更多計算資源，在編譯過程中彈性提升規格，在不用時降低高規格的佔有率。
除此之外，遠端開發環境還提供：
\>>每個使用者多個雲端開發環境
\>>獨立於膝上型電腦上執行的其他程式進行隔離。在開發上可以做到真正並行。

>>環境程式碼化和維護

Cloud Studio 支援 workspace.yaml的視覺化定義配置（Cloud Studio 高階玩家：強大的 YAML 模板），併為該配置儲存成「自定義模板」，這些模板為團隊成員的monorepos 倉庫的雲端開發提供了極大的價值：

易於配置——視覺化UI介面配置，無程式碼的方式即可配置出自定義的新環境配置
支援任意本地的IDE——預配置預設啟動的IDE型別
在幾分鐘內訪問一致的開發環境
每個 monorepo 所需的預安裝環境裡的工具、依賴配置、外掛和測試工具等
預克隆儲存庫，為儲存預熱，用得多啟動更快

>>安全性

無需擔心程式碼檔案被竊取，Cloud Studio 提供的持久化工作空間，會進行特殊加密（詳細文章見：Cloud Studio 雲端開發保障企業原始碼安全）：
\>>受控的開發環境-僅安裝安全可靠的工具外掛，禁止手動安裝非認證外掛等
\>>安全的數字水印- 不干擾寫程式碼，但是當準備複製到開發環境之外，我們會針對內容進行加密，防止程式碼被帶走。
\>>禁用複製貼上和下載能力，但對當前工作空間依然有效。
安全性，可透過開關根據所需開啟或關閉。
環境保持最新狀態——開啟自動更新能力，我們會在夜間自動更新最新的外掛，進行安全升級，掃描環境裡的安全問題：
\>>更安全的工具鏈——預先定義好的的安全環境，受管控的安全的安全工具鏈
\>>更安全的軟體供應鏈
\>>無縫配置更改---- 支援底層基礎映象切換、版本切換等，一鍵熱啟動即可享受新環境，且當前開發狀態不丟失。
\>>團隊級別外掛市場，可使用最新外掛自動更新
\>>可以在將映像釋出之前對映像執行安全掃描

Cloud Studio 提供的工作空間是持久的，因此工程師無需擔心丟失他們的個人設定、檔案和程式碼更改。這允許工程師在不同的裝置上繼續他們的工作，並支援多個工程師在單一環境中進行協作。

Cloud Studio 本土化雲端開發平臺

>>提供主流開發語言環境

我們為中國開發者打造更適應國人開發習慣的開發平臺，同時內建了數十款的基礎開發環境的模板庫，包括所有必需的基礎映象，並預載入了預設設定、預置常用外掛和開發配置。我們目前支援以下開發環境的語言，如圖3：

C/C++
Html
C#
Java及Spring框架
js及Nodejs周邊框架
Go
Python 及 Flet 框架
Flutter 及 Andriod 開發
Vue React Angular 及其他前端框架

圖3：開箱即用的配置

>>基於 Web 的開發空間控制檯

Cloud Studio 為登入使用者提供了專屬的控制檯，為使用者管理自己的工作空間狀態，消耗資源情況，製作個性化的專屬模板、徽標，團隊管理及團隊資源情況，滿足簡單個人開發到複雜的企業級開發的訴求，如圖4所示。

圖 4：Cloud Studio 控制檯

03 Cloud Studio 開發環境架構

圖 5：Cloud Studio 控制檯

如圖5所示，在 Cloud Studio 中，所有的個人環境全部被放置在容器環境中，這使得開發者可以使用官方提供的各類版本，還可以輕鬆地透過 Dockerfile 定製自己的環境，並且即使脫離 Cloud Studio 也能夠被應用在任何地方。在容器之上，Cloud Studio 會為使用者提供額外的開箱即用的軟體包，這包括了使用者的編輯器介面、Docker、kubectl 等常用開發工具。

如圖6，我們統一提供了 Ubuntu 作為開發作業系統，Ubuntu 作為全世界最流行的 Linux 發行版，最符合開發者使用者的使用習慣。其建立在 Debian 之上又天然可使用大部分 Debian 生態下的工具鏈，從而可重用大部分現有生產環境基礎設施。

圖6 Cloud Studio 映象層次結構

從本地電腦遷移到雲，使得能極大地最佳化享受雲上更豐富的計算資源，海量的計算核心和高效能的大容量 GB RAM 的機器。最重要的是，我們決定使用 kubernetes，基於騰訊雲 TKE、EKS 及高速穩定的叢集能力，給我們提供了我們所需要的 IaaS 能力：

在強大的硬體上託管容器的能力
連線容器並支援並行執行
用於在重啟之間儲存開發過程中的檔案，並持久化到NFS的持久卷中

面向Kubernetes的標準化底層容器

我們使用Custom Resources | Kubernetes CRD來完整的描述一個工作空間資源，這使得即使脫離 Cloud Studio 平臺，使用者也可以直接透過 kubectl 自行建立、排程、訪問 Cloud Studio 的工作空間 pod。

在 CRD 中，我們擴充套件了 PersistentVolumeClaim 特性，以支援任意的外部持久化資料，而不僅僅侷限於 Cloud Studio 自身所使用的全域性 NFS 持久化。在後續，我們計劃支援響應 VolumeSnapshotContents 變化，從而降低不使用時的儲存成本。

圖7：Cloud Studio CRD

04 挑戰

為工程師創造完美的環境並非易事——我們在此過程中遇到了一些挑戰。在效能和成本效率之間取得平衡、提供自動升級、確保不間斷工作以及預配置適用於每個人的 IDE 設定是我們必須克服的一些障礙。

IDE 核心選型

工程師每天都在使用 IDE，因此沒有良好 IDE 體驗的遠端環境是無法成功的。在雲端開發環境裡，我們提供了多種不同的 IDE 核心選項：

Cloud Studio Web IDE 核心
VS Code Remote SSH
JetBrtain Remote SSH JetBrains Gateway - Remote Development for JetBrains IDEs

>>Remote SSH 連線方式

如圖8所示，任意Pod所啟動的雲端開發環境，都可以用喜愛的本地IDE進行連線，保留喜歡的主題、熟悉的快捷鍵。充分利用雲端開發環境的優勢。

圖 8：透過SSH的工具訪問雲端開發環境

透過 SSH 連線雲端 IDE 工作空間 | Cloud Studio

除了提供多種 IDE 選項外，我們還專注於透過以下方式微調動手體驗：

預載入索引
預配置設定
預安裝工具、擴充套件和自定義附加元件

Cloud Studio 基於彈性算力和持久化儲存，為使用者提供快速開發的雲端開發體驗，但是擺脫本地主流IDE 轉到雲端開發，從早期開始就是我們最大的挑戰之一。特別是，早期流行的基於 Web的 IDE 的延遲問題以及隨後的一些穩定性問題給我們帶來了很多困擾。

後面我們發現，Web 的IDE和本地的IDE應該是共存，我們應該致力於建設並推行雲端開發環境的理念，並與之企業研發的降本增效訴求、DevOps研發一致性，進行助力

使環境保持最新

由於工程師珍惜他們的時間，提供一個不需要手動維護的環境很重要，因此，我們在非工作時間使用最新的工具和安全更新自動升級環境。

為了滿足每個人的需求，我們允許工程師從四種釋出節奏渠道中選擇一種：

stable——預設一個
rc——下一個穩定版的候選版本
dev – 每晚更新到最新的成功構建
none ——沒有自動更新

無論工程師想要最穩定的環境和最先進的功能，還是根本不需要任何升級，我們都能滿足。

後來我們改進了自動更新以支援逐步推出新版本。新增此功能是為了減少爆炸半徑，以防錯誤透過我們的自動化測試和候選釋出、內部測試過程。

成本效益

從很多客戶側發現，有構建與購買資源的情況並不少見。和企業合作、騰訊雲Serverless、基於Cloud Studio產品自我開發的過程中，我們不斷跟蹤監控，並改進Cloud Studio 的成本，並確保 Cloud Studio 的價效比優於其現成的替代品。

為提高資源利用率，實現更好的成本控制，我們將自建 K8s 叢集遷移到騰訊雲 Serverless 容器服務（原彈性容器服務EKS）中，我們的目的是將資源上雲，充分利用雲天然資源利用率和運維成本的優勢。

為了實現上雲，我們做了大量的架構重新設計，首先將工作空間所依賴的特化特性全部重新設計：

去 OCI Hook 特性依賴：在之前工作空間資源持久化我們是利用了 CRI 標準中的 OCI Hook 特性實現的使用者持久層的 save 與 load，具體來講是在容器啟動過程中，替換映象的 upper layer 為我們為使用者準備的 ext4 虛擬磁碟持久化資料。而在雲上，顯然我們不能利用這類特性，因為我們無法充分預估底層 runtime 是否一定相容 OCI Hook，為此我們重新設計了使用者容器，採用兩層架構，在外層，我們用標準容器提供一個標準環境，接著在此環境中執行一個 podman 容器，然後透過內層 image inspect 拿到層資訊並將使用者持久化層組裝成最終的 rootfs 提供給 podman 執行。

去 DaemonSet 特性依賴：Cloud Studio 團隊十分看重容器啟動效能，而 Ops 視角出身的 k8s 天然又不特別關注容器映象下載速度的問題，因此為了提升使用者所需容器載入速度，在之前，我們使用了 DaemonSet 為每個節點預熱所有使用者所需要的基礎映象，從而保證了使用者映象的載入速度，但 DaemonSet 的特性天然與雲衝突，因為雲的理念是使用者不關心節點資源，為了處理這個問題，我們完全重新設計的使用者容器映象預熱邏輯，我們除了按需向 k8s 提供資源需求之外，又引入了一層快取，也就是說會提前向 k8s 申請一起 pod，與之前不同的是如果我們申請的是節點，那麼節點的資源是固定的，而申請一批 pod 不同，我們結合業務需求，完全可容忍一定的資源超賣，因此我們申請的資源的 request 都極少，同時又使用 limit 去限制了容器的最大資源保證儘量平衡資源要求，最後結合 k8s 排程又設計了重新排程的策略，對每個快取 pod 進行評分為每個使用者選擇表現最好的 pod 供使用者使用。

除了這些較大的邏輯變動外，我們還有很多其他的例如流量匯入策略、實時計費資訊採集等多個最佳化點，最終形成了一個真正貼合雲原生設計又能滿足極大資源利用率的工作空間設計，下面是變更示意圖：

圖9: 資源利用率 - 每個Pod 五臟俱全

我們提供了全持久化能力，相比友商更具有使用價值。由於引入了NFS，我們必須確保我們有效地使用計算和儲存資源，因此我們實施了幾項改進：

關閉非活動環境：為了節省計算資源，自動化作業會定期檢查最近是否使用過環境，並在檢測到非活動環境時刪除其容器。
重新平衡 VM：由於多個環境被放置在一個大型虛擬機器中，並且我們為 VM 付費，因此只有充分利用一個虛擬機器才有意義。因此，如果有兩個 VM 僅使用了其容量的一半，我們將負載轉移到一臺機器上並關閉另一臺。
關閉環境的快照磁碟：Cloud Studio 需要一個容器和一個磁碟才能執行。當我們關閉容器時，磁碟不再被使用，所以我們將其轉換為低成本儲存選項，直到環境再次啟動。

到目前為止，我們儘量控制我們的成本下，極力去最佳化提高效能和使用率，與老的開發環境相比，提升效果非常顯著。

產品監控指標

Cloud Studio 跑在了TKE叢集之上，標準的K8S之上，如圖10，並定義了全鏈路的效能指標。我們透過各種快取方案，實現並突破了效能極限。

圖10: 基於K8S（TKE）基礎之上的雲端開發環境的效能指標定義

我們最佳化前， Cloud Studio 冷啟動耗時大約 19S。我們分析了各類典型場景，最終繪製出了主要阻塞點的耗時情況：

圖11: 阻塞點

同時針對 inspect 這一嚴重阻塞項我們分析了其與節點中容器數量的關係：

圖12: 分析

經過持續最佳化後：

圖13: 最佳化後

冷啟動時長降低到了 5-7 S。二次啟動時長降低到了 5S 以內。

我們的進展

啟動效能持續最佳化，當前透過預熱最佳化，我們已在內部實現了冷啟動與二次啟動穩定 4S 左右的耗時，後續逐步上線線上環境。
透過常駐熱點工作空間，使得高活躍度的工作空間二次啟動時間縮短到 2S 以內。
我們後續計劃針對各類常用模板進一步預熱，使得大部分場景下，使用者冷啟動工作空間也能達到 2S 左右的時間。
計劃最佳化工作空間啟動的錯誤反饋，使得使用者能夠更容易去發現並解決問題。
IDE 啟動最佳化，實現毫秒級 IDE 介面載入。

05 雲原生開發除錯+雲端開發環境

雲原生除錯是我們在雲端整合開發環境中關於測試左移又一思考，從 IDE 本身出發，將雲原生服務開發除錯也作為 IDE 中的一環，使得任何開發者能夠在 IDE 編輯器中一鍵部署起全套的雲原生應用，並輕鬆使用當前程式碼針對當前關心的一個或多個服務劫持服務流量，開啟斷點偵錯程式進行除錯或與其他團隊成員進行實時聯調。

2021年底CODING團隊貢獻了Nocalhost框架到CNCF，在接下來的時間裡，Cloud Studio團隊一直致力於將Nocalhost與Cloud IDE進行結合，來實現開發叢集下的開發聯調、測試左移。透過叢集下的專屬namespace，以及Cloud Studio團隊能力正交，嘗試讓團隊可以簡化雲原生開發階段，並能更左移的發現問題。如圖14，John和Peter在一個開發叢集的一個namespace進行前後端聯調，透過服務Pod的替換切入替換成Cloud IDE，進而除錯發現問題。特此錄製了一個影片來簡單介紹一下。

圖14:資源服務化

06 雲端開發，更多契機場景

未來已來，雲端開發，是一種抽象但具有價值性落地的基礎建設。在有AI可見的年限中，有著更多無限可能。比如，AI+雲端開發=Code Interpreter 或者是 AI的Cloud Development Environment，或者更多更高的場景。

我們將 Cloud Studio IDE 視為雲端開發環境的一種產品實現。我們的目標是使企業級工程師的遠端開發完全無縫。我們正在致力提升：

>>秒級的彈性分配容器

我們希望透過監控判斷較慢的地方，比如消除非同步狀態，提升預熱命中率等一系列手段，致力於將分配並啟動開發空間減少到 3 秒以內。

>>短暫的開發容器

當解決並提升到啟動的極致之後，我們希望從開發人員可以講Cloud Studio 作為構建整合。我們預見了短暫的 Devpod 的以下用例：

Devpod 特定於功能開發
簡單快速的失敗 CI 除錯
隨時可用的程式碼審查環境
分析移動崩潰

>>更省資源的雲原生除錯

雲原生Mesh方案帶來的流量劫持和染色，可以使得雲原生基礎架構下的開發除錯和雲端開發環境一起，爆發出企業級的新產品。

>>無中斷自動升級和維護工作負載

目前，在非工作時間為環境設定了維護視窗，但是，一些工程師可能希望在非工作時間工作或在其環境中執行更長時間的工作負載。因此，可以透過監視活動連線和推遲維護工作負載來進行改進。

>>提升無縫的 IDE 體驗

當工程師在膝上型電腦上本地使用 IDE 時，它應該在後臺隱藏遠端環境實現。IDE 會在後臺靜默連線到遠端環境，並在有足夠好的可用網路的情況下提供強大計算能力的所有好處——如果遠端環境出現任何問題，它們不會被阻止，並且可以在本地無縫地繼續工作。

>>特定團隊的配置

我們正在尋找方法來最大程度地減少使用團隊的首次設定的門檻。我們希望改進的領域之一是允許團隊（程式碼化）自定義他們的配置，以便新的團隊成員只需單擊一下即可獲得根據他們的需求量身定製的一致開發環境。

>>本地電腦和雲端開發環境之間的無縫檔案傳輸

我們嘗試探索計算型開發的場景探索，譬如用於計算密集型任務和長時間執行的編譯構建。在某些情況下，開發人員需要在他們的膝上型電腦和 Cloud Studio 雲端開發環境之間移動檔案（反之亦然）。我們的目標是將 Cloud Studio CLI成為本地驅動器，自動安裝到使用者電腦上，從而可以無縫移動檔案。

>>vGPU

我們正在嘗試構建基於騰訊雲 gpu-manager 的 vGPU 方案，這將可能幫助到以下開發需求：

AI 模型訓練
GUI 跨平臺客戶端開發
遊戲客戶端開發

雲端開發環境 ，「開發者上雲」新起點

導語