【ArchSummit】如何通过AIOps推动可量化的业务价值增长和效率提升?>>> 了解详情
写点什么

vivo 云原生容器探索和落地实践

  • 2022-12-19
    北京
  • 本文字数:6520 字

    阅读完需:约 21 分钟

vivo 云原生容器探索和落地实践

本文根据潘良彪老师在“2022 vivo 开发者大会"现场演讲内容整理而成。


2018 年起,vivo 以容器作为基础底座,打造了一站式云原生机器学习平台。向上支撑了算法中台,为算法工程师提供数据管理、模型训练、模型管理、模型部署等能力,为广告、推荐和搜索等业务赋能,成功为算法实现了降本、提效,让云原生和容器价值初露锋芒。基于机器学习平台的试点成果,经过算法场景的试点实践和价值分析,对内部战略做了升级。确定基于云原生理念去构建行业一流的容器生态,实现规模化的降本提效目标。


本文会详细介绍 vivo 在容器集群高可用建设中的具体实践,包括在容器集群高可用建设、容器集群自动化运维、容器平台架构升级、容器平台能力增强、容器生态打通等层面的打磨和建设。目前,vivo 容器产品能力矩阵逐渐趋于完善,并将围绕全面容器化、拥抱云原生和在离线混部三个方向继续发力。


云原生和容器,是当下比较火热的话题,其中 Kubernetes 更是成为容器编排领域的事实标准。


国内外各企业在内部落地云原生和容器的过程中,基于自己的业务场景和发展阶段,会遇到各种问题和挑战,本文是 vivo 在云原生容器领域的探索和落地实践,希望能对读者有一些借鉴和帮助。


一、容器技术和云原生理念


首先是容器技术和云原生理念的介绍。

1.1 容器技术简介



容器技术不是一个新技术,从 1979 年 unix 系统的 chroot 诞生到现在,历经 40 多年的发展,共经过了四个阶段,分别是:技术萌芽期、技术迸发期、商用探索期和商用拓展期


每个阶段,解决了不同的技术问题,分别是:环境隔离、软件分发和编排、商用服务形态、规模化和场景拓展。


相比于虚拟机,容器技术少了一层虚拟操作系统的损耗,因此它比虚拟机具有更好的性能表现。另外容器在系统资源、启动时间、集群规模、高可用策略等方面,也有非常明显的优势。


2020 年 CNCF 中国云原生调查报告显示,接受调查的中国企业,有 68% 已经在生产环境使用容器技术。


从行业发展看,不管是云厂商还是各大科技公司,都在基于容器技术构建自己的新一代基础架构,推动企业数字创新。容器技术已经得到广泛的认可和普及。

1.2 云原生理念介绍



容器技术催生了云原生思潮,云原生生态推动了容器技术的发展。那么云原生的准确定义和含义是什么呢?


云原生其实没有标准定义,如果非要给他一个定义,行业有两种观点:


一个定义来自 Pivotal 这家公司,它是云原生应用的提出者,是云原生的先驱者、探路者。Pivotal 最新的官网对云原生的介绍有四个要点,分别是:DevOps、持续交付、微服务和容器


另外一个定义来自 CNCF,CNCF 建立于 2015 年,它是一个开源组织,其存在的目的,是支持开源社区开发关键的云原生组件,包括 Kubernetes、Prometheus 监控等。


它把云原生分为 3 种核心技术2 个核心理念

  • 3 种核心技术:分别是容器、微服务、服务网格。

  • 2 个核心理念:分别指不可变基础设施和声明式 API。


但是,不管是那一种定义,容器都是其基础,是云原生落地的核心技术手段。

1.3 云原生价值分析



任何技术和理念,都必须有实际的业务价值。从效率、成本、质量三个维度,来分析云原生和容器的技术价值,可总结如下:

  • 效率:可实现持续交付部署快、镜像封装可移植、弹性计算秒扩容。

  • 成本:可实现按需分配不浪费、统一调度高填充、混合部署少碎片。

  • 质量:可实现运行状态可观测、故障发生可自愈、集群管理可运维。


二、vivo 容器技术探索与实践


新技术的引入带来新的价值,也必然会引入新的问题,接下来介绍 vivo 在容器技术上的探索和实践。


2.1 试点探索



在 vivo 的算法场景中,机器学习平台负责算法模型迭代,是互联网算法业务中核心的一环,早期的平台基于传统的架构,在效率、成本、性能和体验上均有一定的不足,无法满足算法业务快速增长的诉求。基于此,我们首先在算法场景进行容器的试点探索。从 2018 年开始,我们以容器作为基础底座,打造了 vivo 的一站式云原生机器学习平台,向上支撑了公司的算法中台,为算法工程师提供数据管理、模型训练、模型管理、模型部署等能力,为广告、推荐和搜索等业务赋能。


