开发环境上云，打造五星级开发体验

本文作者：王振威 - CODING 研发总监 ，全文约 5000+ 字，预计阅读时间 20 分钟

云是从传统 IDC 机房演进而来，一开始云的定位只是为了解决数据中心的弹性计算，高可用等问题。可以说，公有云让成千上万家企业灵活地按需租用数据中心资源成为可能，同时在推动社会数字化发展上起到了关键作用。

但简简单单的把云理解为资源的按需租用太狭隘了，随着云技术和行业标准的发展，云原生的概念开始出现。云原生变革了传统应用，传统的应用可以运行在本地开发电脑上，到真正正式提供生产服务才被云以弹性的，高可用的资源提供方式接管。而云原生应用跟传统应用不一样，传统应用面向操作系统编程，云原生应用直接面向云编程。云原生应用很难在非云的环境里开发，调试，测试和投产。

CODING 致力于服务开发者，在云发展的时代也一直在积极探索用云的技术和理念来解决实际问题。随着公司业务发展，技术革新，CODING 自身也一直在践行最先进的开发方式，拥抱上云进程。CODING 的开发环境演进大致经历六个阶段，逐步打造了五星级的开发体验。

六个阶段的发展过程，其实也是开发环境逐渐上云的过程，从 0% 到 100% 的开发环境上云，在第六个阶段，CODING 使用 Nocalhost 完成了 100% 的开发环境上云。随着上云进程的进展，下图可以看到不同开发环境的体验星级。

下文将对六个阶段进行一一讲解。

第一阶段：高配笔记本电脑

CODING 2014 年创立，创立之初只有几个程序员，我们跟大多数初创企业没有区别，一条家庭宽带 + 一个千兆无线路由 + 若干台笔记本电脑就可以着手开发第一个版本的 CODING 。

典型的情况是人手一台 MacBook Pro （ i7 + 8G + 256G SSD ），使用 JetBrains 系列 IDE 开发，写完代码在 IDE 里点运行或者调试，IDE 会自动编译并启动应用，开发者可以很方便地调试程序。事实上这个阶段的体验就是五星级的，但随着业务，技术等的发展，开发体验逐渐下降，苦不堪言。

此阶段基本状况

当时 CODING 开发环境情况

• 开发者人数：10 人左右
• 应用架构：Java 单体后端 + Angular.js 前后端分离
• IDE：IDEA + WebStorm 开发
• 构建方式：手动
• 部署方式：云主机 + Nginx + Tomcat 部署
• 开发环境：笔记本电脑 + Tomcat
• CODING 服务启动时间：10 秒

同期云计算和技术架构行业发展状况

• 以云主机和云对象存储为代表的云服务正在逐渐被接受
• Docker 开始在国内被人知晓
• Kubernetes 已经开源
• 微服务概念被提出

存在的问题

• 没有稳定的测试环境
• 手动构建打包和部署效率低下
• 单体后端应用性能和可用性都存在瓶颈

开发体验打分：5 星 ⭐⭐⭐⭐⭐

此阶段虽然存在一些问题，但所有开发人员对开发环境各方面都比较满意，主要的衡量指标是 “写代码->构建->启动->调试->自测” 这个循环 很快（下文中我们称之为 “编码-自测反馈循环” ），而且全部步骤只需要在 IDE 中点击一个 Debug 按钮就行了，一个循环耗时约 10 秒，这意味着开发人员可以更快更高频的检视自己的编码结果，而不是傻傻地等或做大量无意义的机械操作。

第二阶段：高配笔记本电脑 + 局域网服务器

时间来到 2015 年初，开发者已经被手动构建这种机械操作搞的烦躁不堪，测试同学也总是吐槽运行在开发者电脑上的测试环境不稳定，版本混乱，体验太差。我们决定增加了一个放在局域网的电脑当做共用服务器（ i7 + 16G + 500G SSD ），专门用来执行构建和承担测试服务器工作。服务器上的 Jenkins 可以方便地自动构建打包，测试环境也有专属资源和专人维护。

此阶段基本状况

当时 CODING 开发环境情况

