一:配置中心
在平常的业务开发过程中,我们通常需要将系统的一些通用的全局配置,例如机器列表配置,运行时开 关配置,数据库配置信息等统一集中存储,让集群所有机器共享配置信息,系统在启动会首先从配置中 心读取配置信息,进行初始化。传统的实现方式将配置存储在本地文件和内存中,一旦机器规模更大, 配置变更频繁情况下,本地文件和内存方式的配置维护成本较高,使用zookeeper作为分布式的配置中 心就可以解决这个问题。
我们将配置信息存在zk中的一个节点中,同时给该节点注册一个数据节点变更的watcher监听,一旦节 点数据发生变更,所有的订阅该节点的客户端都可以获取数据变更通知。
二:负载均衡
建立server节点,并建立监听器监视servers子节点的状态(用于在服务器增添时及时同步当前集群中服 务器列表)。在每个服务器启动时,在servers节点下建立具体服务器地址的子节点,并在对应的字节点 下存入服务器的相关信息。这样,我们在zookeeper服务器上可以获取当前集群中的服务器列表及相关 信息,可以自定义一个负载均衡算法,在每个请求过来时从zookeeper服务器中获取当前集群服务器列 表,根据算法选出其中一个服务器来处理请求。
三:命名服务
命名服务是分布式系统中的基本功能之一。被命名的实体通常可以是集群中的机器、提供的服务地址或 者远程对象,这些都可以称作为名字。常见的就是一些分布式服务框架(RPC、RMI)中的服务地址列 表,通过使用名称服务客户端可以获取资源的实体、服务地址和提供者信息。命名服务就是通过一个资 源引用的方式来实现对资源的定位和使用。在分布式环境中,上层应用仅仅需要一个全局唯一名称,就 像数据库中的主键。
在单库单表系统中可以通过自增ID来标识每一条记录,但是随着规模变大分库分表很常见,那么自增ID 有仅能针对单一表生成ID,所以在这种情况下无法依靠这个来标识唯一ID。UUID就是一种全局唯一标 识符。但是长度过长不易识别。
- 在Zookeeper中通过创建顺序节点就可以实现,所有客户端都会根据自己的任务类型来创建一个顺 序节点,例如 job-00000001
- 节点创建完毕后,create()接口会返回一个完整的节点名,例如:job-0000002
- 拼接type类型和完整节点名作为全局唯一的ID
四:DNS服务
- 域名配置
![](https://i-blog.csdnimg.cn/blog_migrate/85422e509e6e777da076189908591d4f.png)
- 域名解析
应用解析时,首先从zk域名节点中获取域名映射的IP和端口。
- 域名变更
每个应用都会在在对应的域名节点注册一个数据变更的watcher监听,一旦监听的域名节点数据变更, zk会向所有订阅的客户端发送域名变更通知。
五:集权管理
集群管理主要体现在
- 集权控制:对集群中节点进行操作与控制
- 集权监控:对集群节点运行状态的收集
在日常开发和运维过程中,我们经常会有类似以下的需求:
- 希望知道当前集权究竟有多少机器工作
- 对集群中每台机器的运行状态进行数据收集
- 对集群中机器进行上下线操作传统方式
传统方式
在传统的基于Agent的分布式集群管理体系中,都是通过在集群中的每台机器上部署一个Agent,由这个Agent负责主动向指定的一个监控中心系统(监控中心系统负责将所有数据进行集中处理,形成一系列报表,并负责实时报警,以下简称“监控中心”)汇报自己所在机器的状态,在集群规模适中的场景下,这确实是一种在生产实践中广泛应用的解决方案,能够快速有效的实现分布式环境集群监控,但是一旦系统的业务场景增多,集群规模变大之后,改解决方案的弊端也就显现出来。
大规模升级困难,编程语言多样性
随着分布式系统规模日益扩大,集群中机器的数量越来越多。有效的集群管理越来越重要了, zookeeper集群管理主要利用了watcher机制和创建临时节点来实现。以机器上下线和机器监控为例
新增机器的时候,将Agent部署到新增的机器上,当Agent部署启动时,会向zookeeper指定的节 点下创建一个临时子节点,当Agent在zk上创建完这个临时节点后,当关注的节点 zookeeper/machines下的子节点新加入新的节点时或删除都会发送通知,这样就对机器的上下线 进行监控。
在机器运行过程中,Agent会定时将主机的的运行状态信息写入到/machines/hostn主机节点,监 控中心通过订阅这些节点的数据变化来获取主机的运行信息。