如何落地云原生DevOps?

简介: 什么是云原生DevOps?在阿里内部有怎样的实践?企业又该如何落地?阿里云云效专家团队提出了下一代精益产品开发方法体系——ALPD,提供了系统的云原生DevOps落地的方法支撑,帮助企业渐进式地迈入云原生DevOps。本文结合实际案例,分享通过阿里云云效落地云原生DevOps的五个阶段。

image.png

一 什么是云原生DevOps

我们先通过一个简单的例子来了解什么是云原生DevOps,它和DevOps有什么不同。

image.png

上图是一个大排档,图中的大厨在非常努力的去切、炒、制作各种美食,并将它卖出去。从原材料的采购到加工到销售到售后,都是一两个人完成。这是非常典型的DevOps场景,团队搞定端到端的所有的事情。这种情况,当厨师水平比较高、销售能力比较强的时候,可以做到高效率、低浪费。但存在的问题是,想要规模化会很难。因为它的流程都是非标准的,需要厨师有很强的个人能力。

image.png

我们再看这张南京大排档的图,虽然名字里有大排档,但它显然不是我们上面说的大排档。我们随便走进任何一家南京大排档,都可以发现,南京大排档的厨师,可以专注在为客户提供更好的菜品上,研发试验新菜品,并通过小批量的用户来尝试和推广。无论是用户量增加或减少,都能很快的去适应。店铺扩张也可以很快。这种我们可以理解为云原生DevOps。

为了进一步方便大家理解,下面的小视频里,我们邀请了2位阿里大厨,让他们告诉你什么是云原生DevOps。

视频链接:https://v.qq.com/x/page/u3220cutt7v.html

所以,总结来看,我们认为:云原生DevOps是充分利用云原生基础设施,基于微服务/无服务架构体系和开源标准,语言和框架无关,具备持续交付和智能自运维能力,从而做到比传统DevOps更高的服务质量、更低的开发运维成本,让研发专注于业务的快速迭代。

image.png

如上图所示,云原生DevOps基于两个原则:符合开放标准、语言和框架无关;有两个基础:微服务/无服务架构、Serverless基础设施 BaaS/FaaS;提供两个能力:智能自运维、持续交付。

  • 符合开放标准、语言和框架无关,相比于针对某个特定语言、特定框架,在技术升级或迭代时可以有更高的弹性、更好的发展和生命力,形成更好的生态。

  • 两个基础:基于微服务和无服务架构,可以让DevOps成为可能;基于Serverless的基础设施,是面向资源和需求,以达到更好的弹性。

  • 在这两个原则和两个基础之上,做到两个能力:持续交付和智能自运维。

二 阿里巴巴云原生DevOps升级案例

我们先来看一个阿里某团队云原生DevOps转型的案例。

案例背景:阿里某海外电商团队面临海外市场站点多、建站成本高、需求变化快、交付慢、运维成本高等挑战,如何平滑地升级到云原生DevOps来解决这些问题,以提升业务交付效率呢?我们是这么做的。

1 架构升级——服务治理sidecar和mesh化

 

image.png

第一步是架构升级,首先将服务治理的代码下沉到应用之外的sidecar部分,同时用服务网格来承载了如环境路由之类的能力。如上图所示,每个绿点代表一个服务应用代码,每一个橘点代表一个服务治理代码,这些代码以二方包的形式存在这个容器中。随着服务治理体系的建设,这里面就包含了非常多的东西,如日志采集、监控埋点、运维干预等等,我们把这种容器称之为富容器。它的问题很明显:即便是日志采集的升级或调整,我们都需要把应用重新升级、构建和部署一遍。然而这个其实与应用本身是没有任何关系的。同时,因为关注点不分离,日志采集的一个bug,都会影响到应用本身。

image.png

本着让应用能更专注于应用本身的目的,我们做的第一件事就是把所有服务治理的代码从应用容器中剥离出来,放到了sidecar里面,这样服务治理和应用的代码就存在两个容器里了。同时我们又把原来服务治理的一些事情,比如测试路由、链路追踪等交给了Mesh sidecar 。这样应用就瘦身了,应用只需要关心应用代码的本身。

这样做的好处是,业务可以专注于业务相关的应用代码,而无需依赖于服务治理了。
这是第一步,这一步是平滑的,因为我们可以逐步把服务治理迁移到sidecar里面,不用担心一次迁移成本过大。

