计算资源利用率提高38%，厦航的容器化电商中台构建实践

2019年6月20日，由Rancher Labs（如下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 如下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近1000名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。

来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人，在大会上带来了关于企业容器项目实践经验的精彩分享。

厦门航空和Rancher的合做能够追溯到2年前。2017年，厦门航空完成了厦航云计算平台项目建设，基于Rancher、IaaS和CMP搭建了三位一体的厦门航空云计算平台。

“航空行业电商的发展催生了大量的业务请求访问，平台须要作到具有极强的稳定性和自动弹性收缩能力，而原有的传统开发模式和软件开发模式早已没法知足现有的需求。” 厦门航空信息部系统工程师、云平台负责人周钊分享道：“在这样的情形下，咱们找到了Rancher，经过自主研发及微服务架构与Rancher容器平台完美结合，共同打造出厦航电商战略的支持平台。”

如下是厦门航空信息部系统工程师、云平台负责人周钊的演讲实录：

你们好，我是厦门航空信息部系统工程师周钊，今天和你们分享的主题是厦门航空基于微服务的电商中台构建实践。

厦门航空是一家主基地在厦门的国内中型航空公司。

在今天的演讲中，我将和你们分享厦航的云计算平台。在2014年末，厦航云计算平台项目总体上线试运行，平台包括三个部分。首先是你们熟悉的CMP混合云管理平台，而后是基于Open Stack架构的IaaS云计算平台，最后则是咱们今天的主角，Rancher容器云平台。

1. Rancher 1.6 + ELK

咱们最初上线的时候，Rancher的版本是1.6，咱们第一个容器化的应用是ELK，当时ELK运行在这个项目的另一部分、也就是OpenStack的IaaS平台上，使用RBD存储实现了整个ELK的数据持久化。咱们的ELK不只仅用在日志分析等方面，咱们还把ES在一些查询搜索等业务上作了普遍的推广。

目前，咱们的ELK在Rancher的K8S平台上进行迁移，也就是说咱们在Rancher和K8S上吃的第一个螃蟹仍是ELK。

上图是当初ELK在1.6上的架构图，和社区最佳实践比较相似，在这里就不详细赘述了。

2. 容器化的电商中台

这一部分是咱们的重点——厦门航空的容器化的电商中台。

电商中台和厦航的电商战略是息息相关的。它做为支撑平台，能够实现以机票销售为中心，把不一样类型的乘客以不一样形式的旅程，包括不一样内容的附加服务，打包在一块儿进行全流程服务，提高咱们整个航空公司的业务水平。

目前，厦航电商中台对接了公司全部直销渠道、线上OTA渠道，也就是说假如你如今拿起手机或者经过电脑，在官方渠道或其余任何购票渠道上查询厦航的机票、购买厦航的机票，都会通过咱们的电商中台。

上图是厦航电商中台的架构图。在这个图里面，除了红色部分的Redis、消息队列以及最下面的公共硬件LB设备，其余组件都运行在Rancher 1.6平台上。

上面这张是厦航电商中台生产环境的截图，包含咱们厦航电商中台的全部服务。

这是在整个电商中台第一次迎接比较大的考验，对接阿里飞猪，当时我在Prometheus上截的图，留做记念。里面有一个处理到的数据，你们能够看一下。

这张是前两天准备PPT的时候截的图，能够侧面看到咱们的业务增加量。

讲完厦航电商中台的成果，我想藉这个机会再次感谢Rancher工程师对厦航电商中台以及容器云平台的大力支持。

3. 电商中台上线之路

接下来，咱们来回顾厦门电商中台在容器化过程当中，以及在测试上线过程当中积累的一些经验和体会。Rancher带给咱们的提高首当其冲的就是DevOps更新迭代的速度。

咱们在整个开发测试环境里实现了全流程的CI/CD流水线，整个电商中台如今有单独一套Harbor镜像仓库。

我在准备PPT的时候简单统计了一下，近期每周镜像的增加速度超过15G，这个数据是最低表现，有时每一周可能会有超过30G的镜像增加量。单个服务在上线半年内有超过100屡次的功能更新，当中还不包括BUG的修复。

第二方面，我曾专门统计过容器在基础资源的利用率。若是对比咱们整个电商中台，若是用虚拟机作部署，Rancher节省的计算资源比例超过38%，这个和大会上午一位嘉宾分享的40%的数据是比较接近的。

第三方面，众所周知，容器在灵活扩展和横向扩展方面速度提高很是大。

最后一方面，厦航的团队在基于Rancher API的基础上开发了Publish-helper的工具，在Rancher 1.6平台上实现接近无感知，也就是K8S这边的灰度发布的应用更新。这个工具支撑了厦航基本上全部生产环境的版本更新。

下面和你们分享咱们踩过的一些坑。刚才咱们讲到了容器化的一些好处，可是除此以外咱们也不是没有踩过坑，主要是网络、存储和关键应用组件这三类。

首先是网络，咱们一开始基础平台相对而言资源并非十分充裕。在最开始的时候，咱们用的是千兆网络，在整个平台里面，咱们发现不少容器化的应用集群并不能顺利的初始化。

在排故过程当中，咱们存在大比例的网络丢包。后来咱们分析，老旧的设备包括网卡等支持网络多会话的特性较差。后来咱们就更新了总体设备，换到性能较好、特性较多的万兆网络。

可是咱们在系统上线前作了一次全链路的压测，又发现单个容器尤为是Rancher 1.6里LB的容器，它的单容器网络IO并不高。

上图是咱们内网拿到的数据，万兆网卡在VMWare环境下只有1.33G，在咱们的IaaS平台上只有1G每秒的存储。这个数据并不能达到咱们上线的需求。

