[置顶] Zookeeper实现集群和负载均衡----（1）现状分析

1.概述

为了解决公司系统单点压力过载的问题，经过多次分析和借鉴当前主流的架构思想，决定使用分布式协调应用框架Zookeeper进行现有系统代码优化。

2.当前现状分析

 架构1.0– 线性模式：

存在问题：

1)中心节点过载:基于 B-Proxy 为中心化的通讯转发导致 B-Proxy 压力过大
2) 单点故障：B-Proxy 存在单点故障，各个B模块存在单点故障

架构2.0– 使用F5实现负载均衡

        

解决问题:

1)单点故障
2) 多路转发 -- 负载均衡
存在问题:
1)仍然存在中心，F5作为主中心, B-Proxy 作为副中心。F5 性能比较可靠，B-Proxy的转发工作量也被1分为4,1分为5.但依然是性能瓶颈。中心即为瓶颈，并会存在潜在问题。
2)运维和升级操作复杂，扩展成本高，不可持续。增加处理性能需要扩展 B-Proxy和B模块，性能提升依赖于硬件堆积，扩展成本高；模块增多导致运维和升级操作成本和风险成倍提高。靠扩展硬件提升性能成本太高，并且模块成倍增多，若不借助自动化运维工具，系统将变得不可维护。每次扩展和升级均需要配置F5服务器，也存在潜在风险。
3)现在缺乏依赖F5的心跳探测
现在系统监控依赖于 Negios , 服务转发依赖于 F5，两者没有结合起来。

3.当前现状分析

Ø  去中心化

  去掉以 B-Proxy 为中心的请求转发，A 直接请求B模块。服务请求者直接请求服务提供者。

Ø  动态扩展和高可用 (依赖于 Zookeeper 的监控(心跳检测)结果作为服务发现)

         服务(提供者)启动时实时被发现，动态扩展。服务Lost( 正常关闭、服务异常)时，实时更改可用服务列表，保持服务高可用。

Ø  配置共享

         多服务分布式集群部署时，减少升级和日常运维的工作量。单点故障问题也会解决，负载均衡功能也会实现。

总结：

为此我们选用了Zookeeper这种技术，除了如上特性Zookeeper自身可集群部署，可通过内部机制保证各个节点内部状态的一致性。保证了Zookeeper自身的稳定性。