云原生架构下蚂蚁 Cloud IDE 的应用实践

🙋🏻‍♀️编编拎重点：云上 IDE 研发已经渐渐成为行业趋势，对整个研发链路能有较大提效。蚂蚁 Cloud IDE 经过两年半的发展，逐渐将内部技术栈标准化，并且利用云原生架构的优势，将蚂蚁研发逐步搬上了云端。本次分享中，蚂蚁集团 Cloud IDE 工程师蛋总和大家交流了Cloud IDE 在云原生背景下的探索与落地，欢迎享用。

大家好，我是蛋总，来自蚂蚁研发效能 Cloud IDE 团队。今天我给大家带来的分享是《Cloud IDE 在云原生架构下的应用实践》。

什么是 Cloud IDE？

本地研发的痛点

• 不能随时随地：大家可能在 Outing 的时候会有些体感，Outing 的时候必须出门带个电脑才能放心，因为可能会遇到要修复一些紧急的问题。
• 不能极致的性能：比如有一个需要的比较大资源的项目，可能是需要 32G 才能把这个应用给跑起来，本地研发是无法动态调整这个资源的，当前环境的资源在我们买了这个设备后就已经限定好了，不能动态的去调整 CPU 和 内存。还有一个情况就是运行比较多的项目时非常消耗本地资源，有一个玩笑就是被电脑风扇烫伤，算工伤吗？

• 不能分享协作：比如说在日常研发时会遇到一些应用报错，本地研发可能就非常不太容易的把我们现场环境给值班同学排查具体是哪块出了问题。
• 高风险难管控：当遇到需要统一升级环境和工具时，缺少管控力，比如内部要统一升级本地研发环境从 Java8 到 Java 11，可能要花几个月甚至几年的时间。

Cloud IDE 的优势

• 随时随地开发：无论你的设备是电脑、手机，或是 pad，只需要一个浏览器把 Cloud IDE 打开，然后就可以去编码。我们也会去提前帮你把一些项目的依赖、插件都准备好，带来开箱即用的体验。
• 释放本地资源：我们充分利用了云原生的弹性计算资源，可以去自定义当前项目运行所需要的资源是有哪些。

• 一键分享：使用 Cloud IDE 分享不再是难事了，我们可以很方便的把当前的环境分享给别人，要注意这里的分享不仅仅只是把代码或者是依赖，而是把当前整个操作系统和整个运行时。
• 低风险易掌控：因为研发环境统一在云上，那就有能力统一对云上的一些 SDK 去做一些升级。也可以在研发环境增加一些代码扫描的工具，帮助我们在运行时提前做一些代码的安全检查。

Cloud IDE 不等于 Web IDE

接下来还想分享一个观点，就是 Cloud IDE 并不等于 Web IDE。Cloud IDE 提供了一个 Web 的一个运行的方式提供多个场景的接入，这种形式也会和内部的平台做更紧密的结合。而且 Web 的形式更容易我们分享。

我们也有 Electron 桌面端来连接我们的工作空间进行开发，本地客户端拥有更多系统权限，例如做本地端口和 Host 映射，也可以解决快捷间冲突的问题。

我们也不排斥其他三方客户端连接我们的研发容器。Cloud IDE 可以让 VS Code 或者是 Jetbrains Getaway 使用 Remote 的方式去连接远程研发容器。不过是目前因为精力原因，我们主要还是聚焦在 Web 和 桌面版上。

在蚂蚁内部，有哪些最佳实践？

我们底层有一个基础的镜像，在这里会安装通用的软件，在此之上我们封装了一些蚂蚁通用的技术栈，比如 Java、Node、Go 等等。基于这些通用的技术栈之上，也会去对接一些蚂蚁的研发场景，和代码仓库场景、测试平台，代码评审发布平台、新人培训等场景都有一些整合。

云测平台案例

我们和测试平台整合，可以把当前开发的测试用例直接就跑在了远端的一个真实的设备，这样可以做到边修改单元测试代码边可以看改后在真实机器上跑的效果。

‍在 Cloud IDE 里也可以录制性能报告，这样我们就能在研发时看出 App 性能变化的曲线。

代码平台案例

当在 Cloud IDE 开发完代码后，不用跳转到代码服务平台创建 PR，可以直接在 Cloud IDE 里去创建 PR。

如果从代码服务平台评审代码时想运行下项目，也可以从代码服务平台跳转到 Cloud IDE 里来运行代码，或者在 Cloud IDE 编辑器里做代码的评审。

研发平台案例

这个是蚂蚁内部前端研发平台做的整合案例。当代码合并到迭代分支后，不用去跳到前端研发平台去即可进行流程推进。

新人培训场景

我们也做了一些新人培训场景。例如这是蚂蚁前端框架 bigfish 示例工程，可以在 Cloud IDE 里做教程，辅导新人学会如何使用 bigfish，我们的优势是这个教程和 IDE 的文件树、编辑器、终端去做一些连联动。

问题：如何接入上述研发平台和研发工具？