• 开发者人数：20 人左右
• 应用架构：多个 Java 后端 + Angular.js 前后端分离
• IDE：IDEA + WebStorm 开发
• 构建方式：局域网服务器 + Jenkins
• 部署方式：云主机 + Nginx + Tomcat 部署
• 开发环境：笔记本电脑 + SpringBoot 进程
• CODING 服务启动时间：20 秒

同期云计算和技术架构行业发展状况

• 以云主机和云对象存储为代表的云服务正在逐渐被接受
• Docker 开始在国内的一些团队尝试实践
• CNCF 基金会成立
• Mesos，Kubernetes，OpenShift 等云资源编排方案开始流行

存在的问题

• 后端服务中一些组件被拆分导致本地开发环境搭建略显困难
• 部署麻烦，需要维护多个服务之间的连接关系和配置文件
• 只有一套测试环境无法满足诉求
• 笔记本的性能已经捉襟见肘

开发体验打分：4 星 ⭐⭐⭐⭐

此阶段实现了自动构建和稳定的测试环境，但后端服务开始变成了四个服务，本地环境部署麻烦，仅有一个测试环境也不够使用。此外，服务本身启动变慢也导致了新的问题。开发者们在把自己的笔记本经过一系列配置后还是能比较方便的运行起来整个 CODING，不过此时编码-自测反馈循环的耗时已经上升到了 30 秒左右了。

第三阶段：高配台式电脑 + 局域网机柜

时间来到 2016 年，我们实在无法忍受测试环境单一等造成的问题了，人员越来越多，业务也越来越复杂，我们购置了 10 台二手戴尔 R710 组成了一个机柜，在升级了内存和固态硬盘后，配置上千兆交换机和虚拟化系统。这个机柜被放置到了办公室的机房内，虽有高分贝的噪音，但它能解决部分开发和测试资源问题。而个体开发者也意识到即便是顶级配置的笔记本，其性能也无法支持顺畅的 CODING 开发体验了，很多人配置了台式主机（ i7 + 32G + 1T SSD ）来支撑开发工作。

此阶段基本状况

当时 CODING 开发环境情况

• 开发者人数：40 人左右
• 应用架构：多个 Java/Ruby/Golang 后端 + Angular.js 前后端分离
• IDE：多种 IDE 和各类编辑器
• 构建方式：局域网虚拟机 + Jenkins + Docker
• 部署方式：云主机 + Nginx + Docker + 自研容器编排系统部署
• 开发环境：台式电脑 + docker-compose
• CODING 服务启动时间：40 秒

同期云计算和技术架构行业发展状况

• 国内云服务厂商开始构建以容器、弹性数据库等为代表的 PaaS 产品
• Docker 开始在国内的一些团队尝试实践
• 以 Spring Cloud 为首的微服务框架开始逐渐被了解

存在的问题

• 机柜的噪音巨大，即便机柜被放到办公室机房，还是能干扰到同事
• 机柜的服务器稳定性不好，因散热不佳，功率过载，服务器老化等问题，经常死机
• 微服务数量和配置信息进一步增加，导致本地开发环境搭建更困难，新手上手痛苦
• 因缺少工具支撑，本地电脑跟局域网虚拟机开发的协同不顺畅（本机编码，虚拟机运行）

开发体验打分：3 星 ⭐⭐⭐

此阶段大多数开发者使用 docker-compose 来支撑开发环境，本地的开发环境搭建相对容易了一些，但每次修改完代码，还是必须经过编译，打包 Docker 镜像，再调用 docker-compose up -d 命令来重启容器才能看到修改的代码效果，编码-自测反馈循环耗时进一步提升，从 30 秒提升到了 2 分钟左右。

第四阶段：高配开发电脑 + 高配局域网服务器 + 局域网机柜

时间来到 2017 年，为了应对笔记本编译慢，内存小的问题，公司出钱为每个小组配备了局域网台式机（ AMD R7 + 64G + 1T SSD ）来支撑开发。这些局域网台式机被组成一个虚拟机资源池，划分成虚拟机给到开发者使用。而在办公室狭小的机房的内、无论是空间、空调、隔音还是其他设施都已经无法再多容纳一个机柜了，因此，唯一的机柜专门用来支撑测试环境和预生产环境演练。

此阶段基本状况

当时 CODING 开发环境情况

