高品质的音视频能力是怎样的? | Qcon 全球软件开发大会·上海站邀请函 了解详情
写点什么

携程云原生基础设施演进之路

  • 2020-02-19
  • 本文字数:3467 字

    阅读完需:约 11 分钟

携程云原生基础设施演进之路

随着虚拟化技术和云计算技术的普及,IT 互联网基础设施发生了很大的变化,计算、存储、网络等底层架构也越来越复杂。本文主要介绍携程云平台团队在追求云原生的道路上不断演进携程云基础设施的历程,包括架构选型的思路和踩坑经验的总结。


一、Generation1.0:OpenStack & IAAS 平台建设

携程云 1.0 时代,云平台团队基于 OpenStack 构建 IAAS 平台,旨在提升资源交付效率、统一资源交付标准。虚拟化网络方案基于 OpenStack Neutron 及 Openvswitch 技术实现,网络架构是传统的大三层架构。网络架构如下图:



图 1 传统大三层网络架构示意图


经过对 OpenStack nova 调度器的优化、KVM/Vmware 镜像自动下发,虚拟机的交付时长稳定在 2 分钟至 5 分钟左右。但由于虚拟机和物理机镜像的管理成本较高,IAAS 平台仅负责交付标准的预装 OS(如 Ubuntu1604/CentOS71/CentOS76/Windows2012 等),在 postinstall 过程中安装 Provision 系统的 agent(比如 SaltStack Minion),代码运行环境的标准化是由 Provision 系统来实施。再加上 CMDB、负载均衡系统、自动发布系统等对接的步骤,从用户申请虚拟机到可以提供线上服务,预期时间在 20 分钟到 30 分钟之间。


二、Generation2.0:容器化推进 & Mesos 平台建设

2015 年底开始,云平台开始进行容器化的尝试。由于前几年在 OpenStack 平台积累了很多经验,团队在第一时间选择用 novadocker 组建来进行容器化落地。


容器的网络方案与 Generation1.0 时代的虚拟机网络模型保持一致,继续使用 Neutron+Openvswitch 来落地,这样节省了很多网络选型和测试的时间。


Novadocker 的调度模式与虚拟机类似,第一次实例创建后即落地在固定的宿主机上,因此内部又将 novadocker 创建出的容器定义为“胖容器”。胖容器接入了部分生产业务并稳定运行之后,大家觉得在稳定性方面容器和 VM 并没有太大差异,很快我们启动容器调度平台的选型,让容器实例“动”起来。


2016 年初,在调研了 Docker Swarm、Mesos、Kubernetes 之后,团队普遍认为 Mesos 最为成熟,于是着手开始进行 Mesos 在携程的落地,大家分工进行各技术栈容器镜像规范制定、镜像打包平台建设、PAAS 平台与 Mesos 平台对接、下一代网络方案调研及落地。


在验证了大规模 Mesos 集群的稳定性之后,团队将之前运行在虚拟机上的 java 应用分批次迁移到 Mesos 集群。至此,团队的工作重心从资源交付转向应用交付,研发新申请容器实例到投产平均仅需 30 秒的时间。


在 Generation2.0 的时期,大家逐步认识到容器化带来的实际优势,不可变基础设施的理念不仅帮助了运维团队减轻工作,也为研发团队提升了交付效率,各业务积极配合容器化改造,JAVA 应用容器化覆盖率在很短的时间内超过 90%。


三、Generation2.5:Ctrip Paas + Kubernetes 平台化

在基于 Mesos 平台快速完成 JAVA 应用容器化之后,我们也挖掘出了更多的需求:Python/Nodejs/golang 等多语言技术栈需要进行容器化改造;调度系统的需求越来越复杂(应用分散策略,CPU 绑定,网络 Qos,指定 CPU 指令集的调度);部分应用有强烈的自动扩容缩容的需求等。越来越多的应用侧需求需要下沉到基础设施层(在当前阶段是容器编排调度平台)来实现。


在连续几个月进行 Mesos 调度器的二次开发工作之后,我们发现 Kubernetes 社区也越来越活跃,Kubernetes 很快演进成了一套 Production Ready 的容器调度平台。在评估了工作成本和风险之后,团队在 2018 年初启动了 Mesos 至 Kubernetes 的迁移。同时,Ctrip PAAS 平台已借助 Kubernetes 的底层能力,为研发提供了更丰富的服务。