vivo 的云原生机器学习平台具备如下 5 大优势:

  • 场景全:业务端到端,覆盖推荐、广告、搜索多场景。

  • 体验好:排队时间短,用户体验优,任务 P99 排队时长小于 45 分钟。

  • 成本低:调度能力好,资源利用率高,CPU 利用率均值大于 45%。

  • 效率高:网络规模大,训练跑得快,训练速度 8.3 亿样本每小时。

  • 结果优:算法迭代稳定,训练成功率高,训练成功率大于 95%。


vivo 云原生机器学习平台,成功为算法实现了降本、提效,让云原生和容器价值初露锋芒。


2.2 价值挖掘



基于前面机器学习平台的试点成果,我们深入分析和挖掘容器和云原生的价值,结合 vivo 的情况,我们发现容器和云原生是企业大规模降本和提效的最佳方案。


1)在降本方面


当前我们内部服务器资源的利用率较低,以 CPU 利用率为例,当前 vivo 服务器整体利用率均值在 25% 左右,相比行业一流水平的 40%~50%,还有不少的提升空间。容器在资源隔离、统一调度和在离线混部等方面的优势,均是提升资源 ROI 的有效技术手段。


2)在提效方面


当前我们在中间件版本升级、机器迁移、测试环境管理、突发流量应对和全球化部署的环境一致性等方面均有业务痛点。容器的快速交付、弹性自运维、微服务、服务网格等云原生技术和架构,则是提效的有力措施。


2.3 战略升级



经过算法场景的试点实践和价值分析,我们对内部战略做了升级, 确定基于云原生理念去构建行业一流的容器生态,实现规模化的降本提效目标。


为了更好匹配战略落地,拥抱云原生,我们还对内部技术架构重新规划和升级,新增引入统一流量接入平台、容器运维管理平台、统一名字服务、容器监控等平台和能力,支撑容器生态在公司内部的全面建设和推广。

2.4 面临挑战

2.4.1 集群挑战


要提供大规模的生产可用的容器服务,容器集群的可用性首先会面临诸多挑战。下面介绍 vivo 容器化,在生产集群建设过程中遇到的 4 个比较大的挑战。


  • 集群规模快速增长:vivo 集群服务器规模上万个宿主机节点,管理的集群数十个,单集群规模 2 千 +,实例数 10 万 +,对集群性能和机器管理挑战极大。

  • 集群运维、运营和标准化:由于早期集群管理不规范,黑屏化操作和人为误操作等问题层出不穷,集群运维人员每天因为各种救火忙得焦头烂额。

  • 集群容器监控架构和可观测性:随着集群规模快速增长,容器的监控组件面临极大压力,对容器监控的采集、存储和展示,提出更高的要求。

  • 线上 K8s 版本升级迭代:面对 Kubernetes 版本的快速迭代,需要实现给飞行的飞机换引擎。


针对挑战,我们的应对方案分别是:高可用、可观测、标准化和自动化。其中容器监控和 k8s 版本无损升级的挑战,vivo 公众号有详细技术方案的介绍,本文侧重介绍集群高可用和运维自动化两部分。

 2.4.2 平台挑战


除了集群稳定性的挑战,平台也将面临各种挑战,由于容器平台和周边生态能力不完善,对业务存在较高的适配和迁移成本。总结起来我们遇到的挑战主要有 4 点:

  • 容器 IP 的变化:k8s 早期把业务都设计成无状态的,其原生实现是每次发布容器的 IP 都会变化,这对部分依赖固定 IP 的传统业务不太友好,业务改造成本较高。

  • 周边生态的适配和兼容:包括发布系统、中间件微服务平台、内部开发框架和流量接入层等

  • 用户使用习惯:vivo 有比较成熟的发布平台,用户习惯按机房发布,习惯资源分配和发布分开操作。

  • 价值输出:运维研发效率的提升不好量化,容器成本优势短期不好衡量。


上面这些挑战,推动我们要进行容器周边生态打通,同时通过增强容器平台产品能力,来适配各种业务场景,降低用户的迁移成本。

2.5 最佳实践

 2.5.1 容器集群高可用建设


接下来,介绍 vivo 在容器集群高可用建设中的最佳实践,我们是从故障预防、故障发现和故障恢复,3 个维度来构建容器集群可用性保障体系的。