• 开发者人数：80 人左右
• 应用架构：多个 Java/Ruby/Golang 后端 + React.js 前后端分离
• IDE：多种 IDE 和各类编辑器
• 构建方式：局域网虚拟机 + Jenkins + Docker
• 部署方式：云主机 + Nginx + Docker + 自研容器编排系统部署
• 开发环境：局域网虚拟机 + docker-compose
• CODING 服务启动时间：3 分钟

同期云计算和技术架构行业发展状况

• Kubernetes 逐渐走向成熟，越来越被更多团队接受
• 很多团队开始尝试以 Spring Cloud，Dubbo 等改造自己的单体架构业务
• Service Mesh 概念被提出

存在的问题

• 对开发者的技能要求很高（要求所有人都掌握 Linux 系统的使用和管理方式）
• 资源的弹性能力差，无法应对高低峰问题
• 开发和测试环境与生产环境差异大
• 因缺少工具支撑，本地电脑跟局域网虚拟机开发协同不顺畅（本机编码，虚拟机运行）

开发体验打分：2 星 ⭐⭐

这一阶段是问题很多，也是持续了最久时间的一个阶段。苦不堪言的开发者们，大量的精力被浪费在如何搭建、维护和更新开发环境上。写完代码，必须经历编译，打包 Docker 镜像，推送到镜像仓库，在虚拟机上拉下来，重启容器，等待启动完毕之后才能检视代码的运行结果。编码-自测的反馈循环已经上升到了近 10 分钟。而这逼迫开发者们不得不盲写一大堆代码后才能尝试运行调试一次。

第五阶段：高配开发电脑 + 云主机

时间来到 2019 年，CODING 开始使用腾讯云提供的云主机来支撑开发和测试。公司处理掉了大量之前遗留的机柜服务器和台式电脑，办公室回到了宁静，并且开发和测试环境变得稳定了起来。但云主机能带来的好处也就只有稳定性和安静了，在其他开发体验方面几乎没什么变化。随着业务变的日趋复杂，32G 的内存也跑不起来完整 CODING 了，一时间 i9 + 64G 的台式电脑在办公室比比皆是。

此阶段基本状况

当时 CODING 开发环境情况

• 开发者人数：120 人左右
• 应用架构：多个 Java/Ruby/Golang/PHP/Python 后端 + React.js 前后端分离
• IDE：多种 IDE 和各类编辑器
• 构建方式：CODING CI + CODING 制品库
• 部署方式：Kubernetes （ TKE ）
• 开发环境：云主机 + docker-compose/minikube
• CODING 服务启动时间：40 分钟

同期云计算和技术架构行业发展状况

• Kubernetes 逐渐成为事实上的容器编排标准
• Service Mesh 开始兴起
• CI/CD 灰度发布开始兴起
• 云原生应用被提出

存在的问题

• 本地电脑跟云主机开发的协同性问题（本机编码，云主机运行，网络，界面，存储等）
• 对开发者的技能要求很高（要求所有人都掌握 Linux 系统的使用和管理方式）
• 资源的弹性能力差，无法应对高低峰问题
• 开发和测试环境与生产环境差异大（开发用 docker-compose 或者 minikube，生产环境用 TKE ）
• 大量服务的 Kubernetes YAML 和 docker-compose 配置难以管理

开发体验打分：1 星 ⭐

云主机显著地改善了办公室机房的稳定性等问题，但实质上一个更稳定的 Linux 服务器并不能帮助开发者快速地搭建 CODING 开发环境，也不能加速编码-自测反馈循环。开发者还是需要进行编码，构建，打包镜像，推送镜像，远端拉取镜像，重启容器的过程来检视自己的编码结果。随着系统的复杂度提升，即便有着云端更强性能，更稳定的云主机，CODING 的部分业务的编码-自测反馈循环耗时还是在不断上升。

有些业务的这个循环时间甚至已经达到了耸人听闻的一个小时。

其实这个阶段跟上一阶段差异并不大，仅仅是云主机替代局域网虚拟机。编码-自测反馈循环耗时大幅上升的主要原因为，微服务数量陡增。CODING 的 150 个微服务有着内在的启动依赖顺序，而被依赖的服务没启动完毕会导致下游服务 Pod 启动失败，每次失败都会导致 Kubernetes 加长重启间隔，最终全部服务启动完毕需要很久时间。而此过程如果能人为干预服务的启动时机，从无序启动变为有序启动，则能显著降低启动时间。