通过和Rancher工程师几回的调优，咱们把这个数据提高到大约4G每秒的存储量，基本上和当时K8S Flannel的网络是相似的。

在存储方面，我想先和你们分享几个例子。

第一个例子是上线前的一个检查，咱们的Dockerfile是研发工程师写的，在生产上线以前咱们会检查，避免有一些不规范的地方。里面有一个Docker volume。一开始检查的时候，咱们只检查Docker compose和Rancher compose文件，看里面有没有定义Docker volume。咱们后来发现有的研发人员在Dockerfile里写了Docker volume的指令，配合早期版本的Docker，它有一个特性，Volume的生命周期和Container是一致的。这就形成若是Container消失，Volume数据也会丢失。针对这些问题，咱们后来就增长了一些检查。在咱们内部交接的时候，上线以前不只检查Docker compose，还要检查Dockerfile。

还有一个是我这边的问题。在管理Rancher volume的时候，我把非active状态的Rancher volume都删掉了，应用就有人迅速反映说他的数据丢掉了。还好当时是测试环境。后来我在还原故障现场的时候，发现是Rancher里面的一个特性，Container在重建的时候，Volume会有一个Detached的状态。我删掉的卷正好是Detached的状态，其实active状态的卷是没法删除的，Detached的状态就能够删除了。咱们后面总结了一下，在管理Rancher Volume的时候，仅仅只关注红色的inactive状态的卷，其余的卷通常不作清理，除非有特殊需求。

还有就是比较关键的、须要数据持久化的组件，包括一开始咱们电商中台提到的Redis和消息队列。这些组件咱们在测试环境也是全容器化的，可是在生产上线的时候，考虑它的数据稳定性，还有这些组件对咱们平台的关键性做用，仍是把它放在虚机里面。可是咱们还一直进行数据持久化关键组件的测试。

在Redis和Oracle以前，咱们还作过Cassandra还有PG的容器化测试，如今咱们在测试环境中也一直有这两个组件运行。除此以外，咱们还作过一些比较极端的容器化测试，咱们将Oracle的12C作了单节点的容器化，也是跑的测试环境。

4. Rancher 2.x + 混合云 + 多活数据中心

咱们计划以Rancher为中心，实现混合云与多活数据中心的架构设计，这是咱们今年和Rancher合做的重点工做。

为何厦航要作混合云和多活数据中心呢？当厦航电商中台上线以后，整个电商中台的增加是很是迅速的。在咱们内部，我除了Rancher以外也负责技术平台，包括服务器虚拟化等内容。而后我发现，只要我服务器到位，Rancher立刻就会产生需求，吃掉大部分资源。受限于咱们传统的管理模式，咱们的数据中心基本上很难知足快速的扩容需求。

厦航电商中台由于业务增加比较快，对接的系统也比较多，它的查询和搜索压力是十分庞大的。还有后期在咱们电商中台的演进过程当中，它的架构也一直在变化。咱们须要更灵活的多种多样的服务选型来知足咱们不一样的业务场景需求，而这些问题偏偏是公有云最擅长的，因此咱们有了混合云的需求。

关于多活数据中心，厦航在五年前就进行了两地三中心的容灾设计。在2017年5月，咱们实现了公司最核心的内部系统航班运行控制系统的一键切换。随后，在2017年和2018年，咱们又把公司其余的核心系统，包括有三级评测的系统所有作了两地三中心的容灾建设。而如今，咱们要向多活数据中心演进。

咱们总结了两个原则，一是标准化，一是服务化。咱们认为，基于标准化和服务化云应用，不只仅是应用了上层能够对底层，并且是随处能够运行的，个人上层能够利用任何一个底层，底层对于上层而言，又是透明的。

这个架构演进是比较清晰的，如今只有基础设施层的标准化和服务化，也就是咱们说的IaaS，逐渐向上层演进，把咱们的数据层和咱们的中间件层也作成标准化和服务化的架构。最终走向全面的微服务架构演进。

这是我我的的一个观点，K8S能够承载一切。同时，咱们也开始关注K8S的生态，基于Rancher 1.6的经验，咱们在K8S生态里关注了Istio、Heptio、Calico等等组件。针对这些组件，咱们作了一些实践和研究。

这是发在咱们内网的技术分享，包括Calico的路由反射器，大规模的K8S集群维护，还有基于Heptio的备份和恢复。

我想重点说一下Calico，随着IT企业对容器化和微服务化的改革以及演进，如今已经进入到深水区。像Calico这种重量级的网络组件是很是有必要的。

随着变革的深刻，大规模的K8S集群愈来愈多，而Flannel是一个比较傻瓜化的网络组件，不能知足企业对于容器网络的需求。咱们很是须要一个企业级的容器网络插件。

针对Rancher 2.2几个统一的、标准化的特性，一个是K8S标准容器编排，以及Rancher 2.2对公有云的基础设施服务，公有云托管K8S服务的统一管理，还有多集群的应用管理。

咱们想经过Rancher 2.2的这些特性，在厦航的混合云和多活数据中内心面造成一个桥梁和纽带，串联起咱们在每一个云和每一个数据中内心面的业务。

在Rancher2.2上线以前，我还带来了几个问题。首先是K8S集群的备份和持久卷的备份管理，还有K8S安全与安全域、多租户隔离等等这些安全问题。以及刚才提到的网络控制、网络隔离，最后一个是有状态的应用集群管理。

若是K8S能完美解决这些问题，那它离承载一切的目标或许就不远了。

以上是我今天的演讲，谢谢你们！