关于云原生:深度好文|探寻云原生时代应用研发新模式

36次阅读

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


引言:随同着基础设施技术升级,利用研发环境也从最后的传统 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 平台来实现吧😄。

我的项目级构建部署的问题,Erda 通过 我的项目级流水线 制品 环境部署(其实是环境筹备和部署两个环节)三个重要个性来解决的。

首先,在利用通过代码继续构建部署到开发 / 测试环境,实现了代码到服务的全流程自动化。

其次,我的项目中共用的中间件进行了对立治理。这里的中间件不仅笼罩了平台内置丰盛的中间件服务,还提供了私有云上的存储类中间件,甚至还反对通过自定义中间件的形式来治理对接用户本人部署保护的中间件。这些中间件在 Dice.yml 中能够一键部署,实现真正我的项目级的中间件治理,彻底解决用户依赖中间件的懊恼。

后面提到了代码到服务的全流程自动化,其实制品到服务也是这个全流程中的一个环节。利用研发同学在开发环境冒烟测试通过后,测试同学能够基于利用制品能够组合成我的项目制品,通过我的项目制品 + 环境配置,能够疾速在测试环境上部署测试(基于骨干开发的话,这些步骤都是能够全自动化实现),测试同学通过自动化测试和手动测试确保我的项目品质达标后,就能够一键公布我的项目制品,前期我的项目交付施行同学能够基于此制品到客户环境上进行疾速交付或降级利用。

研发流程的自动化

上述的代码到服务、制品到服务的全流程当然是在研发全流程自动化中进行的。除此之外,在优雅解决研发效力度量数据采集的同时,还要让咱们的研发同学尽量少做一些保护工作,比方:需要工作拆解后,工作的状态、备注是否可能主动流转,不须要刻意地登陆到平台去进行保护就能实现。研发同学在进行沉迷式本地开发的同时,就能实现相干工作。

这个也是 Erda 以后重点在解决的事件,研发角色在对立平台进行高效协同的认知角度可能也会适当调整一下。不同研发角色的协同数据在对立平台,具体的协同能够由多元化的端能力来实现,让用户在不感知平台的状况下,无时无刻不在应用平台的能力,比方:通过 ChatOps,让信息及时触达到用户后,用户能够在实时通信 APP 中疾速解决,解决后的数据会返回平台进行对立计算剖析,随同用户在实时通信 APP 的解决,相干 Issue 事项的备注、截止日期、状态等属性信息也在同步进行自动化流转解决。

视频内容见文章内 Erda 产品全景图

研发流程自动化还能够体现在 Issue、代码、测试、环境实例之前的全方位自动化,通过 Issue 和代码分支的绑定,研发同学本地提交 / 合并代码后就会主动触发相干 Issue 状态流转、代码自动化构建部署、自动化测试、我的项目制品合成、制品 Changelog 的主动生成等全链路的自动化。

以上仅仅列举了新一代 DevOps 的局部个性,对于其余个性,都应该围绕效率、老本和品质这个铁三角开展,去发明更多有意义、有价值的新个性。

本文只发表了一些集体对于 DevOps 演进的局部观点,置信其余小伙伴必定有更好的的想法,如果大家对于本话题感兴趣,欢送分割咱们一起深入探讨。咱们将定期组织小伙伴围绕相干话题进行继续探讨推动,期待更多小伙伴的退出!


咱们致力于决社区用户在理论生产环境中反馈的问题和需要,如果您有任何疑难或倡议,欢送关注 【尔达 Erda】公众号 给咱们留言,退出 Erda 用户群参加交换或在 Github 上与咱们探讨!

Erda Github 地址
Erda Cloud 官网

正文完
 0