第六阶段：开发电脑 + 云端容器集群 + Nocalhost

时间来到 2020 年，CODING 决心彻底解决这一问题。于是，在 12 月份推出了开源产品 Nocalhost 。Nocalhost 旨在解决云原生应用开发调试难的问题，当下可以支持在 Kubernetes 的基础上快速部署、开发和调试应用。目前 CODING 的后端开发者们已经在使用 Nocalhost 开发 CODING 了，底层基于腾讯云的大规模容器集群 TKE 。CODING 把开发环境搬上了云，实现了五星级开发体验。

大致原理为，CODING 公司维护一个较大的 Kubernetes 集群（ TKE ），使用 Nocalhost 为开发者分配开发空间，开发者可以随时在开发空间里部署 CODING 。部署完毕后，开发者可以选取自己想要开发的微服务切换成开发模式，然后配合 IDE 侧直连集群，修改代码配合 HotReload 直接可以检视运行结果。对于 PHP，Python 这类动态语言，因为天然支持快速 HotReload，编码-自测反馈循环直接缩减到了 1 秒，实现保存即生效。

此阶段基本状况

当下 CODING 开发环境情况

• 开发者人数：200 人左右
• 应用架构：上百个 Java/Ruby/Golang/PHP/Python 后端 + React.js 前后端分离
• IDE：多种 IDE 和各类编辑器
• 构建方式：CODING CI + CODING 制品库
• 部署方式：Kubernetes （ TKE ）
• 开发环境：Nocalhost + Kubernetes （ TKE ）
• CODING 服务启动时间：4 分钟

当下云计算和技术架构行业发展状况

• Istio 成为最流行的 Service Mesh 方案
• Serverless Kubernetes 开始逐渐崛起
• Kubernetes 的复杂性开始被行业关注，大家在思考如何从开发者的角度看 Kubernetes
• Serverless 作为下一代云计算技术开始受到重视

存在的问题

• 资源的弹性能力不够彻底，成本略高。(未来可尝试用 Serverless Kubernetes 实现夜晚的低峰节省成本)
• 较难共享公共服务问题，每人部署一套公共服务，比较浪费。(Nocalhost 未来会结合 Service Mesh 方案来解决这个问题)

开发体验打分：5 星 ⭐⭐⭐⭐⭐

这个方案的可操作性是很强的，团队不需要去购置硬件设备，也不需要掌握复杂的机房组网，虚拟化管理软件和 Kubernetes 集群维护技术。直接在云服务商开启给开发环境专用的 Kubernetes 集群并安装上 Nocalhost 就能实现开发环境上云了。

这个方案现在唯一的问题就是成本略高，不过我们相信随着云技术的发展和弹性能力的细化，成本最终会降下来，以后云原生应用的开发环境也是在云上。这个方案为开发团队大幅提升了开发效率，不仅如此，对于 CODING 这样一个有 150 个微服务的庞然大物，我们还做到了让任何一个新手程序员入职都可以在 5 分钟内跑起整套环境，并可实现秒级的编码-自测的反馈循环，这无疑是给开发者打造了五星级的开发体验。Nocalhost 可以管控服务启动顺序保障了应用部署的速度，把集群中的微服务直接转换为开发模式，保障了环境的相似性。自动的代码同步和 HotReload 大幅提升编码-自测循环效率。

下图是使用 IDEA 基于 Nocalhost 开发 CODING 的制品库产品的示例

总结

单体应用的简单和微服务应用的复杂是天然对立的。而随着业务、技术和行业的发展，微服务化又是个必然趋势。在这个过程中，相比于运维的安全稳定诉求，开发者的工作体验往往是被牺牲掉的那一个。CODING 作为一家立志于服务开发者的公司，践行让开发更简单，我们是认真的。我们在不断攻克难题的同时，也在积极地回馈开发者群体。Nocalhost 项目设立之初就是开源的，厂商独立的，欢迎你的贡献。

• Nocalhost 官网: https://nocalhost.dev
• Nocalhost GitHub: https://github.com/nocalhost

Nocalhost 团队长期招募优秀人才，有志于服务开发者，共建云原生开源生态的同学可以投递简历至： [email protected]