Categories
程式開發

我在阿里做中後台開發


開發全流程在線化」近些年來熱度不斷攀升,比如 AWS 在 C9 的實踐、開源屆比較出名的 TheiaJS,到後起之秀 code-server、行業佼佼者 VS Online 等。我個人以及我們團隊對於「開發流程在線化」也做了較為深入的探索實踐,從開始的懵懂迷茫到現在的目標清晰。

我在阿里做中後台開發 1

從 WebIDE 講起

整個集團對於 WebIDE 的建設可以說起步較晚,當業界有了 Theia-IDE 的完整解決方案、coding.net 自己 CloudStudio 的商業模式,我們還在內部建設階段。但好的方面,我們基於 IDE 技術領域及相關工具平台在近期如雨後春筍般湧現: * * *Studio、 * * *IDE、K * * * 以及更廣義的可視化搭建設計器等。

我們團隊在 18 年調研過後決定基於 D * * * * * * *s 的 * * *Studio 來進行上層封裝滿足業務需求,後面由於種種原因不再適合放棄了。

19 年中,基於開源的code-server 和雲原生Kubernetes 的加持,我們自己打造了一款YunIDE,由於需要花費大量的精力去調度運維IDE 底層,這對於一個業務團隊來說也是很難變現的,在第一版本迭代完成之後也選擇遷移了。

code-server:

https://github.com/cdr/code-server

最後我們基於* * * *IDE 並結合XCloud 平台、Dawn 工具、雲查詢,打造了更加垂直易用的在線開發工具,打通了整個I2P(Init to Publish)在線開發流程,對特定場景化及外包同學開發提效起到了關鍵性作用。

Dawn 工具:

https://github.com/alibaba/dawn

我在阿里做中後台開發 2

自建的過程與挑戰

基本上 WebIDE 由三部分構成:

  • Client: 客戶端也是最重要的端,將代碼編輯等本地功能移植到瀏覽器中。
  • Server: 服務端也是控制端,包括管理數據交互及資源調度。
  • Container Pool: 運行時,用戶代碼真正運行的容器環境。

三者之間最典型的架構如下圖所示:

我在阿里做中後台開發 3

code-server 在很大程度上解決了Client 端的問題,其本身基於VSCode 二次開發,在體驗及一些編輯器基礎性問題上,我們不再去花時間重構,將重點精力放在Server 端和Container Pool。

服務端設計

YunIDE 從一開始就是面向雲上設計的,所以在真正討論架構的時候,更多的話語權在於使用雲上基礎設施& 業界開源工具,所以在用戶權限體系、容器資源調度、代碼文件持久化方式等問題上,都與彈內的大部分WebIDE 實踐有所區別,一張早期的架構大圖:

我在阿里做中後台開發 4

截止YunIDE 第一個版本迭代,整個服務端開發對我個人而言挑戰還是蠻多的,尤其是「資源調度& 編排」這部分,需要對容器、Kubernetes 有足夠深入的理解,對雲資源、網絡環境、集團現有基礎設施中間件有一定的了解和經驗。 WebIDE 資源調度本身就是一個追求極限的過程(誰不想自己的 IDE 冷啟動快一些呢),一丁點知識上的盲區都會帶來雪崩版的負面影響。

編輯器 & IPC

編輯器端我們最大化的沿用了Coder/VSCode 的實現,也就是這個原因,YunIDE 在最​​初的體感上要比TheiaIDE 更舒服更接地氣,而且通過對VSCode 擴展體系的繼承,可以獲得幾乎無限的想像空間。我們擴展的功能也通過 vscode extensions 來實現,區別於三方擴展,內建的插件無法被移除。

IPC 這一層除了 code-server 所做的工作,YunIDE 在 HTTP 應用層對 socket IPC 做了代理和 Hack,做了相應的鑑權與應用層適配。

我在阿里做中後台開發 5

關鍵性問題

資源利用率:資源的合理編排以及最大化利用永遠是我們追求的目標,在弱編輯場景(只編碼不調試預覽)如何在保證隔離性的基礎上共享資源:

我在阿里做中後台開發 6

保證高可用性:縮短運行時生命週期,同時也要保證用戶代碼文件不丟失。最理想的狀況是按 socket 連接數來動態的配置運行時容器,但技術上目前實現成本過高,只能以「小時/天」計算銷毀週期。通過 NFS 掛載用戶工作空間,用戶數據不依賴運行時條件,做到數據可恢復。

啟動速度優化:

  • 完全冷啟動:未知鏡像的情況很難優化,但垂直場景下可以做到 1 分鐘內。
  • 預置容器池 + Container Buffer:體驗很好,但造成一定的浪費。

插件生態:VSCode 官方插件體系已經足夠完善,但也還有精進的餘地,而且在集團前後端技術百花齊放的大背景下,界面的可定制性不夠強等缺陷就凸顯出來了(基於TheiaIDE 的方案則更加靈活),vsc 官方插件市場是公開使用的,但由於協議等問題不能被直接使用。

自此而終,自建WebIDE 的路上有過太多機遇與挑戰,也有了相當程度的技術沉澱,逐漸的我們考慮快速將業務場景落地到集團基礎設施,也就有了後面基於* * * * IDE 的I2P 全流程在線化戰役。