2 架构升级——从构建解耦、发布解耦到运维解耦

第二步,我们做了三个层面的解耦:构建解耦、发布解耦、运维解耦。

了解微服务和无服务架构的人应该清楚,只有当一个业务能够独立去开发、测试、发布、运维的时候,业务才能跑得更快、更好。因为这样跟其他人的耦合性降到最低。

但是我们也知道,随着业务越来越复杂和应用的持续演进,应用里会包含越来越多的业务代码。比如下图中这个应用,它里面有一些代码是针对某个特定业务的,比如作为一个支付应用,有的是针对盒马的特定需求的,有的是针对天猫的特定需求的,还有一些是通用代码,或者叫平台代码,是针对所有业务场景的。

image.png

显然,从提高开发效率的角度讲,业务方改自己相关的业务代码,可以减少沟通成本,提高研发效率。但这带来了一个新的问题:如果某一个业务有需求改动,但并不涉及通用的业务逻辑时,也需要对整个应用的所有业务进行全面回归,如果这个时间段还有其他业务改动,他们需要一起集成并进行发布。如果改动的业务多,大家就需要排队集成。这种情况下,集成测试和沟通协调的成本非常高。

我们的目标是每个业务都能独立的开发、发布和运维。为了平滑地达到这个目标,我们首先要做的是让它们在构建阶段能够解耦。比如,对一个相对独立的业务,我们将其单独构建为一个容器镜像,并通过编排把它放到Pod的init Container中,Pod启动的时候,再将其挂载到主应用容器的存储空间。

但是这时,应用的发布和运维还是在一起的,我们需要将它们分开。

我们知道,应用的亲密性粗略可以分为三类:

  • 超亲密,在同一个进程中,通过函数调用通信。

  • 位于同一个Pod的不同容器,通过IPC通信。

  • 位于同一个网络中,通过RPC通信。

我们可以根据业务的特点,逐步地把一些业务代码拆分成一个个RPC或者IPC服务,这样它们就可以独立的发布和运维了。

至此我们就完成了应用容器的构建解耦、发布解耦和运维解耦。

3 IaC & GitOps

image.png

第三步我们看一下开发和运维态。在很多研发场景中,一个棘手的问题是:不同的环境和业务会有非常多的自己特有的配置,在发布和运维时经常需要根据情况修改和选择正确的配置,而这个配置和应用代码本身其实就是发布的一部分,传统的通过控制台去维护的方式成本将会非常高。

在云原生背景下,我们认为IaC(Infrastructure as Code)和GitOps是更好的选择。每个应用除了有一个代码库之外,我们还有一个IaC 仓库。这个仓库里面会包含应用的镜像版本和所有相关的配置信息。当代码变更需要发布或配置有变化时,都通过代码push 的形式推送到IaC仓库。GitOps引擎能自动检测到IaC的变化,并自动将其翻译为符合OAM规范的配置,然后基于OAM模型把改动应用到对应的环境上。无论是开发还是运维,都可以通过 IaC 的代码版本了解到系统发生了哪些变化,而且每次发布都是完整的。

4 资源的BaaS化

image.png

最后一步是资源的BaaS化。

我们想象一下在应用中是怎么去使用资源的。我们一般会先去对应的控制台提交资源申请,描述我们需要的资源规格和要求,然后通过审批后得到资源的连接串和认证信息。在应用的配置中加上资源配置,之后如果有改动,再到对应的控制台操作,并配合代码发布进行审批。当然,对于这类资源的运维和监控一般也是在独立的控制台进行的。

当我们的资源种类越来越多,操作和维护成本就非常高了,尤其是在新建站点的时候。

本着用声明式的方式去描述资源、按需使用的原则,我们通过在IaC 里定义这些资源的方式,去简化所有应用对资源的使用。所有的资源都是声明式的描述,能够实现资源的智能管理和按需使用。同时我们所有的资源都采用的是云上通用资源、标准协议,极大降低了迁移成本。这样我们就逐步把业务团队迁移到云原生基础设施上。

所以,资源BaaS化的两大关键点是:

  • 声明式地描述资源需求,智能管理,按需使用。

  • 采用云上通用资源,对齐标准协议。

三 云效驱动云原生DevOps高效落地

