zookeeper 网关_假期结束遥遥无期，太无聊使用zookeeper对系统进行优化

这个春节假期有点长，闲来无事在家优化系统，引入了zookeeper，简化了之前系统中一些复杂且欠合理的机制。

我们的系统是一套分布式的游戏服务器系统，大致结构如下

有一组前端，当然这里的前端不是web前端网页，而是服务器上的一组网关，用于接收来自客户端的请求

有一组后端，用作业务处理。当服务器前端接收到来自客户端的请求时，会根据后端集群的负载情况把请求分派给负载较小的后端进行处理。

有一组地址服务器，用于给客户端分派前端服务器地址，因为前端服务器会动态的增加和减少，所以当客户端有服务器处理需求时，会去地址服务器获取当前可用的前端服务器地址，然后向获得到地址发送请求。地址服务器相对稳定，不太会有变动。

有一个管理系统服务器，这个系统不直面用户，而是为游戏运营人员使用的系统提供服务，不需要很大的承载量，所以只有单个节点。比如说游戏的运营人员需要给玩家发送邮件，运营系统就是调用这个服务器的接口进行操作的。

这套系统中有一些不合理的地方，比如地址服务器要知道当前有哪些前端服务器处于可用状态。 之前我们采用最传统的方法，在每个前端服务器中启动一个定时任务，将自身的信息通过http请求定时发送给每个地址服务器。如果地址服务器持续能收到某个前端服务器上报的信息，则表明这个前端可用，如果离某个前端上一次上报信息的时间过长，则表明这个前端不可用。

这种方案不但复杂，而且非常不可靠。复杂性在于前端服务器必须知道地址服务器的信息，才可以上报信息，这造成了前端服务器与地址服务器的耦合，软件开发倡导的是低耦合，服务器架构亦是如此。 不可靠性在于，因为前端服务器是间隔上报，比如间隔10秒上报一次，所以地址服务器不能实时知道前端服务器的情况，之间有10秒误差。假如前端服务器在上报后1秒挂掉，那么在后面的9秒，地址服务器还会将这个挂掉的前端返回给客户端，造成客户端访问前端出错。因为前端挂掉这种事情实在太罕见，所以一直以来也没在意这种潜在的风险，但风险是实际存在的。

zookeeper非常适合解决这类问题，zookeeper有临时节点的概念，注意，这里说的节点不是分布式服务器中的服务器节点，而是zookeeper数据存储结构中的一种数据节点，可以通过程序增删查改。 临时节点的含义是当某个程序与zookeeper建立会话(连接)，程序通过这个会话创建临时节点，那么这个节点只在这个会话有效的情况下存在，如果会话失效，比如程序停止、会话超时，那么服务器会自动把这个临时节点删除。

临时节点的这种特性很适合解决前端服务器与地址服务器之间存在的那两点问题。首先他们之间的依赖关系，原本前端服务器依赖于地址服务器，需要持有地址服务器的相关信息，zookeeper对两者之间的关系进行解耦，相当于引入了一个中间层，这正是面向对象中所倡导的依赖倒转原则。当前端服务器启动时，与zookeeper建立会话并创建一个临时节点，节点中包含了前端服务器的相关信息。而地址服务需要获取前端服务器的信息时，只需要去zookeeper中查询这些临时节点，zookeeper成为了两者之间的信息中转站。

与此同时因为临时节点的特性，地址服务器读取前端服务器的时效性也得到了解决。当前端服务器启动时，建立与zookeeper的会话并创建一个临时节点，节点中包含前端服务器需要向地址服务器上报的信息，供地址服务器查询。当前端服务器下线时，与zookeeper的会话失效，zookeeper会自动删除此会话相关的临时节，相当于及时向地址服务器屏蔽这个前端节点，之前的上报信息延迟所带来的风险得到有效的解决。

以上是利用zookeeper临时节点特性优化系统的一个点。除此之外，zookeeper还有事件监听的功能，当zookeeper中的节点发生变化，节点的监听者都能收到通知。这种功能很常见，很多中间件都有，比如ActiveMQ，Redis，只是ActiveMQ或者Redis除了事件监听以外还夹杂着其他功能，为了监听一个事件而使用它们，有种杀鸡用牛刀的味道，zookeeper则更加纯粹，watcher是它的核心功能，因此有这类需求时优先选择了zookeeper实现。

前面我们说过，游戏运营人员通过调用运营系统服务器给玩家发送邮件，运营系统服务器与后端服务器保持连接，当接收到邮件请求时，向后端服务器发送一个邮件消息，后端服务器接收到消息后在转发给前端服务器，前端服务器收到消息后，在转发给客户端玩家。这个流程很复杂繁琐，简直反人类。

有的同学可能有疑问，运营系统服务器为什么不跳过后端服务器直接与前端服务器建立连接，反而要经过后端服务器中转，之中原因在于，后端服务器本身就要与运营系统服务器保持连接，避不开，而前端服务器却不是必须的，现在为了邮件通知功能而去增加两者的耦合度，着实有种捡了芝麻丢了西瓜的味道，得不偿失。引入zookeeper后，可在zookeeper中添加一个邮件节点，每次发送新邮件，运营系统服务器将邮件内容写入邮件节点，前端服务器监听这个节点的变化，来向客户端发送通知。设计模式一种最常用的模式观察者，通过向模型注册观察者对象来接收模型变化的通知，zookeeper的watcher就是观察者模式的一种应用。

理想情况下，分布式服务器的各个节点的关系统一由zookeeper进行关联，每个节点本身可以不知道他所依赖节点的具体信息，不用在配置文件中配各种所依赖的节点信息，所有节点的数据同步、消息通知也由zookeeper完成，这会对系统的可维护性带来极大的改善。尤其对于运维是一种解放，避免维护大量复杂的配置文件。

以上两点优化是zookeeper的初步应用，我们的系统中还有更多场景来用zookeeper进行调优。