服务端程序依赖的基础软件不只是操作系统和编程语言, 还多了两类:
- 负载均衡
- 数据库或其他形式的存储(DB/Storage)
为什么需要负载均衡, 这篇文章会带你了解流量调度与负载均衡的那些事情
流量调度
几个常见的服务端程序运行实例(进程)相关的概念:
- 连接数: 并发数, 指的是同时在服务中的请求数, 也就是那些已经发送请求, 但是还没有收完应答的请求数量
- IOPS: 平均每秒完成的请求(一问一答)的数量. 它可以用来判断服务端程序的做事效率
- 流量, 入向流量和出向流量
- 入向流量, 平均每秒收到的请求包数量 * 请求包平均大小
- 出向流量, 平均每秒返回的应答包数量 * 应答包的平均大小
所谓流量调度, 就是把海量客户并发的请求包按特定策略分配到不同的服务端程序实例的过程
有很多手段可做流量调度
DNS流量调度
不足:
-
升级不便, DNS解析是有层层缓存, 通过调整 DNS解析来实现, 有极大的不确定性, 完成一个实例的升级周期特别长
-
流量调度不均衡, 域名解析做流量调度, 是非常粗糙的, 实际结果并不可控
那么, 怎么才能让流量调度能够做到真正均衡?
网络层负载均衡
第一种做法, 在网络层(IP)层做负载均衡 LVS(Linux Virtual Server) 工作原理
LVS支持三种调度模式:
- VS/NAT: 通过网络地址转换(NAT)技术做调度. 请求和相应都会经过调度器中转, 性能最差
- VS/TUN: 把请求报文通过IP隧道转发至真实服务器, 而真实服务器将响应直接返回给客户, 所以调度器之处理请求报文. 这种做法性能比 VS/NAT 好很多
- VS/DR: 通过改写请求报文的MAC地址, 将请求发送到真实服务器, 真实服务器将响应直接返回给客户. 这种做法相比 VS/TUN 少了IP隧道的开销, 性能最好
VS/DR技术
应用层负载均衡
应用层负载均衡, 有时候我们也把它叫做应用网关 HTTP协议是最广泛的应用层协议. 当前应用网关, 绝大多数是HTTP应用网关.
HTTP网关收到一个HTTP请求后, 根据一定调度算法把请求转发给真实的业务服务器实例RS(Real Server), 收到RS的应答后, 再把它转发给客户端.
整个过程的逻辑非常简单, 而且重试也非常好做. 若某个RS实例挂了后, HTTP网关可以将同一个HTTP请求重新发送给其他RS实例.
大部分HTTP请求不大, 直接在内存中存储即可, 保存代价不高. 但是文件上传型的请求, 由于请求包中包含文件内容, 可能就需要依赖临时文件或其他手段来保存HTTP请求.
优雅升级
有了负载均衡, 不只是可以实现了流量的均衡调度, 连带业务服务器的升级也会方便多了.
对于前端是LVS这种网络层负载均衡的场景, 升级的核心步骤伟:
- 升级系统通知LVS调度器(Director Server)下线要升级的业务服务器(Real Server)实例
- LVS调度器将该实例从RS集合中去除, 这样就不再调度新流量到它
- 升级系统通知要升级的RS实例退出
- 要升级的RS实例处理完所有处理中的请求, 然后主动退出
- 升级系统更新RS实例到新版本, 并重启
- 升级系统将RS实例重新加到RS集合参与调度
对于前端是HTTP应用层网络这种负载均衡的场景, 升级的过程可以更加简单:
- 升级系统通知要升级的业务服务器实例退出
- 将要升级的RS实例进入退出状态, 这时新请求进来直接拒绝(返回一个特殊的Status Code); 处理完所有处理中的请求后, RS实例主动退出
- 升级系统更新RS实例到新版本, 并重启
可以看出, 因HTTP应用网关支持重试, 业务服务器的升级过程就变得简单很多
此文章为3月Day3学习笔记, 内容来源于极客时间《许式伟的架构课》, 强烈推荐该课