上面我们分享的是阿里内部的实践,它依赖于阿里内部的研发协作平台Aone。Aone的公有云版本即阿里云云效。我们如何通过阿里云云效去落地云原生DevOps呢?

image.png

ALPD——云原生时代的研发新范式

从前面的案例我们可以看到,云原生DevOps的落地是一个系统性的工程,需要有系统的方法和工具体系支撑。上图是阿里云云效专家团队提出的下一代精益产品开发方法体系——ALPD,可以看到,ALPD提供了系统的云原生DevOps落地的方法支撑(图中篮筐所示)。

image.png

上图是云效云原生DevOps解决方案图。

这里,我们将用户分为2种角色:

  • 技术主管或架构师。

  • 工程师,包括开发、测试和运维等。

作为技术主管或架构师,他需要从整体上去定义和把控企业的研发行为。从大的角度讲,研发过程包含四个方面:可运行、可观测、可治理、可变更。

首先他会去定义企业的研发协作模式,例如是采用敏捷研发还是精益看板。其次他需要掌握整体的产品架构、如需要用到哪些云产品、这些云产品如何协调和管理等。然后他会去决定团队的研发模式:怎么做好研发协作,怎么把控研发质量等。第三步,他需要确定发布策略,采用灰度发布还是蓝绿部署,灰度策略是什么等等。最后,就是服务的监控策略,比如服务需要接入哪些监控平台,怎么探测服务状态,全局监控配置等等。

一线开发、测试、运维工程师,关注的是工作过程的顺畅和高效。在云效项目协作平台接收到一个需求或任务之后,可以通过云效去编码、提交、构建、集成、发布和测试,并部署到预发和生产环境上,将管理员配置的研发模式、发布策略真正落地。同时,各个环境都是自动触发和流转的,不需要人为地协调和拉动。

整个研发过程中产生的数据是一个有机的整体,可以产生大量的数据洞察,可以驱动团队进行持续改进。当团队在研发过程中遇到瓶颈或迷茫时,还可以从云效专家团队获得专业的诊断建议和研发指导。

总结一下,云效的云原生DevOps解决方案是在ALPD方法论指导下,基于专家建议的最佳实践,深度整合到完整的DevOps工具链中,帮助企业渐进式地迈入云原生DevOps。

接下来,我们看一个具体的案例。

某互联网企业,研发团队在30人左右,没有专职的运维人员,产品包括20多个微服务以及几十个前端应用(web、小程序、APP等)。其业务增长非常快,在面对快速增长的客户和越来越多的需求情况下,原先基于Jenkins+ECS的脚本为主的部署方式渐渐无法满足诉求,特别是无法解决零停机部署升级的问题。于是,开始需求云效的帮助,并最终全面迁移到云效云原生DevOps。

这个研发团队主要面临三大痛点:

  • 客户量大、紧急需求多。

  • 无专职运维、云原生技术如K8S的学习门槛高。

  • IT基础设施架构复杂、发布耗时耗力。

针对这些问题,云效从基础能力、发布能力和运维能力三个方面入手。

首先,引入阿里云ACK在已有ECS资源之上进行基础设施升级,应用进行容器化改造。在服务治理和应用架构上,从Spring Cloud全家桶简化为SpringBoot,通过K8S标准能力支撑服务发现和治理。

其次,通过云效流水线实现自动化容器部署,配合灰度部署策略,做到灰度上线,自动扩容,出现故障自动重启,同时,基于云效流水线做到零停机快速回滚任意成本,节约机器成本的同时解决了企业无专职运维人员的问题。

第三,通过云效自动化流水线和分支保护规范研发模式,包括代码评审、代码检测、测试卡点等,提升反馈效率和发布质量。

下图为整体解决方案的架构图。

image.png

四 云原生DevOps升级路径

我们将云原生DevOps落地分为5个阶段。

image.png

第一个阶段:全手工交付和运维

它是我们最初始的阶段,应用架构还没有进行服务化改造,也没有使用云基础设施或仅使用IaaS,没有持续集成、测试自动化,使用手工部署发布和手工运维。相信很少还有企业停留在这个阶段了。

第二个阶段:工具化地交付和运维

首先要做的是应用架构的服务化,采用微服务架构改善服务质量;其次是引入一些研发工具,如gitlab、jenkins这类孤岛式的工具解决部分问题。同时我们开始落地单模块的持续集成,但是一般还没有实现自动化的质量卡点,发布往往有自动化工具进行辅助。

