系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
问题引入：
- nginx是2012年才流行起来的技术，在反向代理之前的怎么对流量承受能力进行扩容呢？
- nginx成为了瓶颈应该怎么办
1 DNS轮询
最初的单体架构，流量直接打到唯一的一个web-server上：
tomcat只有1000QPS的抗压能力，当流量增大时，在反向代理流行之前，解决方案就是引入DNS轮询
DNS轮询：就是将多个web-server的实际公网ip配置到域名之下，通过dns-server来将流量按照轮询顺序转到对应ip的web-server上
DNS轮询的优势
- 支持扩展且成本低，主要增加机器和添加ip到域名即可
- 原先的系统不需要改造
- 负载均衡，dns可以保证每个节点是均衡的
DNS轮询的劣势
- 无法保证高可用，dns-server无法知道某一ip下的web-server是否可用，流量依旧会会被转到这里，这部分流量就会访问失败
- 扩容非实时，dns的解析生效有延迟
- 暴露过的的公网ip，安全性存在问题
2 反向代理
反向代理的优势
- 对外屏蔽web-server，由nginx进行流行转发
- 扩容是实时的，原有系统也无需变化
反向代理的问题
- nginx成为单点，依旧有高可用问题
- 反向代理层增加了复杂性和时延（次要）
高可用的反向代理
keepalived
不足的是资源利用率只有50%，假设nginx的承受QPS为10000，如果整个站点吞吐超过了nginx的上限，就需要转到多层反向代理
3 多层反向代理
之前提到过，lvs和F5，lvs是实施在操作系统层面的，F5是在硬件层面的，性能一个比一个好，用它们来作为nginx的方向代理就可以做到流量扩容
把lvs架在nginx上面作为nginx反向代理，F5又在lvs的上面作为反向代理，使用虚IP+keepalived来确保高可用。只有入口处需要这种方式来保证高可用，之后的下层和上层的结构，下层某一个节点挂了，上层都可以探测到将流量转发到可用的节点上，所以不需要虚IP+keepalived的模式
假设此时的QPS上限达到了10w，因为这是一个scale-up的方案，就始终会有明确的上限，这是由使用的工具本身决定的，要实现理论上的无限扩容，就必然需要scale-out的方案，这就又回到了最初的DNS轮询
4 多层反向代理，加DNS轮询
如果日PV达到了80亿次，像百度、Google、淘宝，以及一些大一些的企业的网站他们的域名都不止对应一个IP，终点又是起点，我们依旧需要DNS轮询
这种DNS轮询方式是高可用的，因为它的下游是高可用的
剑哥没有提到的：
- 比如区域划分，这就是dns解析服务区对应的服务区块了，华中的归华中，华东的归华东，这是由地理位置决定的
- 可以使用dns轮询 + nginx的模式
这一次剑哥分享了接入层的架构演进，依旧是干货满满的，下一篇将讲述session的一致性问题，这个session是广义的session，指的是用户会话状态的管理，不是单指web-server生产的session。
上一篇回顾：【成为架构师2-3】反向代理：接入层扩容，负载均衡
下一篇更精彩：【成为架构师2-5】维护session一致性的四种方案