深度好文｜探寻云原生时代应用研发新模式

Posted 2022-04-14 尔达Erda

---

引言：伴随着基础设施技术升级，应用研发环境也从最初的传统 IT 架构、虚拟化 & 容器化架构演变到现在的云原生多云架构。“应用研发新模式”本身就是一个比较大的话题，我们也不敢说一个人或者一个团队就能把这个话题聊透彻。但随着应用研发基础架构环境的演进，应用研发模式一定是在不断地调整和创新。

---

今天我们大胆把话题抛出来，聊聊自己的一些想法，和大家一起探讨、共创云原生时代应用研发模式后续的演进路线。

DevOps 平台现状和痛点

（应用研发架构演进路线）
本文暂将应用研发架构的演进路线归纳为四个阶段（如上图），传统 IT 架构和虚拟架构下的应用研发，相信大家都比较熟悉，DevOps 的概念在这两个阶段几乎没有激起什么水花，所以这两个阶段我们就不展开阐述了。
伴随容器技术的出现（特别是 Docker 和 Kubernetes，后续简称 K8s），让 DevOps 概念火了一把，也在实践中开始快速落地和普及。容器能够封装微服务整个运行时环境的特性，天然就适用于微服务构建、发布和运行，让原本缓慢前进的 DevOps 得到飞速发展，开源社区也涌现了很多优秀的开源产品（比如 Jenkins、GitLab 等），大家通过这些开源产品能够快速搭建自己应用的持续集成环境，因此市场上也如雨后春笋般冒出许多 DevOps 相关的产品。
现阶段中的 DevOps 产品通过 Docker 和 K8s 确实帮助用户解决了资源管理、微服务环境构建和持续集成的复杂、效率低等问题，但是伴随公有云等 Infra 基础设施持续高速发展，人们对于应用研发的效率追求也会有更高的要求，对于 DevOps 产品也不会满足停留在当前阶段（微服务应用的持续构建部署），那么如何在 DevOps 现阶段的版本基础上进一步提高研发效率和质量呢？我们还是一起通过梳理当前研发过程中面临的痛点出发吧！

痛点 1：多云资源如何统一管理，解绑云厂商？

在公有云、私有云等多元化的云环境下，大家手头往往都有两套或者多套云资源，如何让这些割裂的云资源统一进行管理？如何基于一个平台让应用快速进行跨云迁移、发布？比如：开发在私有云，生产在公有云等这些问题伴随资源环境多元化问题会越来越突出。

痛点 2：复杂微服务组合如何快速进行环境构建、持续集成？

当前 DevOps 对于单个微服务的环境构建和持续集成问题已经基本解决。但对于企业级软件研发交付团队来说，错综复杂的微服务组合而成的项目如何进行统一的环境构建、部署和交付，目前仍解决得不太彻底，只能让各应用的研发成员都参与到构建、部署的整个阶段。以上复杂的过程容易引起问题不说，效率成本上也是个大问题。

痛点 3：研发效能如何进一步提升？

在当前主流的 DevOps 产品中，代码、构建、部署全流程自动化触发执行的特性基本都是得到了比较好的解决，但是随着研发管理的深度、精细度要求越来越高，需要研发同学维护的数据也随之不断增多，管理维护项目数据的项目管理工作量也在不断增大，效率和成本这组矛盾如何得到妥善处理？
新一代 DevOps 不仅应有效解决上述痛点，还应具有测试安全的左移、研发效能度量等更多开放性能力，这个全新的时代需要有更全面、更创新的特性。

新一代 DevOps 的特性

多云管理

多云管理并不是简单指通过 K8s 集群来实现资源的调度管理，如果仅仅是统一资源调度那本身是 K8s 集群的特性。
通过应用部署环境配置去关联集群，确实可以实现环境之间的隔离、环境之间快速迁移的能力，就如上面提到的：开发测试在本地私有云环境，生产可以通过同一套代码能够快速发布到公有云；还有就是业务在一个集群，数据处理可以在另外一个集群，实现业务和数据分离，两者互不影响，这些都可以通过集群管理来实现。

既然说了这么多都是和集群相关的，那么和多云管理有什么关系呢？
首先，我们对 K8s 集群的节点管理，希望可以一个平台上统一便捷购买/释放主流公有云厂商的资源节点。
其次，现在公有云上都有容器相关的服务提供，平台只需要调度管理这些容器服务即可，所有容器服务的对接管理（包含但不仅限于容器服务的购买、释放、扩缩容等）都需要在平台完成。
再者，公有云上其他的云服务都可以通过平台进行购买直接使用，无需用户不断切换登陆到各公有云的控制台，最后进行云资源的统计分析、资源成本的运营分析，帮助企业在资源方面进行降本增效。这些都是多云管理的范畴之内。
Erda 目前在 K8s 集群管理、公有云服务对接管理方面都是做得比较好的，大家可以体验使用，对这部分内容感兴趣的同学欢迎联系我们，一起沟通、碰撞想法。

项目级持续集成

目前，对于单应用的持续构建部署，DevOps 的业界产品基本都是达成共识的，对于单个微服务应用构建部署的自动化完善程度较好。
但是对于企业级项目研发过程，我们一起来回想看看，比如：单应用内不同任务需要拉多分支来进行开发（基于主干开发的模式可能没有这个问题），受开发环境资源的限制，不同任务开发同学要不断进行线下沟通合并代码发布开发环境（或者测试环境）进行测试，过程中可能存在谁的代码分支有问题导致整个环境不可用的现象，oh my god！
项目级的联调部署就更复杂了，首先需要配置项目环境，其中包含了项目级的参数配置以及大家公用的项目级中间件准备部署；其次是复杂的微服务编排信息维护，这些繁琐的项目级维护管理动作，往往会导致项目部署过程中出现各种阻塞，比如项目共同的中间件准备阻塞，上游服务的部署和健康度也会影响或阻塞下游服务部署和测试等，这些问题会让项目部署更加困难化。

既然已经分析出问题的所在，那么我们一起来看下 Erda 的解决之道。
Erda 坚持以应用为中心，在单应用的研发过程中，基于任务分支开发的模式下（这里说明一下，Erda 产品本身的研发团队是基于主干开发来实现每日集成的），研发同学只要保证自己分支质量的基础上，随时可以发布到开发环境进行测试和验证。
那么细心的同学肯定会发现如果开发环境只有一套，相同应用下有其他研发任务分支的同学该怎么办？这里就先透露一下 Erda 接下来即将规划的功能：大家只管发自己的分支部署，分支之间的临时合并后部署的事情，就交给 Erda 平台来完成吧