系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结,原内容公众号“成为架构师”。
目录
1 单机遗留问题
上一篇讨论了伪分布式与垂直拆分的问题
垂直拆分,解除了子系统耦合,但是对于同一个垂直站点子系统,仍然是一个“单体架构”
集群的实现,通常需要引入反向代理
2 反向代理,接入层扩容
用什么做反向代理
- 软件层面:nginx / apache
- 操作系统层面:LVS
- 硬件:F5
在这里我们只谈软件层面的,OS与硬件层面感兴趣的话可以百度或者Google,至于何为反向代理这里也不赘述了
反向代理解决了什么问题
- 子web系统性能,不再受到单台机器资源限制,可以扩展
- 子web系统,实现了高可用,伪集群变为真集群
反向代理带来了什么新问题
- 多个web节点,负载如何分配(负载均衡问题)
- 反向代理层,如何保证高可用(反向代理高可用问题)
3 反向代理,负载均衡
负载均衡方法:
- 随机,将请求random到web-server
- 轮询,按照web-server 1-n的顺序依次的分发请求
- 静态权重轮询,不同web-server之间的处理能力不同,性能好的权重大,会被转发更多的请求
- 动态权重轮询(后续讨论),权重分配是动态的,而不是一个固定值
- 一致性哈希(后续讨论),ip哈希之后落在hash环上,按照顺时针方向找到对应的真实服务器ip或者虚拟节点
负载均衡抓手(如何维护session状态一致性):
- 四层(转发/交换)
- 七层(转发/交换)
这来自于七层结构模型
第四层传输层:使用ip作为负载均衡的抓手
第七层应用层(在TCP/IP模型中为第五层):使用http请求中携带的参数作为负载均衡的抓手
4 反向代理,高可用
虚拟IP + keepalived方案:
公网IP虚拟化,nginx集群对外暴露的公网ip是一个虚拟ip,dns解析得到的是此虚拟ip
通过keepalived保证nginx的可用性,当其中一个nginx挂了,虚拟ip得到的请求会转到另一个可用的nginx上
但是这种stand by的方式会引入新的问题:利用率的问题,图中利用率只有50%,这将在后续进行讨论。
5 两个遗留问题
- 异构服务器的负载均衡,即前面的动态权重问题
- keepalived方案造成的其中一个nginx stand by利用率低下的问题
下一篇将介绍接入层的架构演进,如果nginx达到了流量上限应该怎么办?
上一篇回顾:【成为架构师2-2】伪分布式与垂直拆分:快速解决单机性能问题的实践方案
下一篇更精彩:【成为架构师2-4】反向代理与DNS轮询:接入层的架构演进