网站的伸缩性是指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或缩小网站的服务处理能力。
网站的 伸缩性设计可分为两类,一类是根据功能进行物理分离实现伸缩,一类是单一功能通过集群实现伸缩。
纵向分离(分层后分离):将业务处理流程上的不同部分分离部署,实现系统伸缩性。
横向分离(业务分割后分离):将不同的业务模块分离部署,实现系统伸缩性。
将相同服务部署在多台服务器上构成一个集群整体对外提供服务。
集群伸缩性又可分为:应用服务器集群伸缩性、数据服务器集群伸缩性
数据服务器集群还可分为:缓存数据集群、存储数据服务器集群。
如果HTTP请求分发装置(负载均衡服务器)可以感知或者可以配置集群的服务器数量,可以及时法相集群中新上线或下线的服务器,并能向新上线的服务器分发请求,停止向已下线的服务器分发请求,那么就实现了应用服务器集群的伸缩性。
利用HTTP重定向实现负载均衡。HTTP重定向服务器结合负载均衡算法并根据用户的HTTP请求计算一台真实的Web服务器地址,并将该Web服务器地址写入HTTP重定向响应(状态吗302)中返回给用户浏览器。
缺点:
浏览器需要两次请求服务器才能完成一次访问,性能较差;
重定向服务器自身的处理能力有可能成为瓶颈,整个集群的伸缩性规模有限;
使用HTTP响应码重定向,有可能使搜索引擎判断为作弊,降低搜索排名。
在DNS服务器中配置多个Web服务器地址,根据负载均衡算法将域名解析为不同的Web服务器地址。
缺点:
DNS是多级解析,每一级DNS都可能缓存,当域名解析到已下线的服务器,会导致用户访问失败。
补充:
大型网站总是部分使用DNS域名解析,利用域名解析作为第一级负载均衡手段,即域名解析得到的一组服务器并不是实际提供Web服务的物理服务器,而是同样提供负载均衡服务的内部服务器,这组内部负载均衡服务器在进行负载均衡,将请求分发到真实的Web服务器上。
通常反向代理服务器同时提供负载均衡的功能。反向代理服务器配置双网卡和内部外部两套IP地址,反向代理服务器通过外部IP接收外部访问请求,并使用负载均衡算法转发给内部的Web服务器,Web服务器使用内部IP,处理完响应后通过反向代理服务器返回给用户。
缺点:
反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈。
在网络层通过修改请求目标地址进行负载均衡。
负载均衡服务器具有内部外部两套IP地址,负载均衡服务器在操作系统内核进程获取网络数据包,根据负载均衡算法计算得到一台真实Web服务器IP,然后将数据目的IP修改为该Web服务器IP。真实Web服务器处理完成后,相应数据包回到负载均衡服务器,负载均衡服务器再将数据包源地址修改为自身IP地址发送给用户浏览器。
真实物理Web服务器响应数据包如何返回给负载均衡服务器有两种手段:
(1)负载均衡服务器在修改目的IP地址的同时修改源地址,将数据包源地址设为自身IP——源地址转换(SNAT)
(2)将负载均衡服务器同时作为真实物理服务器集群的网关服务器
缺点:
负载均衡服务器可能成为性能瓶颈
在通信协议的数据链路层修改mac地址进行负载均衡
三角传输模式(直接路由方式DR):负载均衡数据分发过程中不修改IP地址,只修改目的mac地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致,从而达到不修改数据报的源地址和目的地址就可以进行数据分发的目的。由于实际处理请求的真实物理服务器IP和数据请求目的IP一致,不需要通过负载均衡服务器进行地址转换,可将响应数据包直接返回给用户浏览器,避免负载均衡服务器网卡带宽成为瓶颈。
补充:
数据链路层负载均衡是目前使用最广的一种负载均衡手段。Linux平台上最好的负载均衡开源产品是LVS(Linux Virtual Server)
负载均衡服务器的实现可以分为两部分:
(1)根据负载均衡算法和Web服务器列表计算得到集群中一台Web服务器的地址
(2)将请求数据发送到该地址对应的Web服务器上
负载均衡算法有:
所有请求被依次分发到每台应用服务器上,即每台服务器需要处理的请求数目都相同,适合于所有服务器硬件都相同的场景。
根据应用服务器硬件性能的情况,在轮询的基础上,按照配置的权重将请求分发到每个服务器,高性能的服务器能分配更多请求。
请求被随机分配到各个应用服务器。
记录每个应用服务器正在处理的连接数(请求数),将新到的请求分发到最少连接的服务器上。
根据请求来源的IP地址进行Hash计算,得到应用服务器,这样来自同一个IP地址的请求总在同一个服务器上处理,该请求的上下文信息可以保存在该服务器上。
分布式缓存集群伸缩性设计的主要目标:新加入缓存服务器后应使整个缓存服务器集群中已经缓存的数据尽可能还被访问到。
应用程序通过Memcached客户端访问Memcached服务器集群,Memcached客户端主要包括:一组API、Memcached服务器集群路由算法、Memcached服务器集群列表、通信模块。
简单的余数Hash路由算法在需要扩容时,会导致较高的命中失效率。一致性Hash算法能解决这个问题
一致性Hash算法通过一个叫作一致性Hash环的数据结构实现Key到缓存服务器的映射,其具体算法为:
先构造一个长度为2^32的整数环(一致性Hash环),根据节点名称的Hash值[0, 2^32-1]将缓存服务器节点放在这个Hash换上,然后根据需要缓存的数据的Key值计算得到其Hash值[0, 2^32-1],然后在Hash环顺时针序查找距离这个Key的Hash值最近的缓存服务器节点,完成Key到服务器的Hash映射查找。
问题:插入一个节点后会使得受影响的节点的压力减少一半,而另外的节点相对负载压力是两倍,如何解决?
解决:将每台物理缓存服务器虚拟为一组虚拟缓存服务器,将虚拟服务器的Hash值放置在Hash环上,Key在环上先找到虚拟服务器节点,在得到物理服务器信息。
数据存储服务器伸缩性设计可分为:关系数据库集群的伸缩性设计、NoSQL数据库的伸缩性设计。
架构:多态服务器部署MySQL,但是其角色有主从之分,数据写操作都在主服务器上,由主服务器将数据同步到集群中其他从服务器,数据读操作及数据分析等离线操作在从服务器上进行。
数据分库:不同业务数据表部署在不同的数据库集群上,制约条件是:跨库的表不能进行JOIN操作。
补充:目前支持数据分片的分布式关系数据库产品有:Amoeba、Cobar。
Cobar部署与原理:
Cobar是一个分布式关系数据库访问代理,介于应用服务器和数据库服务器之间。应用程序通过JDBC驱动访问Cobar集群,Cobar服务器很据SQL和分库规则分解SQL,分发到MysQL集群不同的数据库实例上执行。
Cobar的伸缩有两种:Cobar服务器集群的伸缩、MySQL服务器集群的伸缩
采用一致性Hash算法,以Schema为单位进行数据迁移,避免遍历数据库中每条记录。同步完成后,修改Cobar服务器的路由配置,将这些Schema的IP修改为新机器的IP,然后删除原机器中的相关Schema,完成MySQL集群扩容。
NoSQL:主要指非关系的、分布式的数据库设计模式;也可认为是Not Only SQL,表示NoSQL只是关系数据库的补充。NoSQL数据库产品都放弃了关系数据库的两大重要基础:以关系代数为基础的结构化查询语言(SQL)、事务一致性保证(ACID)。
NoSQL的代表是Apache HBase,其主要依赖:可分裂的HRegion、可伸缩的分布式文件系统HDFS实现。
HBase架构:数据以HRegion为单位进行管理,每个HRegion中存储一段Key值区间[key1, key2]的数据,而HRegion存储HRegionServer物理服务器上,每个HRegionServer上可以启动多个HRegion实例。当一个HRegion中写入的数据太多,达到配置的阈值时,HRegion会分裂成两个HRegion,并将HRegion在整个集群中进行迁移。所有的HRegion的信息(存储的Key值区间、所在HRegionServer地址、访问端口号等)都记录在HMaster服务器上。HBase可启动多个HMaster,并通过Zookeeper(一个分布式一致性的数据管理服务器)选择一个主服务器,应用程序通过Zookeeper获得主HMaster的地址。输入Key值获得Key所在的HRegionServer地址,然后请求HRegionServer上的HRegion,获得需要的数据。
【参考文献】大型网站技术架构核心原理与案例分析,李智慧,电子工业出版社