实战训练营：传统分布式架构如何进行容器化升级

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

传统分布式架构的特色

传统分布式架构系统，通常具备如下两个特色：

1、根据业务和资源消耗的不一样，开发者会对传统分布式架构系统进行模块划分。例如：根据业务的区分，个推会划分出不一样的系统模块，和手机SDK创建长链接的客户端CM模块，以及负责消息路由的IM模块；根据资源消耗的不一样，个推会将屡次读写Redis 和屡次读写MySQL的用户模块拆开成不一样的角色。

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

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

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

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

容器化的机遇与挑战

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

◎Docker

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

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

◎Kubernetes

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

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

1、个推遇到的问题：

版本更新迭代快

应用进程多，服务器资源消耗大

服务器环境不统一

须要推动DevOps

2、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相关技术的发展，可以帮助咱们找到更多合适的容器化方式，从而作到完整的容器化，甚至是云服务化。

结语：

现阶段容器化大行其道，容器化在控制成本、保障服务稳定性、提升工做效率上都有极大的优点，然而传统分布式架构却每每因其基础组件和架构的定型，增长了容器化转型的难度，致使船大难掉头。本文但愿经过做者的分享，可以帮助开发者在容器化过程当中更好地理清本身的思路。

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