全流程在線化戰役

基於集團現有基礎設施如 * * * *IDE/K * * * * * 等可以很快構建垂直場景的在線開發環境,後面主要分享下我們的相關經驗沉澱與提效成果。

環境定制

跟幾乎所有 WebIDE 的環境準備一樣,開發運行時開箱即用通過構建相應的 image 來實現。由於我們團隊在前端基礎建設上有了很多沉澱,比如 Dawn 腳手架、雲查詢、XCloud 等,在定制環境時要求變得更加苛刻。

通過在 Web 端前置雲查詢的 QTOKEN 授權體系,我們可以在 WebIDE 的終端環境拿到用戶身份,甚至可以通過用戶身份調用很多需要權限校驗的接口。這極大的拓展了我們的可操作性,舉個例子,通過用戶身份可以很容易實現構建發布管控、日常錯誤收集、問題精準答疑等等:

我在阿里做中後台開發 7

同時鏡像中集成了團隊公共賬號的一些公共權限,很多弱權限行為都通過統一公共賬號管理和維護,比如:GitGroup 授權、npm package 發布、迭代關聯工作項等等。

插件開發

基於 * * * *IDE 封裝的 IDE SDK 進行深度的 UI & 功能定制,如下圖所示,封裝了常用 dawn/命令行 操作:

我在阿里做中後台開發 8

我在阿里做中後台開發 9

在點擊預覽的時候我們做了很多優化處理:

  • 由於插件運行在瀏覽器端,所以點擊「預覽」時通過 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:

  • 容器運行時啟動 dev server
  • 提供統一的域名 preview.ide.alibaba-inc.com 並通過 pathname 區分不同空間

WebIDE 方案 3:

  • 容器運行時啟動 dev server
  • 提供可變的泛域名來隔離不同空間 [uniqueId]-[port].id * * * * *io.aliyun.com

方案 1 可以有效解決問題,但非常麻煩,需要用戶手動綁定 Hosts 而且每次容器 IP 改變後都需要重新綁定,從產品的角度來說這個方案很不成熟,但也不失為一種降級方​​案。

方案 2不能解決前端開發的問題,無法處理HTML 中資源引入方式的多樣性問題,比如src=”https://images2-focus-opensocial.googleusercontent.com/gadgets/proxy?container=focus&gadget=a&no_expand=1&refresh=604800&url=/index.js” 和src=“index.js” 行為就會不一致,很容易導致資源無法正常加載、頁面無法正常預覽。

方案 3 比較完美的解決了上述幾個問題,但擴展性有所限制,每次新增一個業務域就要多申請一個泛域名。

最終,項目預覽的效果如下圖:

我在阿里做中後台開發 10

項目初始化

既然是 I2P 戰役,自然少不了重中之重的 init 環節,本來在本地是很簡單一行命令的事,在雲端卻不簡單。

  • 最開始的刀耕火種時代,我們自己維護了測試環境的 K8S 集群,使用 Jobs 來完成 init 操作。
  • 後面由於太麻煩,遷移到了 ECI。
  • 最後由於 ECI 沒有走「鏡像預熱」,導致初始化時間太長(1-3 min),又從 ECI 遷移到了其他編排系統。

ECI:

https://www.aliyun.com/product/eci

最終,這套 I2P 的成功實踐也被復用到了其他 BU、其他團隊,幫助其他業務場景快速實現「全流程在線化」。

場景化落地

從懵懂到篤定的過程中,我們搞清了這件事:找到你垂直的場景並發光發熱。我們避免把 WebIDE 設想成一個大而全的系統,而是一個小而美的工具。下面是我們已經紮根的領域:

  • XCloud VC 組件開發:中後台低代碼物料
  • 鴻蒙 ACE/國際站 組件開發:營銷搭建物料
  • Dawn 工程:服務於外包同學及其他快速開發場景
  • 雲查詢 FaaS:Serverless 場景快速項目開發

Dawn 工程:

https://github.com/alibaba/dawn

每個不同領域在鏡像、插件等層面做不同的兼容,整體入口收斂到 XCloud,最終完成 WebIDE 的場景化落地,同時也收到了許多肯定的讚許:

我在阿里做中後台開發 11

戰疫情,我們在行動

受疫情影響,很多同學不能正常復工,WebIDE 對於解決外包同學的開發環境問題顯得尤為重要,我們也非常重視,積極改善功能、維持穩定、隨時答疑,外包同學不再擔心電腦安裝各種環境的問題,從之前「幾乎一整天都在裝環境」到現在「打開瀏覽器WebIDE 就能開發上線」,真正做到了「開箱即用」。

下圖展示了從 XCloud 進入開發項目的過程:

我在阿里做中後台開發 12

最後

對文中內容有任何異議歡迎各位斧正。

作者介紹

趙吉彤,花名牧曈,阿里雲智能-銷售管理部前端工程師,負責前端基礎設施建設。

本文轉載自公眾號阿里巴巴中間件(ID:Aliware_2018)。

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489003&idx=1&sn=83a506debf5cc1c3a1921b658d7d0a04&chksm=fdeb278bca9cae9d6b8823a88cb3cbeb5c887dc3bd00848fbdb5882d3777bc14345ac8d44aa8&scene=27#wechat_redirect