餐饮圈APP后端容器化实践

《餐饮圈APP后端容器化实践》要点：
本文介绍了餐饮圈APP后端容器化实践，希望对您有用。如果有疑问，可以联系我们。

项目介绍

简单介绍一下餐饮圈项目规模,以及团队配置,用以作为技术选型和实践的参考条件.

餐饮圈介绍

餐饮圈是专注于餐饮行业社交,招聘的APP. 后端采用微服务的设计思想,将不同的业务放在不同服务中. 随着业务的发展,目前后端服务有20多个.

容器化之前,采用的是传统的负载均衡(阿里云负载均衡)、多台服务器(阿里云ECS)、数据库(阿里云RDS)模式.

团队规模介绍

研发团队3～5人,同时负责前端APP和后端的研发和运维.日常的开发流程采用敏捷开发的Scrum方法.

一个简单的目标——不断提升生产力

不断提升生产力是促使团队尝试容器化后端的主要动力.

随着后端服务的增多,在服务管理方面投入的时间增多,团队注意到用于发布,调试和监控服务的时间越来越多. 因为之前采用的是单一Tomcat运行所有服务,导致每一个服务的变更都需要重启整个Tomcat. Tomcat也占用了大量的服务器内存.

于是,列出了希望提升的几个点：

• 更简化的发布部署方法
• 更灵活管理服务对资源的使用
• 更高效的管理服务器资源,实现快速弹性伸缩

基于以上三点,团队开始考虑容器化后端,使用容器编排平台来管理服务.

注意：容器化后端,并不是解决上面问题的唯一选择.后来的实践中也渐渐体会到,容器化后端是很重大的决定,改变的是整个后端的基础架构.之所以没有过多犹豫就选择容器化方案,是因为团队内有人熟悉容器,而且现有后端基础架构相对简单.

第一张架构总览

项目后端在阿里云上,持久化存储用的全部是阿里云的服务. 数据库使用RDS,图片等静态文件使用OSS,Redis使用云数据库Redis,所以容器化过程不存在应用服务器有持久化数据的问题,只需要保证容器平台可以顺利链接阿里云服务器即可.

注：应用服务器无状态化是容器化之前很关键的点,如果应用服务器上存有数据,例如图片、缓存等,需要先将这些数据转移到云平台的存储服务中,可以参考12 Factor App(https://12factor.net/zh_cn/)这篇文章.

下面是第一张架构总览,简单的从逻辑层面描述了容器化后的后端架构.

可以看到容器编排平台是架构的核心,所以选择一个适合的容器编排平台是容器化后端的关键.

容器编排平台的选择

我们选择了三个容器编排平台作为备选方案：

• Docker Swarm
• Kubernetes
• Rancher

Docker Swarm作为Docker自家出品的容器编排服务,和Docker无缝连接,实施简单,学习曲线平滑,了解Docker使用的程序员可以很容掌握.而且,阿里云容器服务也采用了Docker Swarm作为基础.

Kubernetes,很多大厂用它实现了PaaS服务,在企业级解决方案中Kubernetes也经常被采用作为PaaS平台的基础,可以侧面体现出Kubernetes的可靠性,稳定性等优势.作为Google自家集群管理工具的开源版本,Kubernetes有很高的呼声.

Rancher相对于前两个选择,有着开箱即用的特性,提供了完整的UI控制台.在集群管理方面有多种选择,可以选择Kubernetes,Docker Swarm来做容器编排. 但是因为国内相关实践例子不多,很快就被从选项中去掉.

尝试阿里云容器服务——Docker Swarm

第一个POC是在阿里云容器服务上做的,因为阿里云容器服务采用Docker Swarm基础,而且提供了一套完成的UI控制界面. 借助官方提供的文档,一天内完成了三台服务器节点的测试集群搭建,并发布了几个测试服务.一切进行的很顺利.第二天,陆续将全部服务都部署上去,并开始性能和压力测试.

阿里云容器服务架构如下(来自官方文档)：

第一个问题

在测试过程中,遇到了第一个问题,响应时间不稳定. 有些服务第一次请求响应时间在几千毫秒到几百毫秒波动,并不稳定.

翻阅了路由部分的文档,找到了请求如何在平台内路由的示意图如下：

可以看到Routing容器起到了服务发现和路由转发的作用,负载之后所有请求都会经过Routing容器. 容器内是HAProxy做请求转发.

因为请求经过负载,又经过Routing容器,然后由虚拟网络层在集群内转发到提供服务的容器. 此过程,在请求到达服务容器之前都没有日志可以跟踪,始终无法知道延迟出现在哪一步.

再后来的实施中这个问题随着增加服务容器实例的个数得到缓解,但是始终没有找问题的根本原因(并不能排除应用层本身有的问题的可能).

雪崩

压力测试过程中,集群出现了第一次雪崩,三个节点全部掉线,并且无法SSH登录.

调查雪崩原因有两个：

• 没有限制容器使用资源,导致容器过载后瞬间吃掉系统内存 (参考阿里云文档解决,https://help.aliyun.com/document_detail/26017.html).
• Tomcat官方镜像并不能很准确的计算出JVM的最大使用内存是多少,导致服务容器过载后不断重启(具体解决办法可参考这篇文).

结论

优势

• 阿里云容器服务,提供了类似Rancher的开箱即用的特性,只需要将云服务器配置到集群中就可以自动完成集群的部署. 并且可以通过控制台界面,快速完成阿里云日志服务,云监控等功能的集成. 对于没有专门运维人员的小团队,能节省很多维护时间.
• Docker Swarm作为基础架构,开发团队学习曲线平滑,只需要掌握docker基本知识就可以上手使用.

有待解决的问题

（编辑：ASP站长网）