刚才给大家展示了 Cloud  IDE 和这些平台结合的示例。现在有一个问题，就是如何去接入上述研发平台和研发工具呢？这些接入不可能完全由 Cloud  ID同学自己去做研发，因为可能其他平台更懂他们的业务流程。如果我们去投入研发的话，可能我们的精力是非常不够，团队成员可能要不停的去对接各种各样的研发诉求。那么我们的解法就是插件体系。

插件进程和主进程分离：我们参照 VS Code 插件架构，将插件进程和主进程分离，可以看到橙色部分是单独的插件进程。在这里会完 VS Code 的 api 拦截和适配。插件进程如果要调用 IDE 主进程的能力，需要走 RPC 通信完成。

新增 Browser 层和 Worker 层：在此模型之上，又扩展了 Browser 层和 Worker 层，在这两层可以定制更多的 UI 能力，大家可以用喜欢的 React 去写插件，并且不用走这个通信链路，就能直接从 UI 层调用到主进程提供的功能。这样就能兼容 VS Code 插件体系，并且在此之上有更好的扩展。

插件 UI 样式隔离和 JS 作用域隔离：为了让插件不影响到 IDE 的全局样式，污染到 IDE 的全局方法，我们利用 SHADOW-DOM 实现了一个沙箱环境，确保插件的代码只能影响到插件作用域。

简化调用链路：我们简化了链路的调用的复杂度，前端调后端，和在同一个环境调一个方法一样简单。

接下来再整体介绍一下我们整个 Cloud  IDE 插件体系。我们有一个插件市场平台来维护我们 Clou IDE 相关插件，对上传的插件会进行安全扫描。我们在 Cloud IDE 上加入了插件研发场景，在我们 Cloud IDE 平台即可完成插件研发的闭环。我们也提供了相应的插件 UI 组件，适配了插件的皮肤样式，也适配了 VS Code 插件的 API，这样就能兼容 VS Code 的插件生态。

在云原生架构下， Cloud IDE 到底有哪些新玩法？

依赖和语言服务的提前准备

我们会去提前去做一些依赖和语言服务索引的提前准备。这个是属于我们开箱启用这一环，首先我们会从我们代码服务中拉去获取仓库的列表，然后会在我们工作空间集群里去跑这些项目的语言服务和依赖，然后会把这些产物存储在 OSS，最后当我们新空间来后就会动态下载这些依赖和语言服务索引进行使用，这样用户打开新空间，不需要他安装依赖，语言服务也用进行完全 ready 就能进行语言服务的使用。

插件免下载

传统的插件的安装方式是是从 OSS 上把这个插件包下载下来，然后去解压插件并做插件的激活。

那我们云上是怎么玩的呢？如果是新增一个插件后，插件市场会发出一个 Hook，然后我们会把这些插件提前装到 OSS FS。OSS FS 大家可以理解为对于我们使用者，感觉就是一个本地挂载的文件资源；但对于我们上传者，其实就是一个 OSS 这样简单。我们这边会做一个 Overlay 挂载，让这些插件文件有可写的能力。这样就能达到在 Cloud IDE 里免去了下载插件的过程，默认插件都在空间能读取到，只剩插件激活这个步骤。

多容器架构

大家可以看到其他的一些主流的 Cloud  IDE 大部分都是该架构。就是所有的研发容器的技术栈、用户研发进行和 IDE 服务、插件进程都是在同一个容器里。用户在研发的时候可以看到 IDE 的服务，甚至可以在终端将这个 IDE 服务给杀死。

这样的话可能会有两个问题，一个是隔离性比较差，因为它的进程是可以相互看见的互相影响的，研发进程如果内存较高，很可能引起 IDE 服务进程的 OOM。第二个是服务耦合。当我们想升级我们 IDE 服务的时候，就需要对整个容器进行一个重新构建，运维成本较高。

我们这边做了一个多容器的一个架构。我们的 IDE 服务是封装到了 sidecar 作为一个单独的一个容器，除此之外，我们也会 Mysql 和是代码扫描容器也都分装为 sidecar， 用户研发容器只会关心他当前运行的研发容器环境。因为容器间的隔离特性，用户看不到 IDE 本身的服务，用户容器和 IDE 服务容器不会相互的影响。

其次如果我们要升级 Cloud IDE 版本，只是需要升级 IDE 服务容器就好，也可以进行 sidecar 容器自由的组合，例如一些场景需要 Mysql 我们就将 Mysql 容器挂上去。

整体架构

除了上面介绍的开箱即用、插件体系和多容器以外，底层的 IDE 框架为我们和淘宝的工程师一起来共建的OpenSumi 框架，他提供了 IDE 编辑器、调试、终端、SCM 面板等各种 IDE 基础能力，该框架近期也会开源。我们也有场景中台来支持我们场景接入，有容器服务支撑 IDE 容器的编排。

如果是大家对 Cloud  IDE 比较感兴趣的话，可以通过以下方式联系我，谢谢大家。

有点意思，那就点个关注呗 💁🏼‍♀️