四川建设厅招投标官方网站,服饰东莞网站建设,百度收录排名怎么上去,网站建设模块方案简介#xff1a; 究竟什么是云原生DevOps呢#xff1f;我们认为#xff1a;云原生DevOps是充分利用云原生基础设施#xff0c;基于微服务/无服务架构体系和开源标准#xff0c;语言和框架无关#xff0c;具备持续交付和智能自运维能力#xff0c;从而做到比传统DevOps更… 简介 究竟什么是云原生DevOps呢我们认为云原生DevOps是充分利用云原生基础设施基于微服务/无服务架构体系和开源标准语言和框架无关具备持续交付和智能自运维能力从而做到比传统DevOps更高的服务质量、更低的开发运维成本让研发专注于业务的快速迭代。 1、什么是云原生DevOps
我们先通过一个简单的例子来了解什么是云原生DevOps它和DevOps有什么不同。 上图是一个大排档图中的大厨在非常努力的去切、炒、制作各种美食并将它卖出去。从原材料的采购到加工到销售到售后都是一两个人完成。这是非常典型的DevOps场景团队搞定端到端的所有的事情。这种情况当厨师水平比较高、销售能力比较强的时候可以做到高效率、低浪费。但存在的问题是想要规模化会很难。因为它的流程都是非标准的需要厨师有很强的个人能力。 我们再看这张南京大排档的图虽然名字里有大排档但它显然不是我们上面说的大排档。我们随便走进任何一家南京大排档都可以发现南京大排档的厨师可以专注在为客户提供更好的菜品上研发试验新菜品并通过小批量的用户来尝试和推广。无论是用户量增加或减少都能很快的去适应。店铺扩张也可以很快。这种我们可以理解为云原生DevOps。
那究竟什么是云原生DevOps呢我们认为云原生DevOps是充分利用云原生基础设施基于微服务/无服务架构体系和开源标准语言和框架无关具备持续交付和智能自运维能力从而做到比传统DevOps更高的服务质量、更低的开发运维成本让研发专注于业务的快速迭代。 如上图所示云原生DevOps基于2个原则符合开放标准、语言和框架无关有2个基础微服务/无服务架构、Serverless基础设施 BaaS/FaaS提供2个能力智能自运维、持续交付。
符合开放标准、语言和框架无关相比于针对某个特定语言、特定框架在技术升级或迭代时可以有更高的弹性、更好的发展和生命力形成更好的生态。 2个基础基于微服务和无服务架构可以让DevOps成为可能基于Serverless的基础设施是面向资源和需求以达到更好的弹性。 在这2个原则和2个基础之上做到2个能力持续交付和智能自运维。
2、阿里巴巴云原生DevOps升级案例
我们先来看一个阿里某团队云原生DevOps转型的案例。
案例背景阿里某海外电商团队面临海外市场站点多、建站成本高、需求变化快、交付慢、运维成本高等挑战如何平滑地升级到云原生DevOps 来解决这些问题以提升业务交付效率呢我们是这么做的。1架构升级 - 服务治理sidecar和mesh化 第一步是架构升级首先将服务治理的代码下沉到应用之外的sidecar部分同时用服务网格来承载了如环境路由之类的能力。如上图所示每个绿点代表一个服务应用代码每一个橘点代表一个服务治理代码这些代码以二方包的形式存在这个容器中。随着服务治理体系的建设这里面就包含了非常多的东西如日志采集、监控埋点、运维干预等等我们把这种容器称之为富容器。它的问题很明显即便是日志采集的升级或调整我们都需要把应用重新升级、构建和部署一遍。然而这个其实与应用本身是没有任何关系的。同时因为关注点不分离日志采集的一个bug都会影响到应用本身。 本着让应用能更专注于应用本身的目的我们做的第一件事就是把所有服务治理的代码从应用容器中剥离出来放到了sidecar里面这样服务治理和应用的代码就存在两个容器里了。同时我们又把原来服务治理的一些事情比如测试路由、链路追踪等交给了Mesh sidecar 。这样应用就瘦身了应用只需要关心应用代码的本身。
这样做的好处是业务可以专注于业务相关的应用代码而无需依赖于服务治理了。
这是第一步这一步是平滑的因为我们可以逐步把服务治理迁移到sidecar里面不用担心一次迁移成本过大。2架构升级 - 从构建解耦、发布解耦到运维解耦 第二步我们做了三个层面的解耦构建解耦、发布解耦、运维解耦。
了解微服务和无服务架构的人应该清楚只有当一个业务能够独立去开发、测试、发布、运维的时候业务才能跑得更快、更好。因为这样跟其他人的耦合性降到最低。
但是我们也知道随着业务越来越复杂和应用的持续演进应用里会包含越来越多的业务代码。比如下图中这个应用它里面有一些代码是针对某个特定业务的比如作为一个支付应用有的是针对盒马的特定需求的有的是针对天猫的特定需求的还有一些是通用代码或者叫平台代码是针对所有业务场景的。 显然从提高开发效率的角度讲业务方改自己相关的业务代码可以减少沟通成本提高研发效率。但这带来了一个新的问题如果某一个业务有需求改动但并不涉及通用的业务逻辑时也需要对整个应用的所有业务进行全面回归如果这个时间段还有其他业务改动他们需要一起集成并进行发布。如果改动的业务多大家就需要排队集成。这种情况下集成测试和沟通协调的成本非常高。
我们的目标是每个业务都能独立的开发、发布和运维。为了平滑地达到这个目标我们首先要做的是让它们在构建阶段能够解耦。比如对一个相对独立的业务我们将其单独构建为一个容器镜像并通过编排把它放到Pod的init Container中Pod启动的时候再将其挂载到主应用容器的存储空间。
但是这时应用的发布和运维还是在一起的我们需要将它们分开。
我们知道应用的亲密性粗略可以分为三类 一、超亲密在同一个进程中通过函数调用通信 二、位于同一个Pod的不同容器通过IPC通信 三、位于同一个网络中通过RPC通信 我们可以根据业务的特点逐步地把一些业务代码拆分成一个个RPC或者IPC服务这样它们就可以独立的发布和运维了。 至此我们就完成了应用容器的构建解耦、发布解耦和运维解耦。
3IaC GitOps 第三步我们看一下开发和运维态。在很多研发场景中一个棘手的问题是不同的环境和业务会有非常多的自己特有的配置在发布和运维时经常需要根据情况修改和选择正确的配置而这个配置和应用代码本身其实就是发布的一部分传统的通过控制台去维护的方式成本将会非常高。
在云原生背景下我们认为IaCInfrastructure as Code和GitOps是更好的选择。每个应用除了有一个代码库之外我们还有一个IaC 仓库。这个仓库里面会包含应用的镜像版本和所有相关的配置信息。当代码变更需要发布或配置有变化时都通过代码push 的形式推送到IaC 仓库。GitOps引擎能自动检测到IaC的变化并自动将其翻译为符合OAM规范的配置,然后基于OAM 模型把改动应用到对应的环境上。无论是开发还是运维都可以通过 I aC 的代码版本了解到系统发生了哪些变化而且每次发布都是完整的。
4资源的BaaS化 最后一步是资源的BaaS化。 我们想象一下在应用中是怎么去使用资源的。我们一般会先去对应的控制台提交资源申请描述我们需要的资源规格和要求然后通过审批后得到资源的连接串和认证信息。在应用的配置中加上资源配置之后如果有改动在到对应的控制台操作并配合代码发布进行审批。当然对于这类资源的运维和监控一般也是在独立的控制台进行的。 当我们的资源种类越来越多操作和维护成本就非常高了尤其是在新建站点的时候。 本着用声明式的方式去描述资源、按需使用的原则我们通过在IaC 里定义这些资源的方式去简化所有应用对资源的使用。所有的资源都是声明式的描述能够实现资源的智能管理和按需使用。同时我们所有的资源都采用的是云上通用资源、标准协议极大降低了迁移成本。这样我们就逐步把业务团队迁移到云原生基础设施上。 所以资源BaaS化的两大关键点是
声明式地描述资源需求智能管理按需使用采用云上通用资源对齐标准协议
3、云效驱动云原生DevOps高效落地
上面我们分享的是阿里内部的实践它依赖于阿里内部的研发协作平台Aone。Aone的公有云版本即阿里云云效。我们如何通过阿里云云效去落地云原生DevOps呢 从前面的案例我们可以看到云原生DevOps的落地是一个系统性的工程包含方法、架构、协作和工程各个方面。其中云原生DevOps的落地属于精益交付的范畴。 上图是云效云原生DevOps解决方案图。 这里我们将用户分为2种角色
技术主管或架构师工程师包括开发、测试和运维等
作为技术主管或架构师他需要从整体上去定义和把控企业的研发行为。从大的角度讲研发过程包含四个方面可运行、可观测、可治理、可变更。
首先他会去定义企业的研发协作模式例如是采用敏捷研发还是精益看板。其次他需要掌握整体的产品架构、如需要用到哪些云产品、这些云产品如何协调和管理等。然后他会去决定团队的研发模式怎么做好研发协作怎么把控研发质量等。第三步他需要确定发布策略采用灰度发布还是蓝绿部署灰度策略是什么等等。最后就是服务的监控策略比如服务需要接入哪些监控平台怎么探测服务状态全局监控配置等等。 一线开发、测试、运维工程师关注的是工作过程地顺畅和高效。在云效项目协作平台接收到一个需求或任务之后可以通过云效去编码、提交、构建、集成、发布和测试并部署到预发和生产环境上将管理员配置的研发模式、发布策略真正落地。同时各个环境都是自动触发和流转的不需要人为地协调和拉动。
整个研发过程中产生的数据是一个有机的整体可以产生大量的数据洞察可以驱动团队进行持续改进。当团队在研发过程中遇到瓶颈或迷茫时还可以从云效专家团队获得专业的诊断建议和研发指导。
总结一下云效的云原生DevOps解决方案是在ALPD方法论指导下基于专家建议的最佳实践深度整合到完整的DevOps工具链中帮助企业渐进式地迈入云原生DevOps。
接下来我们看一个具体的案例。
某互联网企业研发团队在30人左右没有专职的运维人员产品包括20多个微服务以及几十个前端应用web、小程序、APP等。其业务增长非常快在面对快速增长的客户和越来越多的需求情况下原先基于JenkinsECS的脚本为主的部署方式渐渐无法满足诉求特别是无法解决零停机部署升级的问题。于是开始需求云效的帮助并最终全面迁移到云效云原生DevOps。
这个研发团队主要面临三大痛点
客户量大、紧急需求多无专职运维、云原生技术如K8S的学习门槛高IT基础设施架构复杂、发布耗时耗力
针对这些问题云效从基础能力、发布能力和运维能力三个方面入手。
首先引入阿里云ACK在已有ECS资源之上进行基础设施升级应用进行容器化改造。在服务治理和应用架构上从Spring Cloud全家桶简化为SpringBoot通过K8S标准能力支撑服务发现和治理。
其次通过云效流水线实现自动化容器部署配合灰度部署策略做到灰度上线自动扩容出现故障自动重启同时基于云效流水线做到零停机快速回滚任意成本节约机器成本的同时解决了企业无专职运维人员的问题。
第三通过云效自动化流水线和分支保护规范研发模式包括代码评审、代码检测、测试卡点等提升反馈效率和发布质量。
下图为整体解决方案的架构图。 4、云原生DevOps升级路径
我们将云原生DevOps落地分为5个阶段。 第一个阶段全手工交付和运维。它是我们最初始的阶段应用架构还没有进行服务化改造也没有使用云基础设施或仅使用IaaS没有持续集成、测试自动化使用手工部署发布和手工运维。相信很少还有企业停留在这个阶段了。
第二个阶段工具化地交付和运维。首先要做的是应用架构的服务化采用微服务架构改善服务质量其次是引入一些研发工具如gitlab、jenkins这类孤岛式的工具解决部分问题。同时我们开始落地单模块的持续集成但是一般还没有实现自动化的质量卡点发布往往有自动化工具进行辅助。
第三个阶段有限制的持续交付和自动化运维。我们进一步提升基础能力将基础设施进行容器化改造基于CaaS建设。另一方面开始引入完整的工具链打通研发数据例如使用云效DevOps这样的工具平台,实现所有数据的完整互通。在发布能力上能做到持续部署但是还需要一定的人工干预。这时自动化测试已经成为主流了服务整体可以观测运维能够面向服务并且是声明式的。
第四个阶段持续交付和人工辅助自运维。我们进一步让开发同学专注于业务开发首先在应用架构上开始大量采用无服务架构并做到无人值守的持续部署发布的灰度和回滚能够在有干预的情况下尽量的自动化。观测能力从应用级别提升到业务级别实现业务的可观测性并且能够在人工辅助的情况下做到部分的自运维。
第五个阶段全链路持续交付和自运维。这是我们追寻的终极目标。这个阶段我们所有的应用和基础设施采用的都是无服务架构并做到端到端的无人值守持续交付包括发布的回滚和灰度也是自动化的技术设施和服务完全实现自运维。开发者真正只需要关心业务的开发和迭代。
但是魔鬼都在细节处当然我们真正的落地的时候仍有很多的问题需要我们去解决借助云效这样的工具平台和ALPD的专家咨询可以让我们少走弯路更快的实现目标。
作者小攻云攻略
原文链接
本文为阿里云原创内容未经允许不得转载
