基于ZooKeeper大规模集群配置系统概述

转载自：http://blog.csdn.net/keyeagle/article/details/6936927

  通常大型互联网公司都拥有较大规模、结构复杂的服务器集群。随着互联网迅速发展，用户访问量以及服务器规模的越来越大，Web应用项目需要部署在数目众多的服务集群上协同工作，才为用户提供更可靠、稳定、优质的互联网服务。

       一般在互联网公司发展初期，服务器以及Web应用程序较少，项目的配置信息都会存放在文件中，比如把一些基本的数据库信息、缓存信息配置在文件中，如***.property文件中，每个项目都有自身单独的一份配置文件。这样的结构如下图所示：

       随着互联网的快速发展和用户的访问量越来越大，一个Web应用程序必须部署在几十台应用服务器上才能满足当前需求。此时再将项目的配置信息放入文件中，就会带来众多不便，比如：

1、项目在开发环境、测试环境、正式环境中很多配置信息都不一样，比如数据库配置等。一个项目要维护多个配置信息，以便在项目不同阶段使用。当项目配置越来越多，文件类型的配置则会变得混乱，它缺乏统一管理。

2、一个Web应用项目会部署在多台机器上，每次更新项目任何一个配置，都需要在不同服务器文件上更新很多次，这样容易出错而且麻烦。

3、  当更新项目的配置时，我们必须要将项目服务关闭，然后修改配置文件中的配置信息，并将项目重新发布，这必然造成一段时间内项目不能对外提供服务，一旦出现任何故障，这个一段时间可能更长。将配置信息放入文件中这样的配置方式不能做到配置信息的动态部署以及自动更新。

       在这样的情况下，建立集中式的配置系统就变得非常有必要。它的整体的配置架构图如下：

      

       下面讲述如何快速有效搭建大型互联网集群配置系统，它有如下四个重要的点：

1、 配置信息存储：项目配置信息怎么存放，放在那边，怎么保证其安全可靠？因为项目配置关系到项目能否启动以及正常运行。一旦配置系统出问题时，它关系到是整个公司的网站。

2、 请求配置信息：当一个Web应用程序启动时，它如何获取到项目的配置？这里可能会涉及到一些程序之间的通信，比如应用和配置服务器的通信等。简单来说，Web项目启动时需要向集群配置系统发送远程请求，获取项目启动的配置信息。

3、 监听配置信息：当项目某些配置信息修改时，配置系统如何通知到应用这些配置的项目，项目接收到配置修改的通知后，项目会做一些动态修改。如何进行监听配置的动态修改，以及根据配置修改项目能做出配置的动态更新？

4、 统一控制终端：集群配置系统最终要给出一个集中的Web控制终端来管理这些配置，包含配置信息增加、删除、修改、查询、部署等等。    

       解决了上面的四个问题，您就可以自己搭建了一套集群配置系统。如果有足够的人力资源、技术资源，您可以写一套分布式的存储来解决配置信息的集中式存储。您也可以写一套通信协议、或者在现有的通信协议上做一些封装来解决获取项目配置、以及监听修改配置的问题。最后您可以用PHP或者.Net来写一套配置终端。但当您没有那么多资源和时间时，也许如下的解决方案是个不错的选择，它能帮助你在很短的时间内搭建一套可靠的分布式配置系统。

       集群配置系统会应用到一个成熟的分布式服务开源框架—ZooKeeper。它是Apache Hadoop的一个子项目，它主要用来解决分布式集群中应用系统的一致性问题，它能提供基于类似于文件系统的目录节点树方式的数据存储。除了数据存储，它还可以用来维护和监控你存储的数据的状态变化。从设计模式角度来看，Zookeeper是一个基于观察者模式设计的分布式服务管理框架，它负责存储和管理大家都关心的数据，然后接受观察者的注册，一旦这些数据的状态发生变化，Zookeeper 就将负责通知那些已经注册的观察者做出相应的反应。ZooKeeper典型集群配置应用如下图：

       正如上图所示ZooKeeper帮我们解决上面四个问题中的三个。具体如下：ZooKeeper Server可以集中式存放数据，存放于上图的Configuration目录下，它有效解决了配置信息的集中式存储，同时ZooKeeper的工作模式是集群模式，一定程度上解决了配置系统的可靠性、安全性。ZooKeeper在java、ruby、C++都有自己线程的客户端Client。这些客户端负责和ZooKeeper Server进行通信，Client在应用程序启动时候向Server发送请求获取项目的配置信息，同时它还能监听这些配置信息的变化。当配置信息变化时候，项目会根据配置变化有一些自定义的操作，比如数据库重新连接，项目重新启动等等。所以ZooKeeper帮我们解决了第1、2、3个问题。最终我们只需要开发出一套配合集群配置系统运行的统一控制终端就可以了。统一控制终端可以是个B/S的管理类Web应用程序。

       下面以Java项目为例，应用ZooKeeper的整个集群配置系统结构图如下：

       如上图所示，ZooKeeper集群配置可以参考ZooKeeper开源文档来搭建，ZooKeeper集群由几台Server组成，Server中存放配置数据，集群的工作模式确保了数据的安全可靠。具体Java 应用程序可以通过ZooKeeperClient和ZooKeeper集群进行通信，获取项目的配置信息，同时监控配置变化。控制终端可能是简单的管理界面，在这个终端上管理着所有的项目配置。项目可能包括几个开发环境，因为在不同阶段搭建的配置是不同的。同时控制终端还将这些配置记录在本地数据库，以作备份。用户在控制终端上操作项目具体配置，包括增加、修改、删除等等。

