容器化思维传统分布式架构容器化的实践和挑战

Posted

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了容器化思维传统分布式架构容器化的实践和挑战相关的知识,希望对你有一定的参考价值。

作者:个推研发专家朱明智

随着以Docker为典型代表的容器化理念逐渐兴起,众多的使用分布式架构的公司和企业,开始考虑对原有系统进行容器化升级。传统分布式架构为什么需要容器化?容器化面临怎样的机遇与挑战?作为智能大数据服务商的个推如何将容器化落地?未来将有怎样的发展?本文以个推在容器化上的实践为例,与大家一起探讨及展望。

传统分布式架构的特点

传统分布式架构系统,一般具有以下两个特点:

一、根据业务和资源消耗的不同,开发者会对传统分布式架构系统进行模块划分。例如:根据业务的区分,个推会划分出不同的系统模块,和手机SDK建立长连接的客户端CM模块,以及负责消息路由的IM模块;根据资源消耗的不同,个推会将多次读写Redis 和多次读写mysql的用户模块拆开成不同的角色。

二、在传统分布式架构系统中,相同的角色模块会有多个实例。这种系统,一方面做到了高可用性,当一个服务器宕机时不影响整体业务。另一方面,在压力变大时方便通过扩容提升吞吐率。例如:当偏重Redis读写的角色请求较多的时候,系统就只需要扩这个角色的实例。

多年实践证明,传统分布式架构系统具有易拓展、高可靠、高效率、低沉本的显著优势,但也具有一定的局限性。

由于角色模块纷繁复杂的特性,传统分布式架构系统在配置管理、服务资源管理、部署环境等工作中难以通过人工快速地完成。例如:针对每个业务模块的不同版本,上线前都需要开发者一一做配置修改;当需要修改具体功能时,必然牵涉很多模块,为开发者产生大量重复的工单。

那么,怎样才能解决这些问题,创建出理想的线上环境和良好的可视化管理系统?这时,我们想到了容器化。

容器化的机遇与挑战

容器化能够有效地解决传统分布式架构系统的一系列问题。其中Docker和Kubernetes是最常用的开源容器引擎和编排工具。

◎Docker

Docker无疑是目前最受欢迎的开源容器引擎。Docker的原理,是将多个应用以及运行所需要的一切环境,都通过集装箱也就是容器包装起来,这样放置就可以避免很多因不规整而带来的隐患。例如:Docker可以有效避免Java环境版本差异、不同应用相互影响、使用资源相互竞争等问题。

个推在使用Docker时,沿用了Docker镜像的分层策略。首先,个推的各个产品线模块,使用的是各自的基础镜像。其次,个推各产品线的服务程序,打在了各自的基础镜像层之上,这样操作能确保各个容器的运行环境互不冲突。

技术分享图片

◎Kubernetes

Kubernetes是一个用于容器集群的自动化部署、扩容以及运维的开源平台。Kubernetes的理念在于指点每个集装箱的摆放,降低服务器资源难度,让运维管理变得更加简便。

个推选择Kubernetes作为Docker容器编排的工具,主要有两方面的考量。

一、个推遇到的问题:
版本更新迭代快
应用进程多,服务器资源消耗大
服务器环境不统一
需要推进DevOps

二、Kubernetes的优势:
运维自动化
应用容器一次性构建
计算机硬件资源能够充分利用
编排管理具有突出优势

在应用Docker和Kubernetes的过程中,个推受益良多,同时也为个推原有的分布式系统结构带来一些压力。例如:个推系统的原有框架及模块都需要改动适配;原有系统非常庞大,需要逐步进行迁移;对原有的生态服务必须有所取舍。因此,我们通过一次落地的容器化实践来探索这个领域。

个推容器化实践

在个推的某项目中,我们进行了一次全程的容器化实践。

在具体实施前,我们先确定整体的架构图,架构图包含Kubernetes基本的一些结构。例如:在Master节点部署上,APIserver是整个系统的控制入口,Scheduler负责任务调度、命令下发,Controller Manager则作为集群内部的管理控制中心;在Node节点部署上,Kubelet作为Agent监听执行该节点的任务,汇报该节点的状态,而Proxy则负责整个网络规则的连接与转发。

