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 能完美解决这些问题，那它离承载一切的目标或许就不远了。
以上是我今天的演讲，谢谢大家！