第三个阶段:有限制的持续交付和自动化运维

我们进一步提升基础能力,将基础设施进行容器化改造,基于CaaS建设。另一方面,开始引入完整的工具链,打通研发数据,例如使用云效DevOps这样的工具平台,实现所有数据的完整互通。在发布能力上能做到持续部署,但是还需要一定的人工干预。这时,自动化测试已经成为主流了,服务整体可以观测,运维能够面向服务,并且是声明式的。

第四个阶段:持续交付和人工辅助自运维

我们进一步让开发同学专注于业务开发,首先在应用架构上开始大量采用无服务架构,并做到无人值守的持续部署;发布的灰度和回滚,能够在有干预的情况下尽量的自动化。观测能力从应用级别提升到业务级别,实现业务的可观测性,并且能够在人工辅助的情况下做到部分的自运维。

第五个阶段:全链路持续交付和自运维

这是我们追寻的终极目标。这个阶段我们所有的应用和基础设施采用的都是无服务架构,并做到端到端的无人值守持续交付,包括发布的回滚和灰度也是自动化的;技术设施和服务完全实现自运维。开发者真正只需要关心业务的开发和迭代。

但是,魔鬼都在细节处,当然我们真正的落地的时候仍有很多的问题需要我们去解决,借助云效这样的工具平台和ALPD的专家咨询,可以让我们少走弯路,更快的实现目标。

作者:开发者小助手_LS

本文为阿里云原创内容,未经允许不得转载

 

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/514425.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

亚马逊独霸美国安云计算未来十年订单;英伟达推出首个元宇宙平台;华为云、天翼云会合并吗?...

NEWS本周新闻回顾亚马逊独霸美国安云计算未来十年订单,微软表示不服亚马逊AWS获得美国国家安全局100亿美元云计算合同。得知亚马逊拿下订单后,微软已向政府问责提交文件,提出抗议。最终……还是亚马逊笑到了最后英伟达推出全球首个元宇宙平台…

如何做好技术 Team Leader?

简介: 作为一个技术TL(Team Leader),除了自身技能,还会面临诸多团队管理上的困难和挑战。如何定义和明确团队的目标?怎样建立优秀的工程文化?让团队长期发挥战斗力和创新能力的核心是什么&#…

android应用控制百度地图,Android中应用百度地图API开发地图APP实例-显示百度地图...

场景效果在使用百度地图API之前需要先在百度地图开放平台中申请API_KEY申请API_KEY登录百度开放平台后找到控制台下的应用管理-创建应用依次输入应用名,应用类型选择Android SDK然后下面需要输入发布版SHA1和包名获取应用SHA1首先来到.Android文件所在的位置&#x…

数禾云上数据湖最佳实践

简介: 数禾科技从成立伊始就组建了大数据团队并搭建了大数据平台。并在ECS上搭建了自己的Cloudera Hadoop集群。但随着公司互联网金融业务的快速扩张发展,大数据团队承担的责任也越来越重,实时数仓需求,日志分析需求,即…

程序员只能吃“青春饭”?IT行业年龄焦虑如何破局?

2019 年搜狐科技《中国互联网简史》报告显示,国内近一半的程序员年龄在 25-29 岁之间,其次为 30-34岁,占比 24.6%,35 岁 -39 岁的程序员占比 6.1%,而 40岁 的程序员仅占 1.2%。由于程序员需要长时间面对电脑工作&#…

对容器镜像的思考和讨论

简介: 常言道,startup 有 startup 的好,大厂有大厂的好,那么大厂究竟好在哪呢?拿硅谷老牌大厂们 FLG 来说,如果要问最令人怀念的是什么?Free food 和基础设施(Infrastructure)一定是会上榜的&am…

android 高度上分权重,Android LinearLayout weight权重使用

在日常的开发过程中,我们通常或多或少会使用到LinearLayout的weight属性来进行权重设置,进而达到按比例显示布局的意图通常我们在使用时,会这样使用android:layout_width"match_parent"android:layout_height"match_parent&qu…

实时计算pv/uv Demo

简介: 本文由阿里巴巴高级技术专家邓小勇(静行)分享,主要用 Demo 演示如何通过实时计算 Flink 实时计算pv/uv的场景。 本文由阿里巴巴高级技术专家邓小勇(静行)分享,主要用 Demo 演示如何通过实…

