关于coding:开发环境上云打造五星级开发体验

7次阅读

共计 6326 个字符,预计需要花费 16 分钟才能阅读完成。

本文作者:王振威 – 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 团队长期招募优秀人才,有志于服务开发者,共建云原生开源生态的同学能够投递简历至:wangweimax@coding.net

正文完
 0