在故障预防上,我们分别从流程工具、容灾能力和基础架构 3 个方面来进行建设:

  • 流程工具:主要包含故障预案和故障演练,以及通过建设运维管理平台,来实现运维标准化、白屏化和自动化。

  • 容灾能力:主要是构建业务跨故障域容灾能力,保障集群故障时,服务和业务流量能跨集群调度和快速一键迁移等。

  • 基础架构:主要是通过屏蔽用户对底层集群的感知,一个机房多套集群,一个业务同时部署在多个集群上,避免单集群故障对业务造成影响。


在故障发现上,我们主要是通过,自建的监控大盘、日常集群巡检、核心组件监控、集群外拨测等措施,对故障及时发现和处理,降低对业务影响。


在故障恢复上,主要是基于前面的故障预案,快速恢复,及时止损,并做好故障的复盘,不断改进我们的故障预防和发现机制,沉淀宝贵经验。


另外,集群的可观测性是可用性保障的一个重要依据,我们通过建设自己的 SLO 面板,对集群状态实时地进行监控,只有对运营状况了如指掌,才能做到稳如泰山,沉着应对一切变化。

 2.5.2 容器集群自动化运维


除了容器集群自身稳定性建设,在运维自动化方面,我们建设了容器多集群管理平台,实现集群配置标准化,核心运维场景白屏化,来提升运维效率。



我们的容器集群管理平台,是以云原生的方式来管理云原生,简单来说,就是基于 K8s 的 operator 机制,实现 K8s on K8s。


当前,我们的平台已经能够实现多集群的统一纳管,集群部署也是自动化、标准化的,还实现了底层 IAAS 层打通,集群节点能全流程化、可视化的一键扩缩容,而集群巡检功能,可以帮助我们及时发现集群的问题和隐患。


通过平台进行日常运维和操作,不仅能提升效率,也具备审计能力,有操作和变更日志可追溯,便于问题定位。

 2.5.3 容器平台架构升级


为适应业务容器化在内部的快速普及和推广,我们升级了 vivo 的容器平台架构。



新的架构分为 4 层,容器 +k8s 则作为基础的统一底座,向下对接公司 IAAS 层的基础设施,向上提供容器产品和平台能力,并通过开放 API 供上层调用和定制自己的上层逻辑。


API 之上是容器支持的各种服务类型,包括在线服务、中间件服务、大数据计算、算法训练、实时计算等,最上面是为 vivo 互联网各个业务进行赋能。


基于这套容器平台架构,业务能实现资源隔离部署、快速交付和按需使用,同时也具备更好的弹性伸缩能力。对平台,我们可以统一资源的调度,实现资源的分时复用、在离线混部等,来提升资源的利用率。

2.5.4 容器平台能力增强


vivo 内部容器化场景比较多样化,为了让业务能够安心、低成本的接入和使用容器的能力,在推广过程中,我们基于开源 + 自研做了容器的适配和原生能力的增强。



下面对 6 个产品能力增强进行简单的分享:

  • 云原生工作负载增强:基于开源的 openkruise,对原生 deployment、statefulset 等 workload 进行了增强,实现诸如原地升级、发布暂停、流式和配置优先级等扩展能力。

  • 服务无损发布增强:基于内部框架和平台自主研发,实现 HTTP、RPC 等协议框架的流量无损发布。

  • 容器镜像安全:基于开源的 Harbor 定制开发,实现容器镜像安全扫描和卡控能力。

  • 容器镜像加速:基于开源 dragonfly2 定制扩展,让大规模集群镜像的分发性能提升 80% 以上。

  • IP 固定能力增强:基于有状态服务和 CNI 进行自研,支撑黑白名单、有状态服务场景诉求,降低业务接入改造成本。

  • 多集群管理能力增强:基于开源 Karmada 进行功能优化和扩展,提升业务容灾能力,支撑单集群横向扩展能力。


当然,在充分享受开源红利的同时,我们也持续地参与开源协同,回馈社区。在使用和自研的过程中,我们也把自己生产实践过程中发现的问题和积累的经验提交到社区,例如 Dragonfly2、Karmada 等。


2.5.5 容器 CICD 一体化


除了平台能力的增强,容器平台作为一个 PaaS 平台,需要和周边的生态打通,才能让业务更好的迁移和使用,其中最重要的就是发布系统的打通,也就是 CICD 平台。


几乎每个科技公司都会有自己的 CICD,它是一个 DevOps 自动化的工具,可进行业务构建和编排部署的流水线。



