网站伸缩性架构

网站伸缩性架构

京东在2011年年末的图书促销活动中，由于优惠幅度大引得大量买家访问，结果导致网站服务不可用，大部分用户在提交订单后，页面显示“service is too busy”。当天晚上，京东老板刘强东在微博上发布消息称，已购买多台服务器以增加交易处理能力，第二天继续促销一天。结果第二天，用户在提交订单后，页面继续是“service is too busy”。显然京东当时的系统伸缩能力较弱，特别是订单处理子系统几乎没有什么伸缩能力。

一． 网站架构的伸缩性设计

回顾网站架构发展历程，网站机构发展史就是一部不断向网站添加服务器的历史。一般说来，网站的伸缩性设计分为两类，一类是根据功能进行物理分离实现伸缩，一类是单一功能通过集群实现伸缩。

1.不同功能进行物理分离实现伸缩

 

单一服务器处理所有业务，到数据库分离，缓存分离，静态资源分离，甚至把一个系统拆分成前台、后台、sso等，不同服务器部署不同的服务，提供不同的功能。

 

2.单一功能通过集群规模实现伸缩

随着网站访问量的逐步增加，单一的服务器也不能满足业务规模的要求，因此需要多个服务器构成一个集群整体对外提供服务。

二． 应用服务器集群的伸缩性设计

如果HTTP请求分发装置（负载均衡服务器）可以感知或者可以配置集群的服务器数量，可以及时发现集群中新上线或下线的服务器，并能向新上线的服务器分发请求，停止向已下线的服务器分发请求，那么就实现了应用服务器集群的伸缩性。

负载均衡是网站必不可少的基础技术手段，不但可以实现网站的伸缩性，同时还改善网站的可用性。具体的技术实现也多种多样，分为一下几种。

1.HTTP重定向负载均衡

 

1)         DNS服务器配置HTTP重定向负载均衡服务器

2)         用户访问HTTP重定向负载均衡服务器

3)         HTTP重定向负载均衡服务器根据负载均衡算法获得一台实际物理服务器的地址，构成一个包含实际物理服务器地址的重定向响应返回给浏览器

4)         浏览器自动重新请求实际物理服务器，然后返回给浏览器

缺点：浏览器需要两次请求服务器才能完成一次访问

2.DNS域名解析负载均衡

 

DNS配置多个记录，每次请求DNS服务器根据负载均衡算法得到一个实际IP地址，然后返回给浏览器，将负载均衡的工作转交给了DNS，省掉了网络管理维护负载均衡服务器的麻烦。

缺点：目前的DNS是多级解析，每一级DNS都可能缓存A记录，当下线某台服务器后，即使修改了DNS的记录，要使其生效也需要较长时间，这段时间，DNS    依然会将域名解析到已下线的服务器，导致用户访问失败；而且DNS负载均衡的控制权在域名服务商哪里，网站无法对其做更多的改善和更强大的管理。

 

3.反向代理负载均衡

 

优点：部署简单

缺点：反向代理服务器是所有请求和响应的中转站，其性能可能会成为瓶颈。

4.IP负载均衡

 

优点：IP负载均衡在内核进程完成数据分发，较反向代理服务器有更好的处理性能。

缺点：同样所有请求都要经过IP负载均衡服务器，对于下载服务和视频服务等难以满足大吞吐量的需求。

5.数据链路层负载均衡

 

数据链路层负载均衡（也称作三角传输模式）是值通信协议的数据链路层修改max地址进行负载均衡。负载均衡数据分发过程中不修改IP地址，只修改目的mac地址，通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP地址一致，从而大到不修改数据包的源地址和目的地址就可以进行数据分发的目的。

三角传输模式的链路层负载均衡是目前大型网站使用最广的一种负载均衡手段。在Linux平台上最好的链路层负载均衡开源产品是LVS。

6.负载均衡算法

1)         轮询

2)         加权轮询

3)         随机/加权随机

4)         最少连接/加权最少连接

5)         源地址散列

源地址散列：是根据请求来源的IP地址进行hash计算，得到应用服务器，这样来自同一个IP地址的请求总在同一个服务器上处理，该请求的上下文信息可以存储在这台服务器上，在一个会话周期内重复使用，从而实现会话粘滞。

 

三． 分布式缓存集群的伸缩性设计

分布式缓存服务器集群中不同服务器中缓存的数据各不相同，缓存访问请求不可以在缓存服务器集群中的任意一台处理，必须先找到缓存有需要数据的服务器，然后才能访问。新加入集群的服务器没有缓存任何数据，而已下线的缓存服务器还缓存着网站的许多热点数据。

1.Memcached分布式缓存集群的访问模型

 

1)         应用程序输入需要写缓存的数据，API将key输入路由算法模块

2)         路由算法根据key和Memcached集群服务器列表计算得到一台服务编号，进而得到该机器的IP地址和端口。

3)         API调用通信模块和集群中的某一台服务器，将数据存入缓存服务器。

2.Memcached分布式缓存集群的伸缩性挑战

路由算法之余数hash：缓存数据key的hash值除以memchched服务器数的余数作为编号，数据保存在相应编号的缓存服务器上。由于hashcode具有随机性，所以可以保证缓存数据均匀的分布在缓存服务器。

如果使用余数hash算法，加服务器的时候，困难出现了，大半读取缓存操作不会命中。一种解决方式是在网站访问量最少的时候扩容缓存服务器集群，然后通过模拟请求的方法逐渐预热缓存，使缓存服务器中的数据重新分布。

能不能通过改进路由算法，使得新加入的服务器不影响大部分缓存数据的正确命中呢？目前比较流行的算法是一致性Hash算法。

3.分布式缓存的一致性Hash算法

 

1)         先构造一个长度为0~2³²的整体环（hush环）

2)         根据节点名称的hash值将缓存服务器节点防止在这个Hash环上。

3)         根据根据需要缓存的数据的key值计算得到其hash值，然后在hush环上顺时针查找最近的服务器节点。

 

四．数据存储服务器集群的伸缩行设计

 

1.关系数据库集群的伸缩性设计

1)         根据业务的不同，把不同业务的表部署在不同服务器上，即数据分库

2)         主从读写分离，主数据库负责写入和修改数据，从数据库负责读操作。

3)         数据库分片，单表数据非常大的表，比如用户表、商机表等，需要进行数据分片，将一张表拆开分别存储在多个数据库中。

目前比较成熟的支持数据分片的分布式关系数据库产品主要有开源的Amoeba和Cobar。

2.NoSQL数据库的伸缩性设计

 

 

五．小结