这里谈谈ZooKeeper的一些关键技术以及用ZooKeeper构建大规模配置系统的细节，最后讲述我们在构建系统过程中的遇到问题及其解决思路，仅作参考，希望对您有所帮助。

         提到zookeeper，我们不得不提起Paoxs算法和LesileLamport。Paoxs算法是zookeeper的灵魂，这个算法是Leslie Lamport在1990年提出的一种基于消息传递的一致性算法。Paxos 算法解决的问题是一个分布式系统就某个值达成一致。典型的场景就决定zookeeper中的leader。算法具体可参见http：//zh.wikipedia.org/zh-cn/Paxos%E7%AE%97%E6%B3%95  

         集中式的配置管理在应用集群中是非常常见的，一般公司都会实现一套集中的配置管理中心，应对不同的应用集群对于共享各自配置的需求，并且在配置变更时能够通知到集群中的每一个机器。应用Zookeeper很容易实现这种集中式的配置管理，比如将APP1的所有配置配置到/APP1这个节点下，APP1所有机器一启动就对/APP1这个节点进行监控，并且实现回调方法Watcher，那么在zookeeper上/APP1下节点数据发生变化的时候，每个Client机器都会收到通知，Watcher方法将会被执行。以上这个例子只是简单的粗颗粒度配置监控，细颗粒度的数据可以进行分层级监控，这一切都是可以设计和控制。它的具体示例图如下：

         如图中/APP1目录下就项目APP1所有配置的信息，每个配置都是一个节点。Watch就是应用ZooKeeper来监控APP1节点数据变化。Watch可以理解为一个分布式的回调，当client关心的节点发生变化时，zookeeper将会把消息传回到client，并导致client的消息处理函数得到调用。zk的任何一个读操作都能够设置watch，例如：getData()， getChildren()， exists()

可以watch的event包括如下的二种：

n  KeeperState：Disconnected、SyncConnected、Expired

n  EventType：None、NodeCreated、NodeDeleted、NodeDataChanged、NodeChildrenChanged

         Zookeeper的使用主要是通过创建其jar包下的Zookeeper实例，并且调用其接口方法进行的，主要的操作就是对节点的增、删、改操作，监听数据节点的变化以及处理。它的简单示例如下图所示：

         上面对ZooKeeper的一些基本常识以及基本编程方法，下面谈谈我们在搭建集群配置系统中遇到的两个主要问题，以及它的解决思路。

问题1：ZooKeeper的session超时问题。

         超时问题是任何分布式应用程序都需要考虑到的问题，ZooKeeper也不例外。由于网络中断一段时间，当它自动恢复过来时候，如果这段时间大于设置的Session超时时间，此时就会产生超时异常。ZooKeeper客户端和服务器是基于长连接的方式，并用心跳保持连接，一旦遇到超时问题，这个连接就无效了。一般解决思路大致有如下三种：

l  在程序中显式用try和Catch主动获取超时异常，然后将客户端和服务器重新连接，前提是在您应用程序中要缓存一些重新连接需要的属性。

l  在程序中启动一个后台线程和ZooKeeper服务器进行通信，这个线程可以做数据的同步，同时也起到一个心跳作用。当检查到超时异常，程序重新连接ZooKeeperServer。

l  最优雅的一种方式，监控ZooKeeper最上层的父节点，当遇到超时异常时，此Watch的回调方法的参数event的属性KeepState包括了Expired，也就是超时异常，在此你可以重新连接服务器。

问题2：ZooKeeper和应用程序数据同步问题。

         ZooKeeper会协调应用程序的配置的一致性。但是应用程序是否需要始终需要获取配置的最新信息呢？显然不是。一个程序对外提供服务，它可能部署在10台机器上。当它有了新版本更新时，它的一些配置需要重新修改。项目版本更新时，总是先停掉部分机器，一批批的进行版本更新。如果项目始终获取的最新的配置信息时候，一些老版本项目会获取最新配置导致运行出错。这样的思路一般解决思路有如下：

l  ZooKeeper是的节点是带版本信息，项目一个版本可以和节点的一个版本进行对应。

l  将修改配置分为两种情况：修改ZooKeeper服务器配置，但是客户端已经运行配置不做修改；在修改ZooKeeper服务器配置，同时修改客户端的配置。