導語
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雲端開發能力。
>>優勢
三月我們發佈了騰訊云云端開發環境白皮書之後，我們把Cloud Studio產研代碼和日常開發搬上騰訊雲 CDE 中。在白皮書中，我們定義了DevOps、容器化、代碼化定義CDE的零設置門檻、安全性是遠程開發環境的主要優勢。我們通過在最新的穩定版本內核及隔離環境之上，來運行每個開發者的代碼，從而大大提高安全性，譬如，我們定製了自動腳本，使得易受攻擊的應用程序代碼可以在非工作時間進行修補和更新。監控遠程開發環境的許多不同方面是相當簡單的，我們可以隨時檢測和識別惡意行爲，譬如挖坑、FQ等。由於在雲端開發環境中（背後是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 跨平臺客戶端開發
- 遊戲客戶端開發
