《架构师36项修炼》分布式系统搭建 -- 网络篇

概述

随着访问量的上升,web 系统的压力越来越大,在这个过程中,面临很多问题

而在网络层面上,由于数据暴增,单服务器开始疲于应对海量用户访问,就需要搭建负载均衡系统,让分布式集群分担压力

所谓的负载均衡,就是让服务器集群分配工作任务,起到保护 web 服务器的作用

 

而负载均衡的策略很多,主要有以下几个:

 

HTTP 重定向

网页通过 301、302 返回包含 Location 的请求包头,让浏览器再次发起请求,访问新的 URL,通过重定向,实现了负载均衡的效果

例如,当我们下载 PHP 源码包的时候,点击下载链接,会被重定向到离我们最近的 URL 下载地址进行下载

 

但是由于这个方案的每次访问实际进行了两次访问,增加了网络延时,降低了用户体验,同时,在大规模访问的情况下,也会出现性能不佳

 

反向代理负载均衡

《架构师36项修炼》分布式系统搭建 -- 网络篇

 

nginx 作为一种常见的反向代理服务器,在负载均衡中常常会被使用

反向代理服务器的核心任务是转发 HTTP 请求,扮演了服务器与用户数据中转的角色

由于反向代理服务器是在应用层工作,是 OSI 网络七层结构中的第七层,所以也被称为“七层负载均衡”

当然,除 nginx 外,可以做反向代理的软件还有很多,但 nginx 可以灵活制定转发策略,分配服务器流量的权重

 

但是,由于每台服务器单独存储了用户的 session 数据,无法保证登录用户能够找到 session,而导致重复登录的现象

有下面两种解决方案:

 

  1. 配置转发规则,让同一个用户的请求一定使用同一台服务器处理,但是这样的规则不仅无法实现严格的负载均衡,对代理服务器来说也具有很大的负担
  2. 将 session 等信息保存在某个独立服务来存储,如使用 redis、memcache 等,该方案较为常用

 

IP 负载均衡

由于 IP 负载均衡工作在网络层和传输层,所以也被称为“四层负载均衡”

相比于工作在应用层的反向代理负载均衡,其工作性能要高很多

 

IP 负载均衡对 IP 层数据包的 IP 地址和端口信息进行修改,以便让请求定位到具体的某个服务器 IP,实现重定向和负载均衡的目的

这种负载均衡最常见的实现方式就是 LVS (Linux Virtual Server),意即“Linux 虚拟服务”,通过 IPVS 实现

《架构师36项修炼》分布式系统搭建 -- 网络篇

 

 

负载均衡服务器收到 IP 包后,会修改 IP 包的目标 IP 地址和端口,然后原封不动的投递到内部网络中,最终流入到实际的 web 服务器

当实际 web 服务器处理完请求后,负载均衡服务器又会将 IP 包中的 IP 地址和端口修改为用户 IP 地址,最终返回客户端

 

上述的方式叫 LVS-NAT,除此之外,还有LVS-RD(直接路由),LVS-TUN(IP 隧道),三者之间都属于 LVS 的方式

 

IP 负载均衡的性能要高出Nginx的反向代理很多,它只处理到传输层为止的数据包,并不做进一步的组包,然后直接转发给实际服务器

但是它的配置和搭建比较复杂

 

DNS 负载均衡

DNS 服务器即内容分发服务器,他存储了 IP 地址与域名的对应关系,它可以使用 GSLB(全局负载均衡)实现负载均衡

DNS 服务器将一个域名映射到多个 IP,GSLB 根据 DNS 服务器的 IP 返回一个距离请求者最近的 IP 地址

这种方式不仅性能很好,而且可以配置多种策略

 

类似的,也应用在 CDN 实现的负载均衡:

CDN 在 Web 系统中,一般情况下是用来解决大小较大的静态资源(html/Js/Css/图片等)的加载问题,让这些比较依赖网络下载的内容,尽可能离用户更近,可以很大程度的提升用户体验

但是,搭建和维护成本非常高。互联网一线公司,会自建CDN服务,中小型公司一般使用第三方提供的CDN

 

具体使用场景

一般来说,具体的方案选择可以遵循:

负载均衡方案的选择
日访问量 方案选择
百万以下 单机优化数据库
百万到千万 nginx 负载均衡,mysql 读写分离
千万以上 lvs,使用 nosql
亿级 异地部署,多种方案结合