《天际友盟DRP数字风险防护报告(2021年上半年)》重磅发布

今天,数字化正在发生,整个社会正在步入数字化革新。根据市场研究公司IDC的预测,到2023年超过50%的全球经济将由数字经济所驱动。在中国,2021-2024数字化转型总支出将达到1.5万亿美元,年均增长率超过17%。由此可见&…

Android Native crash 处理案例分享

简介: Android Native crash 处理案例分享 1. 背景 目前 mPaas[1] Android使用Crash SDK对闪退进行的处理,CrashSDK 是 Android 平台上一款功能强大的崩溃日志收集 SDK,有着极高的崩溃收集率和完整、全面的崩溃日志信息,生成的日…

Mendix:低代码与无代码的异同点与用例

投稿 | Mendix 编辑 | 宋 慧 头图 | 付费下载于 IC photo 低代码和无代码应用开发都遵循着代码抽象化原则来实现建模的可视化。但基于这两种方法构建的应用在规模和类型却有着根本性的区别。 低代码与无代码的相同之处 低代码和无代码开发平台都无需编写代码就能构建软件应用…

解读:云原生下的可观察性发展方向

简介: 非常有幸参加了云原生社区Meetup北京站,有机会和众多业内的大牛一起讨论云原生相关的技术和应用,本次Meetup上我和大家分享了关于云原生下的可观察性相关的议题,本篇文章主要是视频的文字性总结,欢迎大家留言讨论…

一文读懂 Serverless,将配置化思想复用到平台系统中

简介: 搭建一个 aPaaS 平台是需要很长时间的,当然也可以基于一些公有云产品的 Serverless 方案实现现有系统的灵活性与扩展性,从而实现针对于不同客户的定制。 写在前面 在 SaaS 领域 Salesforce 是佼佼者,其 CRM 的概念已经扩展…

9.9 元福利价,解锁校园满分计划

移动云开发者社区致力于为广大开发者提供技术交流和能力输出,是移动云开发者交流汇聚地、移动云产品首席体验官工作台、移动云技术能力布道者讲台和移动云能力输出窗口。通过移动云开发者社区,在帮助移动云开发者用好云、好用云的同时,还可以…

亲历者说 | 完整记录一年多考拉海购的云原生之路

简介: 考拉海购的整个云化改造是从 2019 年 10 月份开始的,当时的唯一目标就是短时间内快速完成迁移。在不到 4 个月的时间里,考拉团队唯一考虑的是如何以最快的速度完成使命,云原生是我们选择的最合适的一条路。 前言 考拉海购的…

为了一个HTTPS,浏览器操碎了心···

作者:轩辕之风O来源:编程技术宇宙 浏览器我是一个浏览器,每到夜深人静的时候,主人就打开我开始学习。为了不让别人看到浏览记录,主人选择了“无痕模式”。但网络中总是有很多坏人,他们通过抓包截获我和服务…

深度 | 阿里云蒋江伟:什么是真正的云原生?

简介: 而今,云原生成了耳熟能详的热门词,似乎不提云原生就落伍了,加入 CNCF 也成了云厂商引以为傲的技术优势。 我们也看到各种云原生的定义,有来自 CNCF 的“微服务容器持续交付DevOps”,也有来自不同云厂…

媒体智能-淘宝直播流媒体互动实践 | D2 分享视频+文章

背景:今天给大家带来的分享主题是《媒体智能-淘宝直播流媒体互动实践》,内容分为5个部分,首先看看在淘宝直播的直播间里主播可以怎样给用户拜年;然后具体讲如何制作一个手势拜年的特效;接着介绍我们媒体智能整体的方案…

从云网络时延看应用部署架构

简介: 介绍云网络时延的构成,并对其进行量化的分析,以及从云网络时延看不同应用对应的部署架构。 也简单的分析了5G时代对应用部署架构的影响和度量云网络时延的产品和工具。 在引出云网络时延这看起来比较专业的话题前,先看几个比…

mPaas 研发流程和线上运维介绍

简介: mPaas 研发流程和线上运维介绍 1. 背景 金融级移动开发平台 mPaaS[1](Mobile PaaS)为 App 开发、测试、运营及运维提供云到端的一站式解决方案,能有效降低技术门槛、减少研发成本、提升开发效率,协助企业快速搭…