vivo 的 CICD 平台底层架构是基于 JenKins+Spinnaker 实现的,整个容器构建和部署流程如下:

  • 首先,用户在 CICD 平台上创建好发布过程的流水线配置并保存。

  • 其次,CI 环节可实现和内部 GitLab 对接,拉取代码,基于 jenkins 进行代码编译和镜像构建,构建好的镜像经过安全扫描后,推送到开发环境的镜像仓库。

  • 最后,在 CD 环节,CICD 平台会调用容器平台提供的 API,进行开发、测试、预发和生产环境的部署操作。


2.5.6 统一流量接入


接下来,介绍容器生态里,最重要的业务流量接入层的打通。



早期,vivo 内部是基于 Nginx,来实现的南北流量和东西流量的转发。在虚拟机和物理机场景能比较好的支撑,随着容器在内部全面的推广,传统的 Nginx 架构已不能适配。


主要体现在,容器场景业务实例数量,相比原来虚拟机和物理机成倍数增长,容器发布过程 IP 的频发变化和状态同步,都会对 Nginx 集群造成非常大的压力,在业务请求量非常大的情况下,接入层的配置文件刷新和加载,会造成业务的抖动,这是我们不能接受的。


基于这个背景,我们基于 APISIX 构建了云原生流量接入层,来适应全面容器化的需求。经过一年多的建设,当前我们的统一流量接入平台已经能够很好的支撑容器化的接入,同时具备更好的扩展能力。

2.6 实践成果

2.6.1 产品能力矩阵完善



经过多年的打磨和建设,vivo 容器产品能力矩阵趋于完善,整个产品能力矩阵,分为 4 层:

  • 基础服务层:包含 3 类服务,镜像管理、集群运维和集群监控。

  • 能力层:包含 6 个核心能力,分别是集群调度、CAAS-API、容器配置、容器业务监控告警、容器日志和平台扩展能力。

  • 平台层:包含 2 大平台能力,分别是 CI 和 CD。

  • 业务层:当前覆盖了 vivo 互联网所有业务场景。


 2.6.2 业务接入成果凸显


接下来,会具体介绍下 vivo 容器推广情况。



目前容器在 vivo 内部主要覆盖 4 大场景,分别是:互联网在线业务、算法在线、大数据计算和 AI 算法训练等。接下来,会从接入规模和价值来简单介绍。


  • 互联网在线服务:内部各个业务线均有大量服务运行在容器上,例如 vivo 商城、账号、浏览器、快应用、天气等,已经接入服务 600+。

  • 算法在线服务:当前接入 500+ 服务,3000+ 服务器,涉及推广搜的各个业务线。

  • 大数据计算服务:包含离线计算如 Spark,实时计算如 Flink、Olap 等场景,当前接入集群 20+。

  • AI 算法训练:主要是提供 GPU、CPU 异构计算,业务场景如 Tensorflow、mpi 等场景,算力十几万核,以及若干 GPU 卡。


业务容器化后,给业务在降本提效上带来的效果非常明显,包括但不限于扩缩容效率、弹性伸缩能力、业务自愈能力、资源成本等方面。

2.7 实践总结



基于我们的探索和实践,可总结为技术价值、推广策略、平台建设和云原生突破 4 个维度的思考。

  • 找价值:关注新技术,但不执着于技术本身,必须结合业务痛点和价值。

  • 定策略:自下而上小范围试点探索,产生实际的业务价值,影响自上而下的战略调整。

  • 建平台:当已经有比较完善的平台和能力时,要找到容器的切入点,进行融合共建,切忌推到重来;对于需要从 0 到 1 建设的新能力,需要果断的孵化创新。

  • 求突破:在业务容器化过程中,为了快速容器化,我们做了许多的兼容和适配。为了更好的降本提效,未来,我们希望引导用户,实现从使用云原生,到用好云原生的突破。


总的来说,技术服务于业务,企业应基于自身现状,寻找合适的解决方案,并为业务创造价值。


三、vivo 对云原生的未来展望

3.1 vivo 基础架构发展



从过去看未来发展,回顾过去 10 年历程,vivo 基础架构的发展经历了 3 个阶段:

  • 阶段一:传统研发运维阶段,从 2011 到 2018 年,从早期的 do 分离研发模式,到基于 openstack+kvm 的虚拟化方案落地。

  • 阶段二:应用架构互联网化阶段,从 2018 到 2020 年,容器化开始在 vivo 内部兴起。

  • 阶段三:云原生基础架构演进阶段,从 2021 年到现在,云原生和容器将会在 vivo 内部有更多场景的应用和推广,如在离线混部等。

3.2 vivo 云原生未来展望



