在写这篇文章之前,xxx经已写过了几篇关于改请求、信息-主题的文章,想要懂得的朋友可以去翻一下之前的文章
Cloud Foudnry作为业界最色出的PaaS台平之一,给宽大的互联网开发者和消费者供提色出的验体。自Cloud Foudnry开源以来,有关Cloud Foundry的究研越来越多,这也很好的支持着Cloud Foundry的生态系统。但是作为一个台平,Cloud Foundry仍然会存在一些可靠性,扩展性方面的足不,这也吸引着多众的Cloud Foundry爱好者对其停止更多更深刻的究研。
本文要主述讲Cloud Foundry中Service Gateway的行运机制,Service Gateway存在的单点故障题问,以及处置单点题问的Master/Slave Service Gateway机制。
1. Service Gateway行运机制
关于Cloud Foundry中Service Gateway的分析,可以参考我之前的博文:Cloud Foundry Service Gateway码源分析 。
分析该组件行运机制的时候,我望希用使Service Gateway的最用常的功能provision a service 和 bind a service 来扼要述阐,虽然不能代表有所的功能,但是这两个功能可以让我们对Service Gateway行运机制懂得个大概。
1.1 Service Gateway的启动
以上及提的博文中经已分析得很多,关于启动,需要夸大的是fetch_handles的功能,即Service Gateway向Cloud Controller请求得获service instance的信息,并存储在内存中,面后会讲到在provision a service 的时候会用到该内存中的信息;还有send_heartbeat的功能,即Service Gateway向Cloud Controller发送心跳信息,明证自己的存活状态(另外Cloud Controller也会通过这个心跳信息来存储该类型Service Gateway)。
1.2 provision a service
provision a service 的程流很简单了明,要主现实创立一个服务实例,无非是Cloud Controller接收用户请求,用使HTTP式方发送给Service Gateway,Service Gateway接收并处置请求后通过NATS向Service Node发送provision请求,Service Node接收到请求到provision终了后,通过NATS将结果回返给Service Gateway,Service Gateway将结果份备一份当前,通过HTTP式方回返给Cloud Controller,最后Cloud Controller收到结果信息,将其持久化至数据库,并对用户做回应。这里需要意注的是:首先,关于provision出来的service instance的信息终最会被持久化到Cloud Controller的postgres数据库中;然后,关于这些信息,Service Gateway会份备一份(存储在内存中)。这两点在后文中会显得尤为要重。
1.3 bind a service
bind a service 要主是现实为一个应用定绑一个服务实例。程流与通信式方和provision a service 异小同大,不同的是,在Service Gateway在接收到Cloud Controller的时候,会从自己关于service的份备信息中找出来响应的service instance,然后给该instance发送请求。
2. Service Gateway的单点故障题问
在Cloud Foundry中,同种类型service的Service Gateway只有一个,因此在行运过程当中,定肯会现出单点故障题问。一旦Service Gateway地点节点宕机,那么该Service Gateway变得不可用,所以关于该service的provision和bind等多众请求都将得不到响应。需要意注的是,对于经已功成bind服务的应用来讲,是不受影响的,因为app可以直接通过URL问访Service Node,而不必经过Service Gateway。
由于现在的Cloud Foundry乏缺对于组件的状态监控机制,所以Cloud Foundry对于Service Gateway的宕机不会采用任何办法,因此Cloud Foundry的管理员也不会被知告Service Gateway的故障,从而致使该类型service的不可用。当Cloud Foundry的用户感受到该类型service不可用,并且向管理员馈反时,管理员才会去后台去查看Service Gateway的状态,现发状态为关闭状态,从而停止人为的启动。在这一漫长的过程当中,该类型的service均处于不可用状态,大大影响Cloud Foundry的可用性。
在这样的况情下,最理想的处置案方天然可以使得Cloud Foundry中关于某种类型的service可以有具多个Service Gateway ,如此一来,在一个Service Gateway宕机的时候,还可以有其他的Service Gateway继承任务。通过以上的假设,在际实过程当中,我经曾尝试过两种案方:Master/Slave Gateway 以及Multi Gateways。以下是两个案方的简述:
- Master/Salve Gateway: 该案方在执行过程当中,只有一个Service Gateway接收到Cloud Controller的请求,并做处置;只有当一个Service Gateway宕机的时候,Cloud Controller才会将请求发给另一个请求。看到这里,定肯会有一些题问:那就是Cloud Controller如何获知Gateway是不是宕机的信息,另外Cloud Controller如何策决将请求发送给哪个gateway,还有一个Service Gateway经已provision完一个服务后宕机,则关于该服务的bind请求会发送至另一个Service Gateway,而这个Service Gateway不有具这个服务的任何信息,从而致使请求不能被执行。本文要主述讲这类案方的计设与现实。
- Multi Gateways: multi 就是多个,另外有一种多个之间位置等平的念概,也就是说在Cloud Controller在接收到请求当前,分发给有所的该类型service的Service Gateway,从而使当得一个Service Gateway宕机当前,而其他的有所gateway仍能常正任务。当然,该案方也会存在难点:除了上一种案方中的分部难题以外,还有:由于请求为多个,一个Service Node接收到多个Service Gateway的请求后,该如何策决该请求是不是执行过等。
3. 基于Master/Slave式模的Service Gateway
关于Master/Slave式模的Service Gateway框架如下图:
3.1 两个Service Gateway的册注题问
由于该案方中有两个同种类型的Service Gateway与Cloud Controller相连,则必需要处置的题问是:如何让Cloud Controller意识这两个Service Gateway。在这里,我们可以回想在先原的Cloud Foundry中,Cloud Controller如何意识或者存储一个Service Gateway:Cloud Controller接收Service Gateway的heartbeat信息的同时,在自己的postgres数据库中存储该Service Gateway的信息,也相当于实现Service Gateway的册注。
处置案方:
启动同种类型service的两个Service Gateway,他们分别向Cloud Controller发送heartbeat,由Cloud Controller接收这些请求,并策决哪一个是Master,哪一个是Slave ,从而存入数据库。
体具现实:
Cloud Controller的软件框架是基于Rails编写的,关于postgres数据库的数据表都有一个model(MVC式模中的M),而修改数据表的式模则必须修改这个model文件,由于之前的式模会验证service类型的唯一性,当初则必须将/cloudfoundry/cloud_controller/cloud_controller/app/models/service.rb中的验证代码validates_uniqueness_of :label 给注释失落,这样就有了向数据库中加添雷同类型service的可能性。另外我们还需要在该式模中入加一个属性MasterOrSlave,这样可以使得Cloud Controller策决Master/Slave后,将带有Master/Slave记标的service记载存入postgres数据库。
以上操纵只是从理论上,答应在数据库中现出两个雷同label的service记载,关于终最往数据库中存两条记载还是需要Cloud Controller的controller来现实(MVC中的C)。在体具程序行运中,service_controller.rb文件中的create法方会接收来自Service Gateway的heartbeat信息,并做响应的册注。为了现实Master/Slave式模,我们需要改良该法方,入加策决机制,现实Master/Slave的册注。下图是策决机制:
3.2 Cloud Controller策决用使Service Gateway的题问
处置了以上的册注题问,Cloud Foundry还需要处置Cloud Controller如何选择Service Gateway的题问。
处置案方:
Cloud Controller关于某一label的service 请求,首先找到该label的Master Service Gateway,如果该Service Gateway的active属性为TRUE,则示表该Service Gateway存活状态为存活,可以接收请求;若active属性为FALSE,则示表该Service Gateway存活状态为不存活,则找到该label的Slave Service Gateway,若Slave Service Gateway的active属性为TRUE,则示表Slave Service Gateway可以接收请求,否则该类型的Master Slave Service Gateway都不可用,请求不会执行,用户被知告Service Gateway不可用。策决程流如下图:
3.3 Master/Slave Service Gateway之间服务信息的步同题问
在Cloud Foundry中Service Gateway的行运机制中,经已分析了provision和bind的功能,在这两个过程当中,都触及了一个内存空间(体具代码为@prov_svcs),这个内存空间用来寄存这个service类型的service信息。Service Gateway启动的时候会通过fetch_handles法方得获部全的信息,另外在每次经过这个Service Gateway的provision和bind等请求时,会有响应的信息更新。
那如果用使Master/Slave Service Gateway机制的话,为什么要斟酌两个Service Gateway之间@prov_svcs的步同信息呢?关于这个题问,可以测推:要证保Master/Slave Service Gateway的高可用性,那么在一个Service Gateway宕机的时候,另一个Service Gateway仍然可以任务,并接管当前的请求。但是,如果一个请求通过Master Service Gateway 功成provision 一个服务实例后,Master Service Gateway宕机了,那么关于这个服务实例的bind请求,定肯会通过Slave Service Gateway来实现,然而Slave Service Gateway不有具这个服务实例的任何信息,故bind失败。毫无疑问,Master/Slave Service Gateway机制必须处置服务信息的步同题问,也就是在一个Service Gateway实现某一个请求,更新@prov_svcs后,必须将雷同的更新知告另一个Service Gateway,实现信息的步同。
处置案方:
从Service Gateway的请求程流来看,关于service instance的信息在@prov_svcs中更新后,都市存储到Cloud Controller的postgres数据库中。为了做到Master/Slave Service Gateway的服务信息步同,最效有的法方就是一有信息被更新到Cloud Controller的postgres数据库中,就马上把这个更新信息发送给另一个Service Gateway。为了简单起见,本文采用的步同式方是:Service Gateway以一个可以人为设定的率频向Cloud Controller发送得获服务信息的请求。这样的话,从必定水平上说,可以证保两个Service Gateway服务信息的步同。
体具现实:
在上文的Service Gateway启动的时候,经已述讲过,Service Gateway会用使fetch_handles法方来得获服务信息,体具代码见asynchronous_service_gateway.rb:
update_callback = Proc.new do |resp|
@provisioner.update_handles(resp.handles)
@handle_fetched = true
event_machine.cancel_timer(@fetch_handle_timer)
# TODO remove it when we finish the migration
current_version = @version_aliases && @version_aliases[:current]
if current_version
@provisioner.update_version_info(current_version)
else
@logger.info("No current version alias is supplied, skip update version in CCDB.")
end
end
@fetch_handle_timer = event_machine.add_periodic_timer(@handle_fetch_interval) { fetch_handles(&update_callback) }
event_machine.next_tick { fetch_handles(&update_callback) }
从代码中可以看到Service Gateway是首先是通过一个周期性的timer向Cloud Controller发送得获请求,当收到Cloud Controller的响应当前,取消了这个timer。在Master/Slave Service Gateway 中为了不断地发送fetch_handles请求,只需要将代码event_machine.cancel_timer(@fetch_handle_timer)注释失落可即。这样的话,Service Gateway就会以周期@handle_fetch_interval发送fetch_handles请求。只要Cloud Controller关于service的信息有动变,Service Gateway就会在@handle_fetch_interval时间内获知。在此基础上,修改以上代码只是现实周期性发送请求,而Service Gateway在受接周期性响应后,还需要在处置的时候作出响应的修改,体具代码在provision.rb中,可以每次执行的时候都将@prov_svcs置空,然后再将有所的服务信息放入hash对象@prov_svcs。
关于该题问的处置,以上只是述阐了Service Gateway需要作的修改,这括包Service Gateway发送请和求受接请求,但是只有这些还是不敷的,对于通信的Server端,Cloud Controller也需要作必定的修改,要主是如何根据Service Gateway的请求,读取postgres数据库中有所的服务信息。代码址地要主为cloudfoundry/cloud_controller/cloud_controller/app/controllers/service_controller.rb的list_handles法方。由于Cloud Controller都是通过Service Gateway的URL信息去寻觅数据库中数据表service_bindings和service_configs的关于该Service Gateway的有所service instance,而当初是Master/Slave Service Gateway机制,需要将两个Service Gateway的服务信息部全信息找出,并回返给Service Gateway。比如:service instance A是由 Master Service Gateway来provision或者bind的,那么在service_configs或者service_bindings中是属于Master Service Gateway的,因此Slave Service Gateway在得获handles的时候,也需要将Master Service Gateway掏出,并回返给Slave Service Gateway。其中的体具现实可以参考Rails中的model,在这里service_binding blongs_to :service_config,service_config belongs _to :service。
3.4 unprovison, bind和unbind等请求的分部修改
关于这分部的修改,以unprovision请求为例:
Cloud Controller在收到用户关于某service instance的unprovision后,首先会从service_configs数据表中找出这个service instance,然后再掏出Service Gateway的URL信息,并向这个URL发送unprovision请求。但是如果当初这个Service Gateway经已宕机的话,之前的机制将不能响应这个请求。如果要在Master/Slave Service Gateway机制中处置这个题问,只需要在每次执行unprovision请求的时候,不是去找service instance的Service Gateway信息,而是去寻觅前当正在任务的Service Gateway 来实现unprovision任务。
关于bind和unbind操纵,也是如此,在Cloud Controller向Service Gateway发送请求的时候,不是通过service instance来寻觅Service Gateway,而是通过前当存活的Service Gateway来寻觅。
4. 评价
以上关于Master/Slave Service Gateway计设与现实,经已述阐终了,当初可以在评价这个机制。
首先从可用性手入,该机制很好的处置了之前Cloud Foundry中Service Gateway的单点故障题问,一旦Cloud Foundry中的一个Service Gateway宕机的话,该机制下,Cloud Foundry仍然可以用使另一个Service Gateway来实现任务。当然,当两个Service Gateway都宕机的况情下,该机制也不能常正证保Service的任务,但是在两个Service Gateway雷同境环下,现出这类况情的概率要远远低于只有一个Service Gateway的时候。
Master/Slave Service Gateway机制最要重的分部要主是如何现实service信息的步同题问,本计设要主是通过周期性的发送得获请求,来现实终最的步同。但是周期性的请求,其实不能谨严的证保consistency。如果关于一个service instance的porvision和bind操纵在一个周期内需要实现,而在两个请求之间的某个刻时,Master Service Gateway宕机的话,Slave Service Gateway也不可用。当这个周期非常粗粒度的时候,这样的题问是不能容忍的,但是如果这个周期比拟细粒度的话,题问能失掉非常好的解缓,这样的况情几乎可以忽略不计。但是当周期性的请求粒度很细的话,势必会形成Cloud Controller的通信的挤拥,这也是一个在请求很多,系统很大的时候不得不斟酌的题问。
5. 总结
本文要主旨在处置先原Cloud Foundry中关于Service Gateway的单点故障题问。在扼要分析Service Gateway的行运程流后,述讲了Service Gateway可能存在的单点故障题问,并对于该题问提出了两种处置案方。随后,本文大篇幅分析了其中一个处置案方Master/Slave Service Gateway机制,要主括包该案方的体具处置的题问和体具现实。最后,对于该机制停止了扼要的评价,要主着眼于可用性与对系统的性能影响。
转载清注明出处。
这篇文档更多出于我本人的理解,定肯在一些方地存在足不和错误。望希本文可以对开始接触Cloud Foundry中service的人有些帮助,如果你对这方面感兴趣,并有更好的法想和议建,也请联系我。
我的邮箱:shlallen@zju.edu.cn
新浪微博:@莲子弗如清
文章结束给大家分享下程序员的一些笑话语录: 打赌
飞机上,一位工程师和一位程序员坐在一起。程序员问工程师是否乐意和他一起玩一种有趣的游戏。工程师想睡觉,于是他很有礼貌地拒绝了,转身要睡觉。程序员坚持要玩并解释说这是一个非常有趣的游戏:"我问你一个问题,如果你不知道答案,我付你5美元。然后你问我一个问题,如果我答不上来,我付你5美元。"然而,工程师又很有礼貌地拒绝了,又要去睡觉。 程序员这时有些着急了,他说:"好吧,如果你不知道答案,你付5美元;如果我不知道答案,我付50美元。"果然,这的确起了作用,工程师答应了。程序员就问:"从地球到月球有多远?"工程师一句话也没有说,给了程序员5美元。 现在轮到工程师了,他问程序员:"什么上山时有三条腿,下山却有四条腿?"程序员很吃惊地看着工程师,拿出他的便携式电脑,查找里面的资料,过了半个小时,他叫醒工程师并给了工程师50美元。工程师很礼貌地接过钱又要去睡觉。程序员有些恼怒,问:"那么答案是什么呢?"工程师什么也没有说,掏出钱包,拿出5美元给程序员,转身就去睡觉了。