作者介绍

孙力： 基础架构资深Java开发工程师

屈晶晶： 基础架构高级前端开发工程师

一、前言

当前的软件系统越来越复杂，越来越多的开发者使用各种 IDE 、中间件来简化自己的软件开发过程。在这样的背景下，传统 IDE 产品的局限性日渐显现，开发者不得不学习更多的技术，引入更多的工具，花费更多的时间在开发环境的管理和维护上。

去哪儿网拥有大量的前后端工程和应用，每个工程所需要的代码编辑器，运行时，SDK，中间件，应用服务器，配置以及底层操作系统可能都不一样，而传统 IDE 工具在可开发性上做的很好，但都无法解决如上所述的开发环境依赖问题。

那么对于前后端工程师来说，如何在当前人力紧张、远程办公、项目不熟悉的情况下，随时随地快速着手开发和发布项目？对于团队来说如何保证团队开发环境的标准配置化的统一，让开发者按照规范工作？带着这些问题，参考云原生实践，基础架构团队实现了去哪儿网 WebIDE 云开发平台，面向多种业务场景提供了标准的容器化的开发环境，对开发者来说大大提升了效率和便捷性。

云开发平台在公司上线后，已接入前后端大多数业务场景，机酒火车票等业务线都在实际开发中使用，云开发工作区月活400+，并且根据业务线同事反馈，对比传统本地开发，首次启动并开发的项目，云开发效率提升80%，日常开发业务场景，提升60%。

二、背景

（一）常见问题

作为一名开发人员，你遇到过下面这些问题吗？

环境搭建成本高： 代码五分钟，搭建环境两小时。当我们要对一个新项目修复 bug 时，很可能代码改写只需要分钟，但安装环境花了两小时。

项目无法启动： 按照项目文档，依旧启动失败。作为一个新人，或者说接手一个新项目的时候，按文档教程安装环境，项目依旧跑不起来。这个有可能就是某个依赖的版本安装的不匹配或是文档没有及时更新。

开发环境差异大： 团队开发同学由于本地开发环境差异大，导致启动失败或问题不能复现，耽误开发工期。

联调测试困难： 前后端联调时，前端总是需要发测试版本才能让后端和产品同事看到页面效果。如果有一些需要频繁修改的内容，那么发版就是一个很大的时间成本。

不能随时随地： 当我们休假的时候，为了保障业务的稳定，必须得带着办公的电脑，那如果现在有一种方案可以不需要那么合适的设备即可办公，是不是就解决了 24h 待机的问题。

以上都是我们在传统开发中常见的问题，云开发就是为了解决这些问题出现的。

（二）传统开发 vs 云开发

我们一直在提云开发，那它的工作模式到底是什么样的，我们来对比下它和传统开发的区别所在。

左边是传统开发的流程，可以看到，它的整个工作区重心是在本地，需要开发者自己去安装 IDE ，搭建依赖环境，自己去 gitlab 上拉取代码。开发完成后再去到发布平台去发布。

而云开发呢相对于传统开发，它的工作区重心从本地转移到了远端工作区。开发者无需关心 IDE 安装、代码拉取，更重要的是环境依赖安装，这一步呢其实就解决了我们先前提出的环境搭建问题。同时，在远端工作区启动服务后，会对外暴露一个服务的地址，这个地址可以在内网环境被所有人访问，这样的话，也就免去了每次都要发测试版本联调的问题。那对于开发者来说，本地只需要一个浏览器即可。我们不需要那么合适的设备即可快速上手开发。这样看下来，云开发相对于本地开发确实是有着一些独特的优势，那我们来总结归纳一下。

（三）云开发优势

1、开箱即用，直接进入开发

云开发环境会根据业务场景提前预置需要的依赖，用户无需关心软件安装、IDE 配置、环境依赖等问题，可直接进入编码工作，大大节省时间。

2、开发环境标准化

根据不同语言环境、软件安装、环境依赖等，直接提供给开发者标准的符合业务场景的开发环境，也利于团队做到配置化的统一，按照统一规范去工作。比如当团队协作开发时，我们每个人本地安装的环境版本是否一样，是一个非常重要的开发问题，即便开发环境有很详细的文档，也很难把所有的细节都写清楚。

举一个例子，像前端同学经常用的 npm 包，如果发版很频繁，想周知给其他同学只能是群里发公告，然后其他人再去更新，一来一去增加了非常大的时间沟通成本。那如果用了云开发，就能避免这些问题。因为云开发平台可以通过镜像模板快速为用户提供包含了语言环境，业务场景依赖及公共配置，并集成常用IDE及开发插件的标准化开发环境，开发者省去了建构开发环境的时间，也不会因为开发环境的差异造成不必要的问题。