图 2 Ctrip DataCenter OS & Kubernetes 整合



图 3 Ctrip 研发服务平台


在 Generation2.5 时代,我们完成了数千个 Node 规模的 Kubernetes 集群建设,接入了携程超过 1 万个线上应用,覆盖了 Java/Nodejs/Python/golang 等主流技术栈。期间团队在 DockerDaemon 稳定性、内核方面踩坑多次,投入很多精力进行了相关问题的排查和解决,确保平台上业务的持续、高效、稳定运行。在集群规模大了之后,底层网络的问题陆续多了起来,大集群的快速扩容、高频次的 HPA,现有 Neutron 集中式 IPAM 分配管理机制已经成为了瓶颈。



图 4 Generation2.5 Neutron 组件监控看板


我们发现部分应用也仅仅是完成了容器化,即部署模式从物理机或虚拟机换成了 Docker 容器(Cloud Hosting 任务达成)。而 Kubernetes 基础设施平台化能够带来的好处还包括:中心化的资源编排可以最大限度的减少资源浪费(前提是 Kubernetes 覆盖足够大);强大的管控能力让各领域专家的精力可以集中在领域本身,运维、部署、容灾、分布式、资源分配等繁琐工作由 Kubernetes 来统一解决;Kubernetes 社区的活跃度也可以让业界一流的架构和技术快速在自己的组织中落地。这几大好处促使我们不满足于 Cloud Hosting,掀开了下一阶段工作重心:Cloud Native basedon Kubernetes 的序幕。


四、Generation3.0:Cloud Native & Kubernetes

1991 年 9 月 Linux0.0.1 版本的发布震动了整个开源界,Linux 自由与分享的哲学在开源界传承至今。2015 年,Google 发布了 Kubernetes 1.0 版本,Kubernetes 在 2017 年开始成为了容器编排系统的事实标准。在携程云平台基础设施从 2013 年至今不断演进的过程中,我们愈发认同 Jim Zemlin 的观点:‘Kubernetes is becoming the Linux of the cloud’。我们团队目前致力于打造 Cloud Native 基础设施,追求更高资源利用率、更快部署速度、更强应用治理能力。


4.1 关于更高资源利用率


图 5 Kubernetes 统一控制平面


目前携程已经接入 Kubernetes 的应用类型包括:在线应用、ElasticSearch 集群、Redis 集群、Spark 离线计算 job 集群、AI 协作平台等,其中在线应用集群具有显著的波峰和波谷,可以利用混部将波谷资源释放给 CPU 密集型的离线计算 Job,可以显著提升集群资源利用率。如下图:



图 6 混步后的资源利用率提升


集中式的 Kubernetes 集群监控工具可以快速识别各种潜在异常:



图 7 携程云管平台 Kubernetes 集群体检中心


4.2 关于更快的部署速度

在提升 Provision 速度方面,团队主要围绕两个方面进行优化工作:一是打造容器镜像管理平台,快速构建新镜像,按需分发至多地数据中心,基础镜像提前下发预热,宿主机镜像多数据中心就近下载。二是进行新一代容器网络架构调整,解决集中式 IPAM 的瓶颈,提供更加”云原生”的网络解决方案。


Cilium on Kubernetes 的网络架构基于 ebpf 技术、容器间通信的链路更短;Node 级别的 IPAM 与 Neutron 相比更高效,也降低了全局性网络故障的潜在风险。


Cilium 是 Kubernetes Native 的一套高性能、高动态的网络解决方案,可以原生支持私有云和公有云,同时可以适配 OpenStack、为后续管理 VM 和物理机管理提供了备选方案。Application 层面,Cilium 原生支持所有 Kubernetes 的资源,可以在应用无感知的情况下对网络进行透明的拦截(ebpf 技术),对混沌工程的支持非常方便。



图 8 Cilium on Kubernetes


4.3 关于更强的应用治理能力

Infrastructre as Code 实践:



图 9 Infra as Code 实践


Kubernetes 平台为 Infrastructure as Code 实践提供了绝佳的平台,我们基础设施的各类管理服务都在使用 IAC 的方式进行部署和统一管理,在提升稳定性和运维效率的同时享受云原生带来的社区红利。


