“反向代理层”绝不能替代“DNS轮询”！.pdfVIP

“反向代理层”绝不能替代“DNS轮询” ！ 原创： 58沈剑 有朋友问我，DNS轮询是不是过时的技术了？有了反向代理层（Nginx 、LVS、F5等），是不是就不需要DNS轮询 了？ 然⽽，反向代理层绝不能替代DNS轮询！ 反向代理层有什么⽤？架构实现时要注意什么？ (1) 作为服务端统⼀⼊⼜，屏蔽后端WEB集群细节，代表整个WEB集群； 画外⾳：这就是为啥它叫反向代理。 (2) 保证WEB集群的扩展性，Nginx后端可随时加WEB实例； (3) 实施负载均衡，反向代理层会将请求均匀分发给后端WEB集群的每⼀个实例； (4) 保证WEB集群的⾼可⽤，任何⼀个WEB实例挂了，服务都不受影响； (5) 注意⾃⾝⾼可⽤，防⽌⼀台Nginx挂了，服务端统⼀⼊⼜受影响； 反向代理层还存在啥问题？ 反向代理层⾃⾝的扩展性问题并没有得到很好的解决，例如当Nginx成为系统瓶颈的时候，⽆法扩容。 DNS轮询如何解决反向代理层的扩展性问题？ 通过在DNS-server上对⼀个域名设置多个IP解析，能够增加⼊⼜Nginx实例个数，起到⽔平扩容的作⽤，解决反向 代理层的扩展性问题。 因此，反向代理和DNS轮询并不是互斥的技术，however ，这⾥详细展开讲⼀下接⼊层的架构渐进历程。 裸奔时代（1）单机架构 裸奔时代的架构图如上： (1) 浏览器通过DNS-server ，域名解析到ip ； (2) 浏览器通过ip访问web-server ； 缺点： (1) ⾮⾼可⽤，web-server挂了整个系统就挂了； (2) 扩展性差，当吞吐量达到web-server上限时，⽆法扩容； 画外⾳：单机不涉及负载均衡问题。 简易扩容⽅案（2）DNS轮询 假设tomcat 的吞吐量是1000次每秒，当系统总吞吐量达到3000时，如何扩容是⾸先要解决的问题，DNS轮询是⼀ 个很容易想到的⽅案。 画外⾳：DNS轮询解决扩展性问题。 此时的架构图如上： (1) 多部署⼏份web-server ，1个tomcat抗1000 ，部署3个tomcat就能抗3000 ； (2) 在DNS-server层⾯，域名每次解析到不同的ip ； 优点： (1) 零成本：在DNS-server上多配⼏个ip 即可，功能也不收费； (2) 部署简单：多部署⼏个web-server 即可，原系统架构不需要做任何改造； (3) 负载均衡：变成了多机，负载也是均衡的； 缺点： (1) ⾮⾼可⽤：DNS-server只负责域名解析ip ，这个ip对应的服务是否可⽤，DNS-server是不保证的，假设有⼀个 web-server挂了，部分服务会受到影响； (2) 扩容⾮实时：DNS解析有⼀个⽣效周期； (3) 暴露了太多的外⽹ip ； 简易扩容⽅案（3）反向代理Nginx tomcat 的性能较差，但Nginx作为反向代理的性能就强很多，假设线上跑到1w ，就⽐tomcat⾼了10倍，可以利⽤ 这个特性来做扩容。 此时的架构图如上： (1) 站点层与浏览器层之间加⼊了⼀个反向代理层，利⽤⾼性能的Nginx来做反向代理； (2) Nginx将http请求分发给后端多个web-server ； 优点： (1) DNS-server不需要动； (2) 负载均衡：通过Nginx来保证； (3) 只暴露⼀个外⽹ip ，Nginx->tomcat之间使⽤内⽹访问； (4) 扩容实时：Nginx 内部可控，随时增加web-server 随时实时扩容； (5) 能够保证站点层的可⽤性：任何⼀台tomcat挂了，Nginx可以将流量迁移到其他tomcat ； 画外⾳：反向代理，能够更实时，更⽅便的扩容了。 缺点： (1) 时延增加+架构更复杂了：中间多加了⼀个反向代理层； (2) 反向代理层成了单点，⾮⾼可⽤：tomcat挂了不影响服务，Nginx挂了怎么办？ ⾼可⽤⽅案（4）keepalived 为了解决⾼可⽤的问题，keepalived 出场了。 (1) 做两台Nginx组成⼀个集群，分别部署上keepalived ，设置成相同的虚IP ，保证Nginx的⾼可⽤； (2) 当⼀台Nginx挂了，keepalived能够探测到，并将流量⾃动迁移到另⼀台Nginx上，整个过程对调⽤⽅透明； 优点： (1) 解决了⾼可⽤的问题； 画外⾳：反向代理的⾼可⽤也解决了。 缺点： (1) 资源利⽤率只有50% ； (2) Nginx仍然是接⼊单点，如果接⼊吞吐量超过的Nginx的性能上限怎么办，例如qps达到了50000咧？ scale up扩容⽅案（5）lvs/f5