3、闭合研发链路

公司团队很多，各个平台的产品层出不穷，开发阶段中往往会伴随多个平台的切换，云开发可整合各个研发平台，这样的话避免反复切换平台带来的繁琐与不便，打通研发链路生命周期。

4、随时随地，便捷性提升

在远程办公的情况下，不必需要合适的设备即可写代码，对便利性也是极大地提升，开发同学可随时创建随时上手开发。

所以综合来看，不论对个人还是企业来说，云开发都有着非常大的优势。这些很大程度上可以提升开发效率，助力研发效能。

三、整体方案

（一）名词解释

• cms：Qunar 低代码平台业务
• qrn：Qunar 的 RN 业务
• qzz：Qunar 的前端静态资源

（二）系统架构

1、Web&客户端

客户端主要分为浏览器和本地 IDE 远程访问两种模式。支持的远程 IDE 类型，浏览器模式支持 vscode ，本地IDE远程访问支持 vscode，Jetbrains系列的IDEA、WebStorm等。

2、工作空间

· 用户开发编码主要就是在工作空间进行，从右侧的明细可以看出，主要分为静态的镜像和动态的运行时两部分。

镜像：根据 操作系统、语言环境、IDE、业务场景 从下到上分为4层，可根据需求自由组合，满足多种场景需求。

运行时：指用户创建云开发环境后确定的运行时环境中的 用户代码，环境变量，IDE配置，自定义插件等。

· 工作空间生命周期：根据用户的使用情况，工作区会经历从创建，到启动初始化，正在运行，到用户不使用后的暂时离线，超时资源回收，以及最后的彻底销毁，完成整个生命周期。

3、云开发管理后台

· 用户工作区的调度管理，创建、离线、销毁等生命周期管理。

· 用户信息管理，如 公私钥密匙配置，IDE 配置，自定义插件等。

· 用户行为监控，收集用户使用数据，用于对云开发环境的弹性回收和重建，数据统计等。

4、容器管理

包括容器的创建和销毁，数据持久化，对运行中容器远程执行命令以完成特定操作等。

5、依赖服务

主要依赖了代码服务、Melaka K8S API 服务、OR 暴露服务域名、对象存储等公司内部依赖服务。

（三）IDE 远程开发方案选型

我们对云开发平台的设计初衷是前端和后端开发都可以使用，不局限于某种 IDE 的开发平台，所以在做 IDE 远程方案选型时需充分考虑其成熟度、可扩展性、可集成度，以及和公司开发现状的匹配与结合。在前期以前端开发场景+浏览器模式作为切入点。以此为目标，开始了对业界 IDE 远程开发方案的调研和技术选型。

Theia

Theia 是 Eclipse 推出的云端和桌面 IDE 平台，完全开源。目前star数有16K。Theia 是基于 VS Code 开发的，它的模块化特性非常适合二次开发，比如 gitpod，华为云 CloudIDE 、阿里系 IDE 便是基于 Theia 开发。

code-server

code-server 是由 Coder 开发的，目前star数有52K。它的理念是把 VSCode 搬到了浏览器上。

vscode 是基于electron架构，大家都知道 electron 它的 UI 最终是运行在 chrome 浏览器中，这整个和 web 架构在UI层是天然相通的。

vscode 底层架构源是 typescript，那 typescript 对于前端同学是相对于比较熟悉的，对于我们后面进行一些源码结构改造提供很好的可拓展性，可定制性。

vscode 有个最大的优点，它为什么能够发展到现在这个程度，其实和它的插件机制是有关系的。vscode 本身的功能其实不是很多，其他的功能都是以插件化的方式插入到 vscode 里面去。

stackblitz

stackblitz 是一款非常方便写 demo 的 IDE 。提供了非容器化方案的纯前端 node 环境，可以说非常有价值 整体来讲，其技术方案的优点在于不消耗远程资源，但是缺点，一个是不开源，另一个是毕竟是模拟的 node 环境，在系统的一些层面可能会有所缺失。

JetBrains Gateway

JetBrains Gateway 是 JetBrains 主推的“远程开发”解决方案，基于 Client + Server 架构，使用 SSH 方式连接 ，延迟低，网络流量低，可复用用户本地的主题、快捷键、配置等。

