2019年6月20日，由Rancher Labs（以下简称Rancher）主办的第三届企业容器创新大会（Enterprise Container Innovation Conference, 以下简称ECIC）在北京喜来登大酒店盛大举行。本届ECIC规模宏大，全天共设置了17场主题演讲，吸引了近1000名容器技术爱好者参加，超过10000名观众在线上直播平台观看了本次盛会。
来自Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco等十多家企业的技术负责人，在大会上带来了关于企业容器项目实践经验的精彩分享。
cdn.xitu.io/2019/7/10/16bd9b3df6e5921c?w=1920&h=1280&f=jpeg&s=336198">
厦门航空和Rancher的合作可以追溯到2年前。2017年，厦门航空完成了厦航云计算平台项目建设，基于Rancher、IaaS和CMP搭建了三位一体的厦门航空云计算平台。
“航空行业电商的发展催生了大量的业务请求访问，平台需要做到具备极强的稳定性和自动弹性收缩能力，而原有的传统开发模式和软件开发模式早已无法满足现有的需求。” 厦门航空信息部系统工程师、云平台负责人周钊分享道：“在这样的情形下，我们找到了Rancher，通过自主研发及微服务架构与Rancher容器平台完美结合，共同打造出厦航电商战略的支持平台。”
以下是厦门航空信息部系统工程师、云平台负责人周钊的演讲实录：
大家好，我是厦门航空信息部系统工程师周钊，今天和大家分享的主题是厦门航空基于微服务的电商中台构建实践。
厦门航空是一家主基地在厦门的国内中型航空公司。
在今天的演讲中，我将和大家分享厦航的云计算平台。在2014年底，厦航云计算平台项目整体上线试运行，平台包括三个部分。首先是大家熟悉的CMP混合云管理平台，然后是基于Open Stack架构的IaaS云计算平台，最后则是我们今天的主角，Rancher容器云平台。
我们最初上线的时候，Rancher的版本是1.6，我们第一个容器化的应用是ELK，当时ELK运行在这个项目的另外一部分、也就是OpenStack的IaaS平台上，使用RBD存储实现了整个ELK的数据持久化。我们的ELK不仅仅用在日志分析等方面，我们还把ES在一些查询搜索等业务上做了广泛的推广。
目前，我们的ELK在Rancher的K8S平台上进行迁移，也就是说我们在Rancher和K8S上吃的第一个螃蟹还是ELK。
上图是当初ELK在1.6上的架构图，和社区最佳实践比较类似，在这里就不详细赘述了。
这一部分是我们的重点——厦门航空的容器化的电商中台。
电商中台和厦航的电商战略是息息相关的。它作为支撑平台，可以实现以机票销售为中心，把不同类型的乘客以不同形式的旅程，包括不同内容的附加服务，打包在一起进行全流程服务，提升我们整个航空公司的业务水平。
目前，厦航电商中台对接了公司所有直销渠道、线上OTA渠道，也就是说假如你现在拿起手机或者通过电脑，在官方渠道或其他任何购票渠道上查询厦航的机票、购买厦航的机票，都会经过我们的电商中台。
上图是厦航电商中台的架构图。在这个图里面，除了红色部分的Redis、消息队列以及最下面的公共硬件LB设备，其他组件都运行在Rancher 1.6平台上。
上面这张是厦航电商中台生产环境的截图，包含我们厦航电商中台的所有服务。
这是在整个电商中台第一次迎接比较大的考验，对接阿里飞猪，当时我在Prometheus上截的图，留作纪念。里面有一个处理到的数据，大家可以看一下。
这张是前两天准备PPT的时候截的图，可以侧面看到我们的业务增长量。
讲完厦航电商中台的成果，我想藉这个机会再次感谢Rancher工程师对厦航电商中台以及容器云平台的大力支持。
接下来，我们来回顾厦门电商中台在容器化过程中，以及在测试上线过程中积累的一些经验和体会。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做了单节点的容器化，也是跑的测试环境。
我们计划以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能完美解决这些问题，那它离承载一切的目标或许就不远了。
以上是我今天的演讲，谢谢大家！
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
