《大型网站技术架构》——第六章 永无止境:网站的伸缩性架构

网站的伸缩性是指不需要改变网站的软硬件设计,仅仅通过改变部署的服务器数量就可以扩大或者缩小网站的服务处理能力。

大型网站:

  • 大量用户,大量访问
  • 功能庞杂,产品众多
  • 网站需要部署大量的服务器

大型网站的渐进式演化过程

网站架构的伸缩性设计

1根据功能进行物理分离实现伸缩
单一服务器处理所有服务
数据库从应用服务器分离
缓存从应用服务器分离
静态资源从应用服务器分离

  • 纵向分离(分层后分离),如 网站具体产品、可复用业务服务、基础技术服务、数据库
  • 横向分离,将不同的业务模块分离部署

2单一功能通过集群实现伸缩
集群伸缩性可分为应用服务器集群伸缩性和数据服务器集群伸缩性
数据服务器集群伸缩性也可分为缓存数据服务器集群和存储数据服务器集群

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

应用服务器应该设计成无状态
负载均衡服务器:HTTP请求分发装置,可以感知和配置集群的服务器数量

1HTTP重定向负载均衡

一台普通的应用服务器,唯一的功能是根据用户请求计算一台真实的Web服务器地址,写入HTTP重定向响应中返回给用户。
优点:简单
缺点:
浏览器需要两次请求才能完成一次访问,性能较差
重定向服务器自身的处理能力有可能成为瓶颈,集群伸缩性规模有限
HTTP302响应码重定向,有可能使搜索引擎判断为SEO作弊,降低搜索排名

2DNS域名解析负载均衡

在DNS服务器中配置多个A记录。每次域名解析请求都会根据负载均衡算法计算一个不同的IP地址返回。
优点:
将负载均衡的工作转交给DNS,省掉了网站管理维护负载均衡服务器的麻烦。
同时许多DNS还支持基于地理位置的域名解析,将域名解析成距离用户最近的一个服务器地址,加快用户访问速度,改善性能。
缺点:
DNS多级解析,每一级都可能缓存A记录,修改A记录等待生效需要较长时间。
DNS负载均衡的控制权在域名服务商,网站无法对其做更多改善和更强大的管理。
大型网站总是部分使用DNS域名解析,利用它作为第一级负载均衡手段。

3反向代理负载均衡

反向代理服务器处于Web服务器前面,可同时提供负载均衡和缓存资源的功能。
请求通过反向代理服务器转发,响应也通过反向代理服务器返回。
Web服务器不直接对外提供访问,因此不需要使用外部IP地址,而反向代理服务器则需要配置双网卡和内部外部两套IP地址。
优点:和反向代理服务器功能集成在一起,部署简单
缺点:反向代理服务器是所有请求和响应的中转站,其性能可能会成为瓶颈

4IP负载均衡

负载均衡服务器在操作系统内核进程获取网络数据包,将数据目的IP修改为一台真实Web服务器,而不需要通过用户进程处理。
IP负载均衡在内核进程完成数据分发,比反向代理负载均衡(在应用程序中分发数据)有更好的处理性能。但是由于所有请求响应都需要经过负载均衡服务器,集群的最大响应数据吞吐量受制于负载均衡服务器网卡带宽

5数据链路层负载均衡

在通信协议的数据链路层修改mac地址进行负载均衡。
三角传输模式。
负载均衡数据分发过程中不修改IP地址,只修改mac地址,通过配置真实物理服务器集群所有及其虚拟IP和负载均衡服务器IP地址一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的。
响应直接返回给用户浏览器,不需要通过负载均衡服务器。
目前大型网站使用最广的一种负载均衡手段。

扫描二维码关注公众号,回复: 4535978 查看本文章

负载均衡算法:

  • 轮询
  • 加权轮询
  • 随机或者加权随机
  • 最少连接:记录每个应用服务器正在处理的连接数,将新的请求分发到最少连接的服务器上。
  • 源地址散列:根据请求来源的IP地址进行Hash计算,得到应用服务器。会话黏滞。

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

主要目标:使集群中已经缓存的数据尽可能还被访问到

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

路由算法负责根据应用程序输入的key计算得到应该将数据写入哪台服务器或者从那台服务器读取。
简单的Hash算法在扩容时导致的缓存不能命中问题
分布式缓存的一致性Hash算法:Hash环
使用虚拟节点的一致性Hash环
在实践中,一台物理服务器虚拟为150个(经验值)虚拟服务器节点。

数据存储服务器集群的伸缩性设计

和缓存服务器集群的伸缩性设计不同,数据存储服务器集群的伸缩性对数据的持久性可用性提出了更高的要求。
缓存的目的是加速数据读取的速度并减轻数据存储服务器的负载压力,因此部分缓存数据的丢失不影响业务的正常处理,因为数据还可以从数据库等存储服务器上获取。
而数据存储服务器必须保证数据的可靠存储,任何情况下都必须保证数据的可用性和正确性。

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

MySQL集群伸缩性方案

  • 数据库主从读写分离:写操作都在主服务器上,由主服务器将数据同步到集群中其他从服务器,数据读操作及数据分析等离线操作在从服务器上进行。
  • 业务分割:不同业务数据表部署在不同的数据库集群
  • 分片:单表数据很大的

支持数据分片的Cobar
Cobar部署模型(图)
Cobar系统组件模型(图)
Cobar集群伸缩原理(图)
实践中,Cobar利用了MySQL的数据同步功能进行数据迁移。以Schema为单位。
无法执行夸库的JOIN操作,更不能执行跨库的事务处理。必须从业务上回避分布式关系数据库的各种缺点:避免事务或利用事务补偿机制代替数据库事务;分解数据访问逻辑避免JOIN操作等。

NoSQL数据库的伸缩性设计

业务对象贫血模型与充血模型?
NoSQL,主要指非关系的、分布式的数据库设计模式。
一般而言,NoSQL数据库产品都放弃了关系数据库的两大重要基础:以关系代数为基础的结构化查询语言(SQL)和事务一致性保证(ACID)。而强化其他一些大型网站更关注的特性:高可用性和可伸缩性。
HBase
HBase架构(图)
HRegionSever是物理服务器,每个HRegionSever上可以启动多个HRegion实例。
HMaster服务器

高手定律:这个世界只有遇不到的问题,没有解决不了的问题。

猜你喜欢

转载自blog.csdn.net/wsjtwmy/article/details/85029842