基于 Cilium,我们同时进行 Network Control as Code 实践,为混沌工程中的网络故障模拟场景提供了便捷落地的可能;同时,基于内核和 ebpf 我们可以从底层进行网络排障工具研发,从底层定位各类网络侧疑难杂症的根因。




图 10 & 图 11:Network Control as Code 实践


五、写在最后

在线应用的底层基础设施变更有一定风险,需要投入较多人力进行迁移方案设计,“给高速飞行中的飞机换零件”挑战在于:运行中的系统给迁移方案带来了诸多先天限制,原则上只允许成功,不允许失败。


现在云计算的发展日新月异,不断有新的技术和架构出现,各领风骚三五年,要求架构师们具备一定的技术前瞻性和敏锐的嗅觉,同时在设计架构时需要考虑底层变更的成本。Cloud Native 架构的开放性和包容性及其对于更高的资源利用率、更快的部署速度、更强的管控能力的不断追求,让我们相信这是值得持续投入的正确道路。


作者介绍


周昕毅,携程系统研发部云平台高级研发经理。目前负责携程 K8S 平台运维管理、分布式存储和云平台网络组件研发及运维管理。熟悉云基础设施建设,从事运维自动化及 DevOps 工具研发工作十年以上。长期关注云原生技术领域,Infrastructure AS Code 理念的坚定践行者。


本文转载自公众号携程技术(ID:ctriptech)。


原文链接


https://mp.weixin.qq.com/s/quJVriicGMmXvZZmWViKzg


2020-02-19 20:30642

评论

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

开源一夏│别逗,作为程序员你竟还没参与过开源项目?

极客飞兔

开源 经验分享 签约计划第三季 8月月更

从TRPO到PPO(理论分析与数学证明)

行者AI

深圳堡垒机厂家有哪些?重点推荐哪家?

行云管家

网络安全 堡垒机 深圳 运维审计

爆了!1213页LeetCode算法刷题神册(全彩),GitHub万星仅是开始

JAVA活菩萨

Java 程序员面试 大厂技能 秋招 大厂面经

架构师学习心得总结

泋清

#架构实战营

国际计费系统基于Sharding-Proxy大数据迁移方案实践

京东科技开发者

数据库 系统 数据迁移

腾讯SpringBoot高阶笔记,限时开源48小时

冉然学Java

编程 springboot 笔记 java 日志 #开源

Rust 入门指南(使用JSON)

王泰

rust

兆骑科创创业大赛竞赛平台,双创服务,投融资对接

兆骑科创凤阁

宁夏等保测评机构有哪些?如何选择?

行云管家

等保 堡垒机 等级保护 等保测评 宁夏

结合实际聊聊电平转换电路(常用电平转换电路总结)

矜辰所致

电路设计 8月月更 电平转换电路

《数字经济全景白皮书》银行业智能营销应用专题分析 发布

易观分析

金融 银行 白皮书 智能营销

leetcode 20. Valid Parentheses 有效的括号(中等)

okokabcd

LeetCode 数据结构与算法 栈和队列

面向推荐的汽车知识图谱构建

之家技术

人工智能 机器学习 知识图谱 汽车

【大厂面试真题解析】蔚来数字化业务后端一面(2022.8.6)

面试官问

后端 面试题 大厂面试 面经分享 蔚来

不得不服!真心被这份阿里大牛开源的“全彩版图解HTTP手册”折服了

JAVA活菩萨

Java 程序员面试 大厂技能 秋招 大厂面经

数据建模已死,真的吗?

Kyligence

数据建模 数据模型 数据指标

SpringMVC(二、请求和响应)

开源 springmvc 8月月更

关于使用WebStorm两年所总结的一些常用插件和功能

安权

前端 webstorm

双Q合璧:RabbitMQ与RocketMQ,电子版手绘脑图+学习指南+面试等

冉然学Java

RocketMQ RabbitMQ 架构设计 笔记 java 日志

Java完全自学手册,从外包到大厂,再到年薪100万技术大佬都靠它

JAVA活菩萨

Java 程序员面试 大厂技能 秋招 大厂面经

dubbo 长连接

石臻臻的杂货铺

dubbo 8月月更

携程云原生基础设施演进之路_文化 & 方法_周昕毅_InfoQ精选文章