作者：牧瞳
「開發全流程線上化」近些年來熱度不斷攀升，比如 AWS 在 C9 的實踐、開源屆比較出名的 TheiaJS，到後起之秀 code-server、行業佼佼者 VS Online 等。我個人以及我們團隊對于「開發流程線上化」也做了較為深入的探索實踐，從開始的懵懂迷茫到現在的目标清晰。
從 WebIDE 講起
整個集團對于 WebIDE 的建設可以說起步較晚，當業界有了 Theia-IDE 的完整解決方案、coding.net 自己 CloudStudio 的商業模式，我們還在内部建設階段。但好的方面，我們基于 IDE 技術領域及相關工具平台在近期如雨後春筍般湧現：Studio、IDE、K* 以及更廣義的可視化搭建設計器等。
我們團隊在 18 年調研過後決定基于 Ds 的 **Studio 來進行上層封裝滿足業務需求，後面由于種種原因不再适合放棄了。
19 年中，基于開源的
code-server和雲原生 Kubernetes 的加持，我們自己打造了一款 YunIDE，由于需要花費大量的精力去排程運維 IDE 底層，這對于一個業務團隊來說也是很難變現的，在第一版本疊代完成之後也選擇遷移了。
最後我們基于 **IDE 并結合 XCloud 平台、
Dawn 工具、雲查詢，打造了更加垂直易用的線上開發工具，打通了整個 I2P（Init to Publish）線上開發流程，對特定場景化及外包同學開發提效起到了關鍵性作用。
自建的過程與挑戰
基本上 WebIDE 由三部分構成：
- Client: 用戶端也是最重要的端，将代碼編輯等本地功能移植到浏覽器中。
- Server: 服務端也是控制端，包括管理資料互動及資源排程。
- Container Pool: 運作時，使用者代碼真正運作的容器環境。
三者之間最典型的架構如下圖所示：
code-server 在很大程度上解決了 Client 端的問題，其本身基于 VSCode 二次開發，在體驗及一些編輯器基礎性問題上，我們不再去花時間重構，将重點精力放在 Server 端和 Container Pool。
服務端設計
YunIDE 從一開始就是面向雲上設計的，是以在真正讨論架構的時候，更多的話語權在于使用雲上基礎設施 & 業界開源工具，是以在使用者權限體系、容器資源排程、代碼檔案持久化方式等問題上，都與彈内的大部分 WebIDE 實踐有所差別，一張早期的架構大圖：
截止 YunIDE 第一個版本疊代，整個服務端開發對我個人而言挑戰還是蠻多的，尤其是「資源排程 & 編排」這部分，需要對容器、Kubernetes 有足夠深入的了解，對雲資源、網絡環境、集團現有基礎設施中間件有一定的了解和經驗。WebIDE 資源排程本身就是一個追求極限的過程（誰不想自己的 IDE 冷啟動快一些呢），一丁點知識上的盲區都會帶來雪崩版的負面影響。
編輯器 & IPC
編輯器端我們最大化的沿用了 Coder/VSCode 的實作，也就是這個原因，YunIDE 在最初的體感上要比 TheiaIDE 更舒服更接地氣，而且通過對 VSCode 擴充體系的繼承，可以獲得幾乎無限的想象空間。
我們擴充的功能也通過 vscode extensions 來實作，差別于三方擴充，内建的插件無法被移除。
IPC 這一層除了 code-server 所做的工作，YunIDE 在 HTTP 應用層對 socket IPC 做了代理和 Hack，做了相應的鑒權與應用層适配。
關鍵性問題
資源使用率：資源的合理編排以及最大化利用永遠是我們追求的目标，在弱編輯場景（隻編碼不調試預覽）如何在保證隔離性的基礎上共享資源：
保證高可用性：縮短運作時生命周期，同時也要保證使用者代碼檔案不丢失。最理想的狀況是按 socket 連接配接數來動态的配置運作時容器，但技術上目前實作成本過高，隻能以「小時/天」計算銷毀周期。通過 NFS 挂載使用者工作空間，使用者資料不依賴運作時條件，做到資料可恢複。
啟動速度優化：
- 完全冷啟動：未知鏡像的情況很難優化，但垂直場景下可以做到 1 分鐘内。
- 預置容器池 + Container Buffer：體驗很好，但造成一定的浪費。
插件生态：VSCode 官方插件體系已經足夠完善，但也還有精進的餘地，而且在集團前後端技術百花齊放的大背景下，界面的可定制性不夠強等缺陷就凸顯出來了（基于 TheiaIDE 的方案則更加靈活），vsc 官方插件市場是公開使用的，但由于協定等問題不能被直接使用。
自此而終，自建 WebIDE 的路上有過太多機遇與挑戰，也有了相當程度的技術沉澱，逐漸的我們考慮快速将業務場景落地到集團基礎設施，也就有了後面基于 *IDE 的 I2P 全流程線上化戰役*。
全流程線上化戰役
基于集團現有基礎設施如 IDE/K* 等可以很快建構垂直場景的線上開發環境，後面主要分享下我們的相關經驗沉澱與提效成果。
環境定制
跟幾乎所有 WebIDE 的環境準備一樣，開發運作時開箱即用通過建構相應的 image 來實作。由于我們團隊在前端基礎建設上有了很多沉澱，比如 Dawn 腳手架、雲查詢、XCloud 等，在定制環境時要求變得更加苛刻。
通過在 Web 端前置雲查詢的 QTOKEN 授權體系，我們可以在 WebIDE 的終端環境拿到使用者身份，甚至可以通過使用者身份調用很多需要權限校驗的接口。這極大的拓展了我們的可操作性，舉個例子，通過使用者身份可以很容易實作建構釋出管控、日常錯誤收集、問題精準答疑等等：
同時鏡像中內建了團隊公共賬号的一些公共權限，很多弱權限行為都通過統一公共賬号管理和維護，比如：GitGroup 授權、npm package 釋出、疊代關聯工作項等等。
插件開發
基于 **IDE 封裝的 IDE SDK 進行深度的 UI & 功能定制，如下圖所示，封裝了常用 dawn/指令行 操作：
在點選預覽的時候我們做了很多優化處理：
- 由于插件運作在浏覽器端，是以點選「預覽」時通過 socket 向容器端發送指令查詢目前可用端口。
- 排除 **IDE 及插件自身使用的端口，排除外部不可通路的（0.0.0.0），排除非 Node 程序開放的端口，剩下的基本上是我們的目标端口，實際使用下來體驗也是比較好的。
- 通過内置的規則（倉庫、人員資訊、項目資訊）來判斷實際預覽需要用到的域名，感謝 **IDE 團隊的支援，目前我們可以在三個域名下進行預覽開發。
對接 **IDE 的過程中，前端項目的有效預覽問題我們這邊算是做了些小小的貢獻，推動了通過「泛域名解析」來完整的模拟本地預覽體驗。
本地方案：
- 啟動 dev server
- 綁定 hosts local.foo.aliyun.com 來擷取官網登陸狀态聯調接口
- 打開浏覽器
WebIDE 方案 1:
- 容器運作時啟動 dev server
- 綁定 hosts local.foo.aliyun.com 到容器的 IP
WebIDE 方案 2:
- 提供統一的域名 preview.ide.alibaba-inc.com 并通過 pathname 區分不同空間
WebIDE 方案 3:
- 提供可變的泛域名來隔離不同空間 [uniqueId]-[port].id*io.aliyun.com
方案 1 可以有效解決問題，但非常麻煩，需要使用者手動綁定 Hosts 而且每次容器 IP 改變後都需要重新綁定，從産品的角度來說這個方案很不成熟，但也不失為一種降級方案。
方案 2 不能解決前端開發的問題，無法處理 HTML 中資源引入方式的多樣性問題，比如 src="/index.js" 和 src="index.js" 行為就會不一緻，很容易導緻資源無法正常加載、頁面無法正常預覽。
方案 3 比較完美的解決了上述幾個問題，但擴充性有所限制，每次新增一個業務域就要多申請一個泛域名。
最終，項目預覽的效果如下圖：
項目初始化
既然是 I2P 戰役，自然少不了重中之重的 init 環節，本來在本地是很簡單一行指令的事，在雲端卻不簡單。
- 最開始的刀耕火種時代，我們自己維護了測試環境的 K8S 叢集，使用 Jobs 來完成 init 操作。
- 後面由于太麻煩，遷移到了 ECI。
- 最後由于 ECI 沒有走「鏡像預熱」，導緻初始化時間太長（1-3 min），又從 ECI 遷移到了其他編排系統。
最終，這套 I2P 的成功實踐也被複用到了其他 BU、其他團隊，幫助其他業務場景快速實作「全流程線上化」。
場景化落地
從懵懂到笃定的過程中，我們搞清了這件事：找到你垂直的場景并發光發熱。我們避免把 WebIDE 設想成一個大而全的系統，而是一個小而美的工具。下面是我們已經紮根的領域：
- XCloud VC 元件開發：中背景低代碼物料
- 鴻蒙 ACE/國際站 元件開發：營銷搭建物料
- Dawn 工程：服務于外包同學及其他快速開發場景
- 雲查詢 FaaS：Serverless 場景快速項目開發
每個不同領域在鏡像、插件等層面做不同的相容，整體入口收斂到 XCloud，最終完成 WebIDE 的場景化落地，同時也收到了許多肯定的贊許：
戰疫情，我們在行動
受疫情影響，很多同學不能正常複工，WebIDE 對于解決外包同學的開發環境問題顯得尤為重要，我們也非常重視，積極改善功能、維持穩定、随時答疑，外包同學不再擔心電腦安裝各種環境的問題，從之前「幾乎一整天都在裝環境」到現在「打開浏覽器 WebIDE 就能開發上線」，真正做到了「開箱即用」。
下圖展示了從 XCloud 進入開發項目的過程：
最後
對文中内容有任何異議歡迎各位斧正，歡迎交流：[email protected]。
Happy Hacking Online.
關注「Alibaba F2E」
把握阿裡巴巴前端新動向