当具体实践时,有状态组件怎样才能成功部署,内外网如何实现互通,需要怎样的配置中心,监控怎么做,都是开发者容易遇到的问题。

◎有状态组件的部署

在Kubernetes中,存在很多无状态组件,它们对于Pod的管理都是基于无状态、一次性的理念。如Replication Controller,它只是简单地保证可提供服务的Pod数量。如果一个Pod被认定为非健康 的状态,那么Kubernetes就会以非常简单粗暴的态度对待这个Pod:删掉、重建、自动扩缩容。这种处理方式通常适用于业务逻辑处理和内存计算型程序。

但是, Kubernetes可以通过StatefulSet的方式,给Pod提供唯一的标志,从而保证ZooKeeper、MySQL、Redis等有状态组件的成功部署和有序扩展。

但在系统中,如果要满足服务的Pod无论被置于何处,数据都要落地到同一目录的要求,当有状态组件被放置到容器中时,挂载就肯定需要经过网络。然而,使用网络卷进行挂载没有本地挂载可靠,网络的性能损耗也是高于本地的几十倍上百倍。同时,这种组件的维护操作并不频繁,没有为运维带来太多便利。因此,经过综合考虑,个推没有将这类有状态组件放到容器中。

◎内外网络的互通

内外网络的互通是容器化过程中容易遇到的典型问题。个推使用calico进行虚拟地址的分配,所以同个集群内的网络可以实现互通。集群内的服务访问外部的时候,可以直接使用真实的物理地址。集群外的服务访问内部的时候,需要通过iproute的方式,将虚拟ip映射到真实ip,才能实现内部服务的访问。

◎配置中心

关于配置中心,可以先整理罗列一些需求点,标出重点后逐个去解决。个推此次容器化实践过程中重点关注的需求点包括配置中心集群化,提供WEB界面化管理和权限管理,支持多种环境配置,开发集成简单,本地有备份等。

在对一系列开源配置中心进行调研后,通过对比QConf、diamond、Xdiamond、disconf、Apollo、mconf以及xxl-conf的各项功能,个推选择了功能更加齐全的Apollo。

技术分享图片

(注释:调研具有时效性,图中某些配置中心的最新版本,现在可能已经支持当时还未支持的功能)

◎监控采集

运行在Kubernetes里的应用程序,容易产生如网络同外部隔离、生存周期受集群管理、运行节点不固定等问题。我们通过对自有的监控系统进行一些调整,比如将主服务部署在Kubernetes集群外部,在集群每个Pod里面部署Agent,从而实现数据的采集监控并汇报主服务。

容器化的后续展望

最后,个推希望在吸取本次经验的同时,对未来的容器化实践有所规划与展望。例如,我们可以考虑从业务监控和扩缩容结合、自动化测试、Stateful服务等方面继续深入探索。

业务监控和扩缩容结合,能识别出假死,判断出业务压力。自动化测试,通过补充各个业务和模块的自动化测例,便能在很大程度上节省回归测试的成本,更好地实现快速迭代持续交付的目标,是DevOps进程中非常重要的一步。Stateful服务,后续随着Kubernetes相关技术的发展,能够帮助我们找到更多合适的容器化方式,从而做到完整的容器化,甚至是云服务化。

结语:

现阶段容器化大行其道,容器化在控制成本、保障服务稳定性、提高工作效率上都有极大的优势,然而传统分布式架构却往往因其基础组件和架构的定型,增加了容器化转型的难度,导致船大难掉头。本文希望通过作者的分享,能够帮助开发者在容器化过程中更好地理清自己的思路。

需要注意的是,容器化实践并不是为容器化而容器化,而是在充分理解现有业务需求和解决方案的基础上,通过容器化提供更高效、更稳定的系统服务,这才是容器化真正的价值所在。

以上是关于容器化思维传统分布式架构容器化的实践和挑战的主要内容,如果未能解决你的问题,请参考以下文章

应用统计平台架构设计:智能预测APP统计数据

有容云:微服务容器化的挑战和解决之道

基于Docker+Kubernetes,微服务容器化开发实战

资深架构师分享:1 天落地的 Kubernetes 容器化方案

干货 | 工行分布式数据库选型与大规模容器化实践

聊聊微服务架构实践之路的4大挑战,3月31日见真章!