通过调研及验证，从社区热度、可用性、可扩展性、公司内前端开发场景匹配等角度综合考虑，最终我们选择 code-server 开源版作为前端开发+浏览器模式的 IDE 远程开发方案选型，虽然其没有 Theia 的可扩展性那么高，但基本满足我们的要求，而且其使用体验上要好不少，社区热度一直很高。当然对于选用哪种 IDE 远程开发方案，在设计时完全是可拓展的和可替换的，我们会对 IDE 远程开发方案整个使用过程中的共性做抽象，统一考虑，并在设计云开发工作区镜像分层时将其独立出来，这个在下面描述镜像架构时会提及。

（四）镜像架构

在方案初期，我们确定了首个适配的业务场景，并与开发团队做了多次深入的沟通，以此为基础梳理和设计出了镜像架构。

起初，我们首个适配接入的是 cms 低代码场景，原因是它短频快的开发模式和云开发即开即用的特性很契合，cms 业务覆盖面大，像机酒火车票市场等等都在使用，而且入手难度低。与开发团队沟通后得知，IDE 使用方面以 vscode 居多，其次是 WebStorm 。再考虑后续其它业务场景的拓展性，如接入 qrn、node、h5 等，依赖和定制化需求可能各有不同。通过分析这些场景使用的异同点，基于容器镜像本身分层的天然特性，以及我们要适配多种操作系统、多种语言环境、多种 IDE 类型以及整合多种业务场景的目标，也参考了开源项目如 gitpod 等镜像设计思路，我们设计出了如下的 4 层镜像架构图。

镜像按照分层设计分为了 4 层，从上到下分别是：

1、业务场景层：包含业务场景下特定的环境依赖，开发工具以及自定义脚本。目前已经支持 cms、qrn、node&qzz、rock、java 等场景。涵盖了公司内部大部分业务开发场景。

2、IDE 层：封装了常用 IDE 及 IDE 定制配置，如 vscode 浏览器端的 code-server、Jebtrains WebStorm、IDEA 等，还包括 IDE 相关的公共插件扩展，启动脚本、用户行为监控脚本。

3、语言环境层：包含 nodejs、java 等开发语言环境支持能力。

4、操作系统层：目前支持 centos、ubuntu 两种底层操作系统，并集成 zsh 等用户开发中常用系统软件。

镜像的分层是基于我们对最终满足用户开发场景工作区的分类、整理，和便于重用，以快速的支持新的场景。我们最终的镜像就是由这四层基础镜像交叉组合成的，这样便于快速支持多种操作系统、多种语言环境，多种IDE类型，以及多种业务场景。

（五）初具雏形

有了以上的方案及是实现，再通过域名 +URL Path 方式暴露云开发访问地址后，用户就可以开始进行代码编写、运行、debug、提交代码等等一系列常规操作了。示例效果如下图。

这就是浏览器中使用 WebIDE 云开发的操作界面，可以看到，用户界面与 VS Code 非常相似，用户可以在浏览器中使用 VS Code 的编辑器、侧边栏、终端等功能。但是，由于运行在浏览器中，一些高级功能（如全局搜索和调试）可能会受到限制。VS Code 的用户界面则完全运行在本地计算机上，提供更好的性能和体验。

调试方面，WebIDE 提供了调试功能，但需要用户手动配置调试器。VS Code 内置了调试器，并提供了可视化的调试界面和调试功能。

插件方面，WebIDE 可以使用 VS Code 的许多扩展，尽管不是所有扩展都能正常工作，但我们平常使用的大部分都是支持的。

目前已经基本可以让用户体验和使用，但距离好用易用、深入业务场景，提升开发效率还有一些差距，也是我们后面要处理的核心难点问题。

（六）核心难点及解决方案

业务场景落地

为了提供给用户更好的开发流程体验，在云开发结合业务场景的过程中也遇到了难题——如何解决前端资源调试预览的问题。

我们在本地开发的时候，调试预览的模式基本都是这样的，首先会在浏览器中访问线上的地址，把一部分资源或接口访问到线上，另一部分资源代理到本地启动的服务上。

经过调研，我司前端项目使用hiproxy进行代理的占比达到 40% 。所以一定要满足这些项目的用户在云环境上的使用。这里为什么单独提到 hiproxy，是因为 hiproxy 启动是依赖于当前命令执行的 rewrite 文件，一般来说，这个文件都会放在项目根目录下。云环境上的话，就是跟随代码放在云上。而像 charles 等一些其他方式的代理，会配置在开发者本地，是全局的，那这种的话就不需要做考虑了。除此之外，针对特定业务场景，比如说像低代码平台业务，我们还提供了定制化的前端代理。于是针对于前端资源代理问题，我们也做了几个方面的工作去解决。

