腾讯云「云端开发环境Cloud-简称CDE」日常开发实战案例自举分享
发表时间：2023-09-29 10:03:07
文章来源：炫佑科技
浏览次数：170
菏泽炫佑科技
腾讯云「云端开发环境Cloud-简称CDE」日常开发实战案例自举分享
介绍
云团队日常开发实战案例分享
本文重点分享云产研团队如何利用腾讯云的“云开发环境Cloud-简称CDE”来提升日常开发-调试-构建-运行关键阶段的开发者体验。
云产品是基于云开发环境的开发平台，旨在简化复杂性，解决很多本地开发问题。
作者从团队*初决定上云时遇到的挑战、迁移到云过程中的痛点入手，阐述了架构重构带来的优缺点以及如何专注提升启动开发环境的性能和降低成本，并分享所取得的进展。
*后，作者将给大家留下一些关于“云开发环境”现在和未来的机会和想法。
01
*初的痛点
Cloud 核心代码库的状态
与传统业务项目相比，云的业务场景极其复杂。 每个模块都有不同的形式，包括内核、插件、各种文件系统管理程序、动态容器进程和其他形式的应用程序、十多种编程语言和数据处理。 十种后台服务以及各种程序的配套构建和配置工具。
随着时间的推移，碎片化已经成为云团队中大开发者的*大痛点。 具体来说，依赖关系混乱、各模块版本难以统一、多个工具碎片化使用成本高、协作和代码共享困难。
搬去
针对这些问题，我们制定了代码库转移策略，逐步将所有代码库转移到统一的代码仓库，建立了主干开发模式。
该模型具有以下优点：
挑战
切换到 后，我们发现了另一个问题：虽然它为稳定统一的开发流程奠定了坚实的基础，但它使在日常笔记本电脑上完成的完整研发流程（从代码编辑-提交-构建-运行-测试）变得具有挑战性，因为如图1所示：
除此之外，维护一套一致的工具并在笔记本电脑上保持本地开发是需要我们关注和解决的问题。
图1 解剖图
02
使用云进行远程开发和引导
我们问自己，既然我们做的是一个云开发平台，并且提到了这么多优点（可扩展性、云资源的享受、隔离、方便访问等），我们是否可以在云上运行自己的大仓库进行开发？ ？ 在该环境中，利用云产品功能进行日常开发，从而持续反馈产品体验。 如果体验不好用，我会尝试解决问题。 所以我们走上了引导之路。
什么是腾讯云-云开发环境？
当我们寻找解决方案为开发人员提供更快、更轻松、更安全的开发体验时，我们开始将远程开发作为替代方案。 在腾讯云更快的机器上构建云开发环境的想法，在几秒钟内拉动，并将所有代码库和工具保持在安全、受控的环境中。
这就是Cloud的初衷：基于Cloud开发平台构建CDE云开发环境。
什么是云？
Cloud是一个基于浏览器的集成开发环境（IDE），为开发人员提供始终在线的云工作站。 用户使用云时无需安装，只需打开浏览器即可随时随地使用。 云开发体验与本地开发几乎相同，上手门槛更低； 极其开放，第三方平台可以通过我们提供的SDK轻松集成云开发能力。
>>优点
3月份我们发布腾讯云云开发环境白皮书后，我们将云生产研究代码和日常开发迁移到腾讯云CDE中。 在白皮书中，我们定义了CDE的容器化、基于代码的定义，零设置门槛和安全性作为远程开发环境的主要优势。 我们通过在*新稳定版本的内核和隔离的环境上运行每个开发人员的代码，极大地提高了安全性。 例如，我们定制了自动脚本，以便可以在非工作时间处理易受攻击的应用程序代码。 进行修补和更新。 监控远程开发环境的各个方面非常简单，我们可以随时检测和识别恶意行为，例如挖洞、翻墙等。由于 Pod 运行在云开发环境中（背后有集群） ）没有计算机的电池和资源限制，在非工作时间扫描磁盘以查找恶意工件或活动是微不足道的，但价值是巨大的。
>>性能**
利用强大的腾讯云资源提供更快的 Git、构建和 IDE 体验 - 每个环境可弹性增加至多达 32 个核心和 128 GB RAM 以及许多附加功能，如图 2 所示：
>>不断调优IDE启动链接，测试通过后平均2-3秒即可打开，如下图
图 2：分层架构
>>采用Linux文件系统，相比笔记本文件系统有更好的性能
>>Git网络代理、内网访问加速
>>优化Git配置
>>环境编码与维护
云支持.yaml()的可视化定义配置，并将配置保存为“自定义模板”。 这些模板为团队成员仓库的云开发提供了巨大的价值：
>>安全
云提供的工作空间是持久的，因此工程师不必担心丢失个人设置、文件和代码更改。 这使得工程师能够在不同的设备上继续工作，并支持多个工程师在单一环境中进行协作。
云本地化云开发平台
>>提供主流开发语言环境
我们为中国开发者打造一个更适合中国人开发习惯的开发平台。 我们还内置了数十种基础开发环境的模板库，包括所有必需的基础镜像，以及预加载的默认设置、预设常用插件和开发配置。 。 目前我们支持以下开发环境语言，如图3所示：
图 3：开箱即用配置
>>基于Web的开发空间控制台
云为登录用户提供专用控制台，管理其工作空间状态、资源消耗，创建个性化专属模板、标识、团队管理和团队资源状态，满足从简单的个人开发到复杂的企业级开发的需求。 需求，如图4所示。
图4：云控制台
03
云开发环境架构
图5：云控制台
如图5所示，在云端，所有个人环境都放在容器环境中，这使得开发者可以使用官方提供的各种版本，也可以轻松定制自己的环境，而且即使离开云端也可以在任何地方应用。 在容器之上，Cloud将为用户提供额外的开箱即用的软件包，包括用户的编辑器界面、以及其他常用的开发工具。
如图6所示，我们提供了统一开发的操作系统。 作为全球*受欢迎的Linux发行版，它*符合开发者和用户的使用习惯。 它建立在其之上，自然可以使用大多数生态系统中的工具链，从而重用大部分现有的生产环境基础设施。
图6 云镜像层次结构
从本地计算机迁移到云端，可以让您大幅优化并享受云端更丰富的计算资源、海量计算核心和高性能大容量GB RAM机器。 *重要的是，我们决定利用腾讯云TKE、EKS以及高速稳定的集群能力，为我们提供我们需要的IaaS能力：
标准化底层容器
我们使用 | 完整描述工作空间资源，允许用户直接创建、调度和访问云工作空间 Pod，即使它们脱离了云平台。
在CRD中，我们扩展了m功能以支持数据的任意外部持久化，而不仅仅是Cloud本身使用的全局NFS持久化。 未来，我们计划支持响应 ts 变化，从而降低不使用时的存储成本。
图 7：云 CRD
04
挑战
为工程师创造完美的环境并非易事——我们在此过程中遇到了一些挑战。 平衡性能和成本效率、提供自动升级、确保不间断工作以及预先配置适合每个人的 IDE 设置是我们必须克服的一些障碍。
IDE核心选择
工程师每天都会使用 IDE，因此如果没有良好的 IDE 体验，远程环境就无法成功。 在云开发环境中，我们提供了多种不同的IDE内核选项：
>> SSH 连接方法
如图8所示，任何由Pod启动的云开发环境都可以使用您喜欢的本地IDE连接，保留您喜欢的主题和熟悉的快捷键。 充分利用云开发环境。
图8：通过SSH工具访问云开发环境
通过 SSH 连接到云 IDE 工作区 | 云
除了提供多种 IDE 选项外，我们还致力于通过以下方式微调实践体验：
云基于弹性计算能力和持久化存储，为用户提供快速开发的云开发体验。 然而，摆脱本地主流IDE并转向云开发一直是我们早期面临的*大挑战之一。 尤其是早期流行的基于Web的IDE的延迟问题以及后续的稳定性问题给我们带来了很大的麻烦。
后来我们发现Web IDE 和本地IDE 应该共存。 致力于云开发环境理念的构建和推广，助力企业研发降本增效、研发一致性需求。
让您的环境保持*新状态
由于工程师珍惜时间，因此提供不需要手动维护的环境非常重要，因此我们会在非工作时间使用*新的工具和安全更新自动升级环境。
为了满足每个人的需求，我们允许工程师从四种发布节奏渠道中进行选择：
无论工程师想要*稳定的环境和*先进的功能，还是根本不需要升级，我们都能满足。
我们后来改进了自动更新以支持新版本的逐步推出。 添加此功能是为了减少影响范围，以防错误通过我们的自动化测试和候选版本、内部测试流程。
成本效益
从许多客户那里发现构建和购买资源的情况并不罕见。 在与企业、腾讯云合作以及自主开发云产品的过程中，我们不断跟踪、监控、改进云的成本腾讯云「云端开发环境Cloud-简称CDE」日常开发实战案例自举分享，确保云的性价比优于现成的产品。做出了替代方案。
为了提高资源利用率，实现更好的成本控制，我们将自建的K8s集群迁移到腾讯云容器服务（原弹性容器服务EKS）。 我们的目的就是把资源搬到云端，充分利用云的资源利用率。 以及运维成本优势。
为了实现云迁移，我们做了很多架构上的重新设计。 首先，我们重新设计了工作区所依赖的所有专业功能：
去除OCI Hook特性依赖：在之前的工作空间资源持久化中，我们使用了CRI标准中的OCI Hook特性来实现用户持久层的保存和加载。 具体来说，在容器启动过程中，上层镜像被替换成了我们为用户准备的ext4虚拟磁盘来持久化数据。 在云上，显然我们无法利用这些功能，因为我们无法完全预测底层是否会兼容 OCI Hook。 为此，我们重新设计了用户容器，采用了两层架构。 在外层，我们用一个标准的容器提供一个标准的环境，然后在这个环境下运行一个容器，然后通过内层镜像获取层信息，将用户持久层组装成*终的运行。
去除功能依赖：Cloud团队非常重视容器启动性能，而从Ops角度出发的k8s自然不会特别关注容器镜像下载速度的问题。 因此，为了提高用户所需的容器加载速度，我们之前采用的是预热所有用户所需的基础镜像，保证了用户镜像的加载速度，但它的特性天然就和云冲突了，因为云的理念是用户不关心节点资源。 为了处理这个问题，我们完全重新设计了用户容器的镜像预热逻辑，除了按需向k8s提供资源需求之外，我们还引入了一层缓存，也就是说我们会从k8s中申请一个pod进步。 和之前不同的是，如果我们申请一个节点，那么该节点的资源是固定的，但是申请一批pod就不一样了。 基于业务需求，我们可以容忍一定的资源超售，所以我们申请的资源很少。 同时我们使用limit来限制容器的*大资源，以保证尽可能的平衡。 资源需求，*终设计了基于k8s调度的重新调度策略，对每个缓存pod进行评分，并为每个用户选择性能*好的pod。
除了这些逻辑上的重大改变之外，我们还有很多其他的优化点比如流量导入策略、实时计费信息采集等，*终形成了真正契合云原生设计、能够满足云原生设计需求的云原生设计。资源利用率高。 工作区设计，以下是改动图：
图 9：资源利用率 - 每个 Pod 都有它需要的一切
我们提供完整的持久化能力，这比我们的竞争对手更有价值。 自从引入 NFS 以来，我们必须确保有效地使用计算和存储资源，因此我们实施了多项改进：
到目前为止，我们已尽力控制成本并努力优化性能和使用情况。 与旧的开发环境相比，改进效果非常显着。
产品监测指标
云运行在TKE集群和标准K8S上，如图10所示，定义了全链路性能指标。 我们通过各种缓存解决方案实现并超越了性能限制。
图10：基于K8S（TKE）的云开发环境性能指标定义
在我们优化之前，云冷启动大约需要 19 秒。 我们分析了各种典型场景，*后绘制了主要阻塞点的耗时情况：
图 11：瓶颈
同时我们分析了这个严重阻塞项与节点内容器数量的关系：
图 12：分析
经过不断优化：
图13：优化后
冷启动时间缩短至5-7秒。 第二次启动时间缩短至5S以内。
我们的进步
05
云原生开发调试+云开发环境
云原生调试是我们考虑将测试转移到云集成开发环境左侧的另一种方式。 从IDE本身开始，云原生服务的开发和调试也作为IDE的一部分包含在内软件开发，这样任何开发者都可以在IDE编辑器中一键使用。 部署一整套云原生应用，轻松使用当前代码劫持当前关注的一个或多个服务的服务流量，打开断点调试器进行调试，或者与其他团队成员进行实时联调。
2021年底，团队将框架贡献给CNCF。 接下来的时间，Cloud团队一直致力于与Cloud IDE集成，实现开发集群下的联合开发调试和测试转移。 通过云团队集群下的独占和正交能力，我们尝试让团队简化云原生开发阶段，更向左发现问题。 如图14所示，John和Peter正在其中一个开发集群上进行前后端联合调试，将服务Pod更换为Cloud IDE，然后调试发现问题。 我录了一个视频，简单介绍一下。
图14：资源服务化
06
