携程：我们是如何利用容器实现快速弹性伸缩的？

《携程：我们是如何利用容器实现快速弹性伸缩的？》要点：
本文介绍了携程：我们是如何利用容器实现快速弹性伸缩的？，希望对您有用。如果有疑问，可以联系我们。

一、在线旅游与弹性需求

近年来随着大众旅游消费的火热,携程的业务每年呈高速增长,2016年Q4财报显示携程2016年全年营业收入同比增长76%,交通票务营业收入同比增长98%,酒店预订营业收入同比增长56%,其他BU也有大幅增长,预计2018年携程的 GMV 将突破10000亿,并在2021年突破2万亿.

我们开发的私有云和持续交付平台为携程超过 20 个 BU/SBU 服务,为了同步支撑业务的高速发展,我们也需要不断的技术革新,持续提升携程运营、研发的效率,缩短产品从 idea 到交付用户的时间.

旅游出行的特点是季节性的,在平时流量都比较低,但节假日前一天流量会突然增高很多.因此每到节假日就会面临成「倍」增长的扩容需求.图 1?中可以明显的看到流量的起伏情况.

图 1

一般情况,临时扩容的需求较多,缩容会比较少,因为流量一上去之后,在短时间内不会下来,另外一方面,哪怕是流量下来了,由于以往资源申请没那么灵活,一般都会占用资源不释放,只能通过一些运维手段来监测资源使用情况然后告知业务部门去主动缩容.

携程目前大部分还是虚拟机,我们想缩短提前扩容的时间,以目前的虚拟机扩容方式,单个虚拟机扩容(从分配资源、调度、网络、os基础环境、应用部署等)至少是十分钟级别的.

如果是每次扩容上千台的话,确实需要一定的时间,而且还得看看有无足够的资源,比如 1 月 1 日的流量提前一周就扩容好,但这不够灵活,业务流量下来以后需要缩容,目前的速度还是不够快.

针对这一场景,我们需要解决的问题是,能有更快的方案吗?如何能够做到更快速的弹性伸缩满足业务的需求?答案是利用容器.

图2

再举个例子,携程有个深度学习的小诗机项目,将训练好的模型,对外提供服务,用户只要上传照片,后台的?AI?机器人就会根据照片中的内容自动写诗,这对于现行都市词穷一族来说,瞬间提升了意境,蛮有意思的.

该项目希望在春节前上线,需要紧急扩容?1000?核,以满足春节期间大流量的需求,春节过后立马就可以缩容?90%?的资源.

目前我们通过容器可以做到?1000?核的资源,5?分钟内完成?150?个容器实例的扩容,而且这还是?API?同步创建的速度,我们正在优化成异步的方式,相信后续提高并发能力后,速度还可以得到大大的提升.

其实携程的容器化已经进行一年多了,容器给我们最大的感觉是看起来简单,但要做好很难,原理不是很复杂,但是要利用这个技术做出一个产品或服务,中间有非常多的细节需要完善,比如如何做到用户体验更好的?UI?可视化、如何做到灰度发布、容器监控、容器基础镜像版本管理等等.

二、携程容器云定位

携程容器云定位有以下?4?点：

1、打造极致的秒级持续交付体验,服务20+BU

秒级意味着所有的扩容、缩容、回滚全部是秒级的,做到秒级是很难的,有很多需要突破的地方.比如,高速的镜像下发系统；高效的调度系统,稳定的容器服务,高度自动化的网络服务.

2、提升资源利用率

为了提高服务器资源利用率,我们采取账单的形式,督促业务线提高资源利用率,优化代码架构.我们对采集到的实时监控数据进行统计分析,按照?CPU、内存、存储、网络等多个纬度,按月计费,每个月会将账单发给业务线的?CTO.

3、组件服务化(mysql/kv/mq/…)or PaaS?化

应用所需要依赖的很多组件能够变成服务化,AWS 或者阿里云也做了很多这种服务.携程内部也在尝试把一些公共组件服务化,例如,MySQL,Redis,RabbitMQ?等.

拿?MySQL?为例,我们让用户可以在测试环境快速部署?MySQL?实例,并且可以选择性的将测试数据灌入.新建的?MySQL?实例也会自动在数据访问中间件中完成注册,方便开发人员、测试人员快速搭建测试环境和测试数据.

4、从自动化到一定程度智能化

从自动化到一定程度智能化指的是基础设施变得更智能,比如能够具备一定的自我修复能力,如果是从上游到下游的一整套服务都具备智能化修复能力的话,这是一个非常大的突破,对于提升运营效率和故障恢复速度至关重要；

三、容器部署基本原则

• 单容器单应用
• 单容器单?IP,可路由的 IP
• 容器镜像发布
• immutable infrastructure
• 容器内部只运行 App,所有 agent 部署在host 层面-包括监控/ES/salt等agent

以上是携程容器部署基本原则,看起来很容易,却是我们很长时间实践经验的总结.

比如单容器单应用这个原则,历史原因我们有混合部署的情况,单个vm部署多个应用,运维的复杂度会上升很多,比如：应用之间如何做到更好的资源隔离?发布如何避免相互之间的冲突?等等.

使得我们的运维工具、发布工具变得格外复杂,开发、测试的持续交付效率也受到极大影响；

容器镜像发布也是我们做的一个比较大的突破,过去是代码编译成可发布的包,直接部署到 vm 内部,而现在是编译时直接生成容器的镜像,不同环境其实部署的是同一个镜像.

并且不允许部署之后单独登陆进行配置修改,通过这种方式做到?immutable infrastructure,保证开发、测试、生产环境的一致性,同时也保障了自动化扩容、缩容快速高效的进行.

是否在容器内部也运行各种运维 agent 也是我们经过实践确定下来的；我们希望容器尽量简单,尽可能只包含运行的应用本身,此外将所有的 agent 合并到 host 层面,也能在很大程度上提升服务器资源利用率,agent数量下降一到两个数量级；但配套的管理工具(eg: salt) 需要做一次升级改造才能适配新的模式；

四、容器编排选型&取舍

1、OpenStack

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!