1. 前端代理—hiproxy

首先，要解决 hiproxy 的问题，我们要先了解 hiproxy 的原理。在翻看源码后发现，我们日常执行 hiproxy start -o 命令，其实可以分为两步操作：

① 启动一个5525端口代理服务

② 执行chrome启动命令，让谷歌浏览器重新启动一个新的窗口，这个窗口和其他窗口独立。在本地执行是没有问题的，那到了云环境上，因为远端服务没有浏览器，即便有，也是在远端服务器上，而不是用户本地的浏览器。

所以基于此，猜想假设把这两步拆分开，代理服务启动在云环境，而启动 chrome 窗口放在开发者本地，是不是就可以解决这个问题。那我们把这个 chrome 启动命令 –proxy-server 中的 ip 换位云环境的 ip 后，流程是完全可以走通的，那 hiproxy 这个问题就解决了。

2. 前端代理—特定场景定制

在低代码中一个页面是有很多的组件构成的。一个 git 仓也包含了多个组件。如果用 hiproxy 做代理，当然也是可以完成的。只不过因为每次开发的组件以及云环境地址不同，就需要更改代理的配置文件，这样的话就增大了开发成本。所以针对于这种场景，在预览地址后加特殊参数，指定代理的地址和需要代理的组件，在 server 端检测到参数后定向访问资源，这样就解决了调试预览的问题。

这就形成了一个完整的流程。后续如果有新的业务场景想对接云开发，就有了一套现成的模式去参考。

提升资源利用率 – 弹性伸缩

考虑到随着云开发平台推广，会不断有用户开始体验和使用，且用户可根据不同语言类型、IDE 类型、业务场景和项目创建多个云开发环境，为了避免容器资源浪费，需要一套资源回收和清理的机制保证容器资源高效利用，对于用户长期不使用的云开发容器能够自动回收，再次使用时能够快速恢复拉起。并且用户的代码和配置安全不丢失。

数据安全和高可用： 云开发环境是用户每天都会使用和操作的，可用性必须要高，且对代码和配置的安全性也有很高要求，不能存在丢失的情况。采用“容器化+对象存储持久化+定时数据备份策略+宿主隔离”的方式，为用户提供数据可靠性，也为弹性伸缩提高容器资源利用率打下基础。

监控用户使用行为： 资源回收的前提是能够知晓用户不再使用云开发工作区，即需监控用户的使用行为，我们通过心跳上报机制维护云开发工作区的在线状态，以此为资源自动弹性伸缩和用户行为数据统计的基础。

弹性伸缩，资源高效利用： 在保证用户数据安全基础上，监控用户使用行为，利用容器弹性伸缩特性，提高资源利用率。功能上线后，容器资源的实际利用率从 30% 提升到平均 80% 左右。

• 超时回收：当用户不在线时间达到超时时间阈值，如 3 小时，云开发平台会自动释放容器 cpu、内存资源，但用户代码、IDE 配置等数据仍将持久化保存，下次拉起时可直接恢复数据和使用。

• 彻底销毁：当用户长时间不在线，且达到销毁时间阈值时，如 7 天，会先给用户发 QT 提示，提示中已给出云开发环境的各项信息，如确认不需要使用忽略消息即可，如仍需使用，按照提示操作即可保留。彻底销毁不仅会回收容器 cpu 、内存资源，久化的代码资源和配置也会删除。

本地IDE模式

由于使用习惯，快捷键等迁移成本问题，使用浏览器作为客户端接入云开发模式并不适用于所有用户，所以我们在设计初期的目标就是可接入多种IDE的远程开发方案，这就需要将 IDE 的管理抽象为 IDE 创建，连接方式管理，状态管理，插件和配置管理等多个部分，并将市面上常见 IDE 的云开发方案整合其中。目前已适配了 vscode浏览器模式，vscode 本地模式，JetBrains WebStorm、Idea 等多种远程开发模式。

如上图左侧所示，浏览器模式通过 https 域名+URL Path 的方式访问，而 Local IDE 的方式可通过本地 vscode，Jetbrains IDEA、WebStorm、Gateway，通过 SSH 远程连接云开发环境，并且无论哪种模式，用户都可以在 qunar 的云开发平台上完成操作，不需要来回切换，使用体验上也比较统一和高效。