回归事物本源思考,做正确的事,并把事情做正确。不盲从,有定力,基于价值,客观看待新技术发展,大胆假设、小心验证、实践出真知。vivo 云原生的未来,将会朝着 3 个方向发展,分别是全面容器化、拥抱云原生和在离线混部。


  • 我们的愿景是:一次开发到处运行,通过自动运维实现极致效率和成本最优!

  • 对开发人员:我们希望大家成为那只遨游海上的蓝色鲸鱼,驮着我们的业务应用,一次构建到处分发,灵活调度和运维。

  • 对管理者:我们希望追求效率的同时,能够实现成本最优。

2022-12-19 15:316985
用户头像
鲁冬雪 InfoQ 主编

发布了 336 篇内容, 共 192.9 次阅读, 收获喜欢 270 次。

关注

评论

发布
暂无评论
发现更多内容

智慧仓储管理系统,是否能解决购物狂欢节后新一轮爆仓危机?

一只数据鲸鱼

物联网 数据可视化 智慧物流 智慧仓储

从一个模糊词查询需求的处理方案讨论到一种极速匹配方案的实现

行如风

模糊匹配 双数组trie树 ahocorasick ac自动机 黑名单过滤

计算机网络简述

lee

计算机网络 网络协议 网络

从MongoID的生成讨论分布式唯一ID生成方案

行如风

雪花算法 分布式ID 全局唯一ID 流星算法

英特尔力邀150家产业大咖推动Evo严苛认证,打造PC界的奥斯卡

E科讯

重磅|中国PostgreSQL分会与腾讯云战略合作协议签订

PostgreSQLChina

数据库 postgresql 软件 开源社区

为什么要TDD(测试驱动开发)

sherlockq

敏捷开发 TDD 极限编程

anonymous匿名者场外交易系统APP软件开发

系统开发

快速接入 | 从 0 到 1 构建语音聊天室

拍乐云Pano

音视频 RTC 实时语音 语音聊天室 语聊房

如何基于 SDK 快速开发一款IoT App 控制智能灯(iOS 版)

IoT云工坊

ios App 物联网 IoT sdk

为什么说rollup比webpack更适合打包库

fengxianqi

大前端 Rollup webpack

未签订劳动合同的CTO | 法庭上的 CTO(17)

赵新龙

CTO 法庭上的CTO

人工智能不过尔尔,基于Python3深度学习库Keras/TensorFlow打造属于自己的聊天机器人(ChatRobot)

刘悦的技术博客

人工智能 tensorflow chatbot 聊天机器人 keras

云视频技术领军人赵加雨:如何提升在线教育课堂互动体验

拍乐云Pano

音视频 在线教育 RTC 互动课堂 白板

犯“走私罪”的CTO | 法庭上的CTO(19)

赵新龙

CTO 法庭上的CTO

像用户一样测试:打破知识的诅咒

QualityFocus

测试 软件质量 可用性 用户体验

重学JS | 数组遍历的7种方法及兼容性处理(polyfill)

梁龙先森

大前端 编程语言

生产环境全链路压测建设历程 21:某快递 A 股上市公司的生产压测案例之基于测试流量的混沌工程(故障演练)

数列科技杨德华

全链路压测 七日更

直播中不可缺少的一环-rtmp直播推流

anyRTC开发者

音视频 WebRTC CDN RTC RTMP

“盗窃”公司源代码被开除的CTO | 法庭上的CTO(20)

赵新龙

CTO 法庭上的CTO

什么是浮点数?

Kaito

计算机基础 浮点数

移动生态盘点与HMS生态解析

华章IT

华为 Android Studio 移动开发 HMS

盘点 2020 | 10 天开发前台系统技术系列

老魚

CSS 大前端 全栈 js 盘点2020

混合用工、被拖欠工资的 CTO | 法庭上的 CTO(16)

赵新龙

CTO 法庭上的CTO

股东变员工,所以不发工资?| 法庭上的CTO(18)

赵新龙

CTO 法庭上的CTO

深入浅出 ZooKeeper

vivo互联网技术

zookeeper 分布式 ZAB

星域母子币系统软件开发|星域母子币APP开发

系统开发

Spring 源码学习 11:invokeBeanFactoryPostProcessors

程序员小航

Java spring 源码 源码阅读

英特尔赵宏:从硬件创新到平台突破,PC的未来非常值得期待

E科讯

九环智能合约开发

V19927655815

APP开发

抢先体验全新升级版Eternal Wallet!

Geek_c610c0

数字货币 数字货币钱包开发

vivo 云原生容器探索和落地实践_服务革新_vivo互联网技术_InfoQ精选文章