python zookeeper 服务发现

如果所开发的是个小系统, 那就根本没必要运用这种技术, 因为, 面临的问题并非怎样发现服务。对于那些规模较大, 且需要强大处理能力的系统来讲, 存在一个令人厌烦的问题, 即怎样对这些服务进行有效管理。

列举这样一个简易的事例, 你创作了一项服务, 该服务用以接收某一内容, 进而返回此用户的姓名、电话一类的信息, 这般看来显得颇为简易, 随后你启用这项服务并对外界供应服务。然而没过多久, 你的这项服务承受不住重负了, 缘由在于请求数量过多了, 要留意, 这些请求皆是整个大型系统的内部其他模块发送出来的。有这样一种情况, 单独一个服务不够使用, 于是我们选择启动多个服务, 并且采用 nginx 来担当负载均衡。如此实行确实是可行的，可是依旧存在着相应问题, 具体而言, 就是在增添新的服务以及撤掉某一个服务之际, 均要对 nginx 的配置加以修改。倘若 nginx 出现故障挂掉了, 要不然就是单一的一个 nginx 无法满足需求, 进而又增添设置了一个 nginx 服务器, 在这种状况下, 究竟该以何种方式去告知那些发送请求的模块。

这是一个可能为复杂度较高的系统所遭遇到的情况, 在服务环节要求有水平方向的拓展, 然而, 在进行此项拓展事宜之际, 需要借助一种方式去示意那些发出请求的人, 如此方能达成该项职责的履行。

你将其理解成是一棵树, 你能够于树上创建节点, 在新的那些节点之上依旧能够创建节点, 存在一种节点称作临时节点, 通俗来讲, 也就是创建此临时节点的进程要是挂掉了, 便会把这个节点删掉, 服务发现便是要借助这个性质。首先, 咱们在上面创建一个名为kwsy的节点, 这名字是我随意起的, 会让所有向服务发送请求的模块都来监视这个节点, 一旦这个节点下的子节点出现了变化, 像新增、删除这种情况, 那么这些进行监视的模块都会收到消息, 此时, 它们就知道是不是有新的服务被启动了或者某个服务挂掉了各服务在启动的时候, 都会在kwsy节点下创建一个新的节点, 顺便把自身的一些信息, 比如IP地址、端口号、url等信息写入节点中。

先来一段代码来模拟服务的注册过程

#coding=utf-8
from kazoo.client import KazooClient
import time
zk = KazooClient(hosts='127.0.0.1:2181')
zk.start()
def test_ensure():
zk.ensure_path('/my/favorite')
def test_create():
nodename = '/kwsy/service'
index = 1
while index < 10:
zk.create(nodename,'123.56.190.151_{index}'.format(index=index),ephemeral=True,sequence=True)
time.sleep(10)
index += 1
if __name__ == '__main__':
#zk.delete('/kwsy')
test_create()
zk.stop()

于进行创建节点这个操作之际, 将二者标识均指定为真态, 其中前者意示该节点当属临时节点范畴, 后者则表明其为次序井然之有序节点, 二者综合起来便构成一个有序临时节点。当指定其为临时节点后, 若出现服务崩溃的状况, 那么在服务启动之时所注册的该节点将会被予以删除动作, 如此这般, 请求模块便可得知此情况。在创建节点之时, 存在需要指定节点名称这一要求, 若将其指定为真态, 便会由自身为节点赋予名称, 并且此名称具备有序性, 这般一来, 我们便无需担忧节点名称会出现冲突情形了。

再看模拟请求模块监视的过程

#coding=utf-8
from kazoo.client import KazooClient
import time
zk = KazooClient(hosts='127.0.0.1:2181')
zk.start()
service_lst = []
@zk.ChildrenWatch('/kwsy')
def my_func(children):
global service_lst
service_lst = children
children = zk.get_children('/kwsy',watch=my_func)
for child in children:
service_lst.append(child)
while True:
print service_lst
time.sleep(10)
zk.stop()

对于/kwsy这个节点, 程序会进行监视, 只要有新的节点被创建, 或者节点被删除, 都会触发这个函数, 这样一来, 就能获得最新的子节点信息，而拿到这些子节点信息后, 就可知道服务的IP地址、端口号等信息, 随后, 便是以轮换或者随机的方式向这些服务发送请求啦。然需指明者, 服务挂掉之后, 删除节点存有延迟, 此即意味着, 发送请求之模块不可仅依监视结果判定服务是否归挂, 却应自有一法判定当前选中服务是否可用, 毕竟, 吾等乃在用做服务发现, 并非用以识此挂掉之服务。