上图是使用本地 Jetbrains IDEA 接入云开发的使用示例，可以看到和直接使用本地 IDEA 的开发效果基本一致，使用过程中，只会传输代码、索引等数据，将计算等任务交给云开发环境，而渲染显示等还是依赖本地的 IDE ，并且可复用用户原本的快捷键和插件。这种情况下，我们就能完全拥有本地化的开发体验。

Java后端云开发落地

介绍了 LocalIDE 本地开发模式后，下面以后端 Java 开发场景结合 Jebtrains  IDEA 的本地 IDE 模式，描述下具体实现方案，主要分为两块，一是用户创建的云开发工作区，二是用户本地的使用体验。

1、云开发工作区

Java 环境依赖：镜像模板的语言环境层，会分别适配多种 Java+maven+tomcat 等的组合，以满足公司内对于 Java8、11、17 等多版本环境依赖的需求，为用户提供Java后端标准化开发环境，无需搭建，直接进入开发。

Jetbrains IDEA 远程开发方案集成：镜像的 IDE 层集成了Jetbrains IDEA远程开发方案，在容器启动时会拉起 server 端进程，用户通过 SSH 方式远程连接，整个过程只需要在云开发平台页面上操作，云开发环境创建成功后会通过 Gateway link 的方式触发打开用户本地 IDE ，并且已将远程连接信息自动填好，用户只需确认即可进入开发。

用户代码：云开发平台有权限控制，用户只能选取自己有权限的代码，并通过 SSH 公私钥的方式，以用户自身权限拉取代码到云开发环境中。

2、用户本地

(1) 使用体验

操作界面：如上图，和使用本地IDEA的操作界面、功能菜单基本一致。

快捷键：基于Jetbrains远程开发方案，会自动拷贝用户本地的快捷键设置，所以在快捷键上基本没有迁移成本。

插件：提前预置了常用的开发插件，并且会自动拷贝复制用户本地的预装插件，插件体验上无差异。

(2) 应用访问和调试

应用访问： 启动应用程序后，如访问端口是8080，会将本地的8080端口通过SSH代理的方式连接到云开发环境，即访问本地8080端口实际是访问云开发环境中应用。

调试： 打断点调试方式和本地一致。

打通开发全流程

除了云开发快速便捷的开发体验，我们更希望和公司内开发流程中的其它产品结合起来，打通开发的全流程，真正建立研发效能的闭环。

上图就是对于开发同学来说项目开发的主要路径。其中项目打开 → 项目开发 → 代码提交可以交由 WebIDE 云开发中操作。其他流程，这里举个例子：像关联 pmo ，我们可以在创建云开发环境时关联绑定 pmo 号或者以 pmo 系统为入口进入云开发，而在关闭 pmo 时会自动检测到并销毁使用完毕的云开发环境。代码发布方面，我们也打通 CI/CD 流程，用户无需切换，一键发布。

插件扩展

上图红框处是我们给云环境定制化的一款插件，为打造团队需要的 WebIDE ，满足日常的开发是必须的。所以易扩展一定是排在第一位的。基于此，我们在插件中，实现了打通开发全流程的 CI/CD 环接。插件整体分为三大版块。

1、常用命令

目前云环境插件中提供了一些常用命令，点击即可自动运行在终端。

这个功能大大便利了开发同学，不需要大家打开终端执行命令，而是点击即可自动打开终端执行。

2、发布版块

也就是我们打通 CI/CD 的一环。这部分会根据打开的文件目录自动识别发布类型，不需要开发同学去发布平台查找以及填写发布表单，即可一键发布关联 portal 和 mportal 。

3、个性化定制

用户可定制安装属于自己的插件，设置后，在新创建的云环境上都是生效的，开发体验能最大程度的接近本地化。

四、总结及展望

去哪儿云开发平台建立的目标是结合云原生容器化并使用云开发模式，适配前后端多种业务场景，能够快速提供标准化开发环境，与多种 IDE 远程开发方案深度整合，打通公司内部开发生命周期流程，提升开发效率。从上线后的结果看，已经完全达到目标。接入支持了前后端多种业务场景，如 cms、qrn、node&qzz、rock，java 等。整合了 vscode 浏览器模式、vscode 本地模式、Jetbrains WebStorm、Idea 开发模式等多种 IDE 远程开发方案。深入结合业务场景，提升开发效率。

后续我们将云开发领域持续跟进和优化。优化效率和体验方面考虑使用预热池化技术提升云开发环境的创建速度。适配和接入公司内更多业务场景，满足更多开发需求。继续整合打通开发流程中涉及的服务和产品，让云开发使用更顺畅，进一步提升效率。