餐饮圈APP后端容器化实践(2)

• 集群使用的etcd作为一个外部服务独立提供,对于用户不可见,也不可控.
• 请求链路不完全透明,链路跟踪有难度.
• 技术支持需要在群里喊. 当然群里管理员很负责,阿里云工程师都很专业,问题基本可以很快解决.但感觉技术支持的流程还不是太规范.

尝试Kubernetes集群

虽然Kubernetes提供了在AWS等云上的部署的驱动,但是对于阿里云,目前并没有集成进去. 所以,我们参考了阿里云初扬的《当 Kubernetes 遇到阿里云 之 快速部署1.6.1版本》(https://yq.aliyun.com/articles/73922)做POC.

对于刚刚接触Kubernetes的人来说,这很有挑战.

依然从三节点的测试集群开始,但马上遇到了虚拟网络层的问题,在经典网络模式下始终无法在集群内联通虚拟网络. 几次尝试未果后,转移到VPC网络,成功建立了集群,并打通了虚拟网络.

集群成功运行——只是个开始

经过两天的折腾,Kubernetes集群搭建完成. 但是还有很多东西需要完善,控制台UI界面、服务发现、日志、监控. 很显然这些都不在Kubernetes的核心中. 所有都需要借助其他开源项目来搭建,需要投入更多的人力和时间去完善. 对于小团队来说,希望将Kubernetes用于微服务架构的生产环境,挑战很大.咨询过一些前辈后,了解到在Kubernetes上部署Spring Cloud是一个用于微服务的选择,但是并没有继续尝试.

结论

优势

Kubernetes优势很多,比如大厂都在用,社区很活跃. 但我们最终并没有完整实践Kubernetes,所以没有办法谈对这些优势的体会.

对于小团队来说的挑战

• 阿里云上部署需要了解很多Kubernetes的基础组件,其中『虚拟网络层』搭建挑战很大.
• 如果希望用于生产环境,需要自行搭建高可用架构,并且搭建控制台,服务发现,日志等应用. (可以参考《在阿里云上部署生产级别Kubernetes集群》<https://yq.aliyun.com/articles/71037>了解部署高可用集群的方法,但文章中也没有提到微服务相关的工具如何搭建)
• 微服务平台相关组件都需要自行部署和配置.

选择——阿里云容器服务

经过对两个平台的POC,我们最后选择了提供了更多工具的阿里云容器服务作为容器化后端的方案.

对于小团队来说,容器化是为了提高生产力,开始选择容器编排平台时,我们忽略了微服务平台这个概念,将容器编排平台等同于了微服务平台. 在POC阶段,逐渐认识到了两者的不同,微服务平台可以构建在容器编排平台之上,也可以直接在云服务器上部署.

选择阿里云容器服务,其实是选择了一套微服务平台,并不单单是Docker Swarm.

坚持容器化后端,也是因为基于Docker的DevOps可以不局限于某种后端技术,更灵活的隔离应用运行环境,和控制应用对资源的使用.

第二张 Architecture Overview

目前实施的架构总览：

后记

在容器化后端过程中到我们底在选择什么

最初我们希望通过容器化后端架构来实现提高生产力这一目标. 在技术选型的开始阶段,“选择一个适合的容器编排平台”被定义为关键技术问题. 但随着POC的深入,只选择容器编排平台并不能解决提高生产力的目标,甚至容器编排平台本身并不能直接提高生产力,对于小团队来说反而需要投入更多的人力去维护. 我们认识到,对于一个3～5人的小团队来说,我们更需要的是一套微服务治理平台,这个平台是建立在IT基础架构之上的应用平台.而容器编排平台更像是IT基础架构针对容器的一层抽象,并不能直接满足小团队提高生产力的目标. 下图大概说明了,应用、微服务平台、容器编排平台、IT基础架构的关系.

所以,在容器化后端技术选型的后半程,我们更多的考量的是如何选择一个适合的微服务平台.最后基于阿里云容器服务,实现了我们的后端容器化的第一阶段. 因为Docker Swarm和Docker的无缝连接,开发团队并没有花费太多精力去学习新的概念,快速的将发布运维一系列工具迁移到了容器上. 在一个月之内,保证日常业务变更的前提下,完成了后端容器化,实现了提高生产力的目标.

还没做的事情

• 继续调研微服务平台
• 测试弹性伸缩

文章来自微信公众号：Docker

（编辑：ASP站长网）