etcd 是 CoreOS 团队发起的开源项目,是一个管理配置信息和服务发现(service discovery)的项目,它的目标是构建一个高可用的分布式键值(key-value)数据库,基于 Go 语言实现。
特点:
简单:支持 REST 风格的 HTTP+JSON API
安全:支持 HTTPS 方式的访问
快速:支持并发 1k/s 的写操作
可靠:支持分布式结构,基于 Raft 的一致性算法,Raft 是一套通过选举主节点来实现分布式系统一致性的算法。
etcd基于其优秀的特点,可广泛的应用于以下场景:
服务发现(Service Discovery):服务发现主要解决在同一个分布式集群中的进程或服务,要如何才能找到对方并建立连接。本质上来说,服务发现就是想要了解集群中是否有进程在监听udp或tcp端口,并且通过名字就可以查找和连接。
消息发布与订阅:在分布式系统中,最适用的一种组件间通信方式就是消息发布与订阅。即构建一个配置共享中心,数据提供者在这个配置中心发布消息,而消息使用者则订阅他们关心的主题,一旦主题有消息发布,就会实时通知订阅者。通过这种方式可以做到分布式系统配置的集中式管理与动态更新。应用中用到的一些配置信息放到etcd上进行集中管理。
负载均衡:在分布式系统中,为了保证服务的高可用以及数据的一致性,通常都会把数据和服务部署多份,以此达到对等服务,即使其中的某一个服务失效了,也不影响使用。etcd本身分布式架构存储的信息访问支持负载均衡。etcd集群化以后,每个etcd的核心节点都可以处理用户的请求。所以,把数据量小但是访问频繁的消息数据直接存储到etcd中也可以实现负载均衡的效果。
分布式通知与协调:与消息发布和订阅类似,都用到了etcd中的Watcher机制,通过注册与异步通知机制,实现分布式环境下不同系统之间的通知与协调,从而对数据变更做到实时处理。
分布式锁:因为etcd使用Raft算法保持了数据的强一致性,某次操作存储到集群中的值必然是全局一致的,所以很容易实现分布式锁。锁服务有两种使用方式,一是保持独占,二是控制时序。
集群监控与Leader竞选:通过etcd来进行监控实现起来非常简单并且实时性强。
HAProxy是可提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,是免费、快速并且可靠的一种解决方案。HAProxy非常适用于并发大(并发达1w以上)web站点,这些站点通常又需要会话保持或七层处理。HAProxy的运行模式使得它可以很简单安全的整合至当前的架构中,同时可以保护web服务器不被暴露到网络上。
HAProxy的主要特性有:
可靠性和稳定性非常好,可以与硬件级的F5负载均衡设备相媲美;
最高可以同时维护40000-50000个并发连接,单位时间内处理的最大请求数为20000个,最大处理能力可达10Git/s;
支持多达8种负载均衡算法,同时也支持会话保持;
支持虚机主机功能,从而实现web负载均衡更加灵活;
支持连接拒绝、全透明代理等独特的功能;
拥有强大的ACL支持,用于访问控制;
其独特的弹性二叉树数据结构,使数据结构的复杂性上升到了0(1),即数据的查寻速度不会随着数据条目的增加而速度有所下降;
支持客户端的keepalive功能,减少客户端与haproxy的多次三次握手导致资源浪费,让多个请求在一个tcp连接中完成;
支持TCP加速,零复制功能,类似于mmap机制;
支持响应池(response buffering);
支持RDP协议;
基于源的粘性,类似nginx的ip_hash功能,把来自同一客户端的请求在一定时间内始终调度到上游的同一服务器;
更好统计数据接口,其web接口显示后端集群中各个服务器的接收、发送、拒绝、错误等数据的统计信息;
详细的健康状态检测,web接口中有关于对上游服务器的健康检测状态,并提供了一定的管理功能;
基于流量的健康评估机制;
基于http认证;
基于命令行的管理接口;
日志分析器,可对日志进行分析。
HAProxy负载均衡策略非常多,常见的有如下8种:
roundrobin:表示简单的轮询。
static-rr:表示根据权重。
leastconn:表示最少连接者先处理。
source:表示根据请求的源IP,类似Nginx的IP_hash机制。
ri:表示根据请求的URI。
rl_param:表示根据HTTP请求头来锁定每一次HTTP请求。
rdp-cookie(name):表示根据据cookie(name)来锁定并哈希每一次TCP请求。
四层负载均衡器也称为4层交换机,主要通过分析IP层及TCP/UDP层的流量实现基于IP加端口的负载均衡,如常见的LVS、F5等;
七层负载均衡器也称为7层交换机,位于OSI的最高层,即应用层,此负载均衡器支持多种协议,如HTTP、FTP、SMTP等。7层负载均衡器可根据报文内容,配合一定的负载均衡算法来选择后端服务器,即“内容交换器”。如常见的HAProxy、Nginx。
相同:三者都是软件负载均衡产品。
区别:
LVS基于Linux操作系统实现软负载均衡,而HAProxy和Nginx是基于第三方应用实现的软负载均衡;
LVS是可实现4层的IP负载均衡技术,无法实现基于目录、URL的转发。而HAProxy和Nginx都可以实现4层和7层技术,HAProxy可提供TCP和HTTP应用的负载均衡综合解决方案;
LVS因为工作在ISO模型的第四层,其状态监测功能单一,而HAProxy在状监测方面功能更丰富、强大,可支持端口、URL、脚本等多种状态检测方式;
HAProxy功能强大,但整体性能低于4层模式的LVS负载均衡。
Nginx主要用于Web服务器或缓存服务器。
Heartbeat是Linux-HA项目中的一个组件,它提供了心跳检测和资源接管、集群中服务的监测、失效切换等功能。heartbeat最核心的功能包括两个部分,心跳监测和资源接管。心跳监测可以通过网络链路和串口进行,而且支持冗余链路,它们之间相互发送报文来告诉对方自己当前的状态,如果在指定的时间内未收到对方发送的报文,那么就认为对方失效,这时需启动资源接管模块来接管运行在对方主机上的资源或者服务。
Keepalived 是一个基于VRRP协议来实现的LVS服务高可用方案,可以解决静态路由出现的单点故障问题。
在一个LVS服务集群中通常有主服务器(MASTER)和备份服务器(BACKUP)两种角色的服务器,但是对外表现为一个虚拟IP,主服务器会发送VRRP通告信息给备份服务器,当备份服务器收不到VRRP消息的时候,即主服务器异常的时候,备份服务器就会接管虚拟IP,继续提供服务,从而保证了高可用性。
keepalived体系架构中主要有三个模块,分别是core、check和vrrp。
core模块为keepalived的核心,负责主进程的启动、维护及全局配置文件的加载和解析。
vrrp模块是来实现VRRP协议的。
check模块负责健康检查,常见的方式有端口检查及URL检查。
Keepalived工作在TCP/IP模型的第三、四和五层,即网络层、传输层和应用层。
网络层,Keepalived采用ICMP协议向服务器集群中的每个节点发送一个ICMP的数据包,如果某个节点没有返回响应数据包,则认为此节点发生了故障,Keepalived将报告次节点失效,并从服务器集群中剔除故障节点。
传输层,Keepalived利用TCP的端口连接和扫描技术来判断集群节点是否正常。如常见的web服务默认端口80,ssh默认端口22等。Keepalived一旦在传输层探测到相应端口没用响应数据返回,则认为此端口发生异常,从而将此端口对应的节点从服务器集群中剔除。
应用层,可以运行FTP、telnet、smtp、dns等各种不同类型的高层协议,Keepalived的运行方式也更加全面化和复杂化,用户可以通过自定义Keepalived的工作方式,来设定监测各种程序或服务是否正常,若监测结果与设定的正常结果不一致,将此服务对应的节点从服务器集群中剔除。
Keepalived通过完整的健康检查机制,保证集群中的所有节点均有效从而实现高可用。
LVS是linux virtual server的简写linux虚拟服务器,是一个虚拟的服务器集群系统,可以在unix/linux平台下实现负载均衡集群功能。
LVS的主要作用是:通过LVS提供的负载均衡技术实现一个高性能、高可用的服务器群集。因此LVS主要可以实现:
把单台计算机无法承受的大规模的并发访问或数据流量分担到多台节点设备上分别处理,减少用户等待响应的时间,提升用户体验。
单个重负载的运算分担到多台节点设备上做并行处理,每个节点设备处理结束后,将结果汇总,返回给用户,系统处理能力得到大幅度提高。
7*24小时的服务保证,任意一个或多个设备节点设备宕机,不能影响到业务。在负载均衡集群中,所有计算机节点都应该提供相同的服务,集群负载均衡获取所有对该服务的如站请求。
LVS 有三种负载均衡的模式,分别是VS/NAT(nat 模式)、VS/DR(路由模式)、VS/TUN(隧道模式)。
NAT模式(VS-NAT)
原理:首先负载均衡器接收到客户的请求数据包时,根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后负载均衡器就把客户端发送的请求数据包的目标IP地址及端口改成后端真实服务器的IP地址(RIP)。真实服务器响应完请求后,查看默认路由,把响应后的数据包发送给负载均衡器,负载均衡器在接收到响应包后,把包的源地址改成虚拟地址(VIP)然后发送回给客户端。
优点:集群中的服务器可以使用任何支持TCP/IP的操作系统,只要负载均衡器有一个合法的IP地址。
缺点:扩展性有限,当服务器节点增长过多时,由于所有的请求和应答都需要经过负载均衡器,因此负载均衡器将成为整个系统的瓶颈。
IP隧道模式(VS-TUN)
原理:首先负载均衡器接收到客户的请求数据包时,根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后负载均衡器就把客户端发送的请求报文封装一层IP隧道(T-IP)转发到真实服务器(RS)。真实服务器响应完请求后,查看默认路由,把响应后的数据包直接发送给客户端,不需要经过负载均衡器。
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,也能处理很巨大的请求量。
缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持“IP Tunneling”。
直接路由模式(VS-DR)
原理:首先负载均衡器接收到客户的请求数据包时,根据调度算法决定将请求发送给哪个后端的真实服务器(RS)。然后负载均衡器就把客户端发送的请求数据包的目标MAC地址改成后端真实服务器的MAC地址(R-MAC)。真实服务器响应完请求后,查看默认路由,把响应后的数据包直接发送给客户端,不需要经过负载均衡器。
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户。所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,也能处理很巨大的请求量。
缺点:需要负载均衡器与真实服务器RS都有一块网卡连接到同一物理网段上,必须在同一个局域网环境。
LVS调度器用的调度方法基本分为两类:
固定调度算法:rr,wrr,dh,sh
rr:轮询算法,将请求依次分配给不同的rs节点,即RS节点中均摊分配。适合于RS所有节点处理性能接近的情况。
wrr:加权轮训调度,依据不同RS的权值分配任务。权值较高的RS将优先获得任务,并且分配到的连接数将比权值低的RS更多。相同权值的RS得到相同数目的连接数。
dh:目的地址哈希调度(destination hashing)以目的地址为关键字查找一个静态hash表来获得所需RS。
sh:源地址哈希调度(source hashing)以源地址为关键字查找一个静态hash表来获得需要的RS。
动态调度算法:wlc,lc,lblc,lblcr
wlc:加权最小连接数调度,假设各台RS的权值依次为Wi,当前tcp连接数依次为Ti,依次去Ti/Wi为最小的RS作为下一个分配的RS。
lc:最小连接数调度(least-connection),IPVS表存储了所有活动的连接。LB会比较将连接请求发送到当前连接最少的RS。
lblc:基于地址的最小连接数调度(locality-based least-connection):将来自同一个目的地址的请求分配给同一台RS,此时这台服务器是尚未满负荷的。否则就将这个请求分配给连接数最小的RS,并以它作为下一次分配的首先考虑。
Nginx的优点:
工作在网络的7层之上,可以针对http应用做一些分流的策略,比如针对域名、目录结构。Nginx正则规则比HAProxy更为强大和灵活。
Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,LVS对网络稳定性依赖比较大,稳定要求相对更高。
Nginx安装和配置、测试比较简单、方便,有清晰的日志用于排查和管理,LVS的配置、测试就要花比较长的时间了。
可以承担高负载压力且稳定,一般能支撑几万次的并发量,负载度比LVS相对小些。
Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等。
Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器。
Nginx作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,很多场景下都将其作为反向代理加速器。
Nginx作为静态网页和图片服务器,这方面的性能非常优秀,同时第三方模块也很多。
Nginx的缺点:
Nginx仅能支持http、https和Email协议,这样就在适用范围上面小些。
对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测。
不支持Session的直接保持,需要通过ip_hash来解决。
LVS的优点:
抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生。因此负载均衡软件里的性能最强的,对内存和cpu资源消耗比较低。
LVS工作稳定,因为其本身抗负载能力很强,自身有完整的双机热备方案。
无流量,LVS只分发请求,而流量并不从它本身出去,这点保证了均衡器IO的性能不会收到大流量的影响。
应用范围较广,因为LVS工作在4层,所以它几乎可对所有应用做负载均衡,包括http、数据库等。
LVS的缺点:
软件本身不支持正则表达式处理,不能做动静分离。相对来说,Nginx/HAProxy+Keepalived则具有明显的优势。
如果是网站应用比较庞大的话,LVS/DR+Keepalived实施起来就比较复杂了。相对来说,Nginx/HAProxy+Keepalived就简单多了。
HAProxy的优点:
HAProxy也是支持虚拟主机的。
HAProxy的优点能够补充Nginx的一些缺点,比如支持Session的保持,Cookie的引导,同时支持通过获取指定的url来检测后端服务器的状态。
HAProxy跟LVS类似,本身就只是一款负载均衡软件,单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的。
HAProxy支持TCP协议的负载均衡转发。
代理服务器是一个位于客户端和原始(资源)服务器之间的服务器,为了从原始服务器取得内容,客户端向代理服务器发送一个请求并指定目标原始服务器,然后代理服务器向原始服务器转交请求并将获得的内容返回给客户端。
其主要作用有:
资源获取:代替客户端实现从原始服务器的资源获取;
加速访问:代理服务器可能离原始服务器更近,从而起到一定的加速作用;
缓存作用:代理服务器保存从原始服务器所获取的资源,从而实现客户端快速的获取;
隐藏真实地址:代理服务器代替客户端去获取原始服务器资源,从而隐藏客户端真实信息。
RTO(Recovery Time Objective):RTO指服务恢复的时间,最佳的情况是 0,即服务立即恢复;最坏是无穷大,即服务永远无法恢复;
RPO(Recovery Point Objective):RPO 指指当灾难发生时允许丢失的数据量,0 意味着使用同步的数据,大于 0 意味着有数据丢失,如“RPO=1 d”指恢复时使用一天前的数据,那么一天之内的数据就丢失了。因此,恢复的最佳情况是 RTO = RPO = 0,几乎无法实现。
CAP理论指出了在分布式系统中需要满足的三个条件,主要包括:
Consistency(一致性):所有节点在同一时间具有相同的数据;
Availability(可用性):保证每个请求不管成功或者失败都有响应;
Partition tolerance(分区容错性):系统中任意信息的丢失或失败不影响系统的继续运行。
CAP 理论的核心是:一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求,最多只能同时较好的满足两个。
原子性(Atomicity):整体不可分割性,要么全做要不全不做;
一致性(Consistency):事务执行前、后数据库状态均一致;
隔离性(Isolation):在事务未提交前,它操作的数据,对其它用户不可见;
持久性 (Durable):一旦事务成功,将进行永久的变更,记录与redo日志。