“反向代理層”絕不能替代“DNS輪詢(xún)”！
有朋友問(wèn)我，DNS輪詢(xún)是不是過(guò)時(shí)的技術(shù)了?有了反向代理層(Nginx、LVS、F5等)，是不是就不需要DNS輪詢(xún)了?
然而，反向代理層絕不能替代DNS輪詢(xún)!
反向代理層有什么用?架構(gòu)實(shí)現(xiàn)時(shí)要注意什么?
(1) 作為服務(wù)端統(tǒng)一入口，屏蔽后端WEB集群細(xì)節(jié)，代表整個(gè)WEB集群;
畫(huà)外音：這就是為啥它叫反向代理。
(2) 保證WEB集群的擴(kuò)展性，Nginx后端可隨時(shí)加WEB實(shí)例;
(3) 實(shí)施負(fù)載均衡，反向代理層會(huì)將請(qǐng)求均勻分發(fā)給后端WEB集群的每一個(gè)實(shí)例;
(4) 保證WEB集群的高可用，任何一個(gè)WEB實(shí)例掛了，服務(wù)都不受影響;
(5) 注意自身高可用，防止一臺(tái)Nginx掛了，服務(wù)端統(tǒng)一入口受影響;
反向代理層還存在啥問(wèn)題?
反向代理層自身的擴(kuò)展性問(wèn)題并沒(méi)有得到很好的解決，例如當(dāng)Nginx成為系統(tǒng)瓶頸的時(shí)候，無(wú)法擴(kuò)容。
DNS輪詢(xún)?nèi)绾谓鉀Q反向代理層的擴(kuò)展性問(wèn)題?
通過(guò)在DNS-server上對(duì)一個(gè)域名設(shè)置多個(gè)IP解析，能夠增加入口Nginx實(shí)例個(gè)數(shù)，起到水平擴(kuò)容的作用，解決反向代理層的擴(kuò)展性問(wèn)題。
因此，反向代理和DNS輪詢(xún)并不是互斥的技術(shù)，however，這里詳細(xì)展開(kāi)講一下接入層的架構(gòu)漸進(jìn)歷程。
裸奔時(shí)代(1)單機(jī)架構(gòu)
裸奔時(shí)代的架構(gòu)圖如上：
- 瀏覽器通過(guò)DNS-server，域名解析到ip;
- 瀏覽器通過(guò)ip訪(fǎng)問(wèn)web-server;
缺點(diǎn)：
- 非高可用，web-server掛了整個(gè)系統(tǒng)就掛了;
- 擴(kuò)展性差，當(dāng)吞吐量達(dá)到web-server上限時(shí)，無(wú)法擴(kuò)容;
畫(huà)外音：?jiǎn)螜C(jī)不涉及負(fù)載均衡問(wèn)題。
簡(jiǎn)易擴(kuò)容方案(2)DNS輪詢(xún)
假設(shè)tomcat的吞吐量是1000次每秒，當(dāng)系統(tǒng)總吞吐量達(dá)到3000時(shí)，如何擴(kuò)容是首先要解決的問(wèn)題，DNS輪詢(xún)是一個(gè)很容易想到的方案。
畫(huà)外音：DNS輪詢(xún)解決擴(kuò)展性問(wèn)題。
此時(shí)的架構(gòu)圖如上：
- 多部署幾份web-server，1個(gè)tomcat抗1000，部署3個(gè)tomcat就能抗3000;
- 在DNS-server層面，域名每次解析到不同的ip;
優(yōu)點(diǎn)：
- 零成本：在DNS-server上多配幾個(gè)ip即可，功能也不收費(fèi);
- 部署簡(jiǎn)單：多部署幾個(gè)web-server即可，原系統(tǒng)架構(gòu)不需要做任何改造;
- 負(fù)載均衡：變成了多機(jī)，負(fù)載也是均衡的;
缺點(diǎn)：
- 非高可用：DNS-server只負(fù)責(zé)域名解析ip，這個(gè)ip對(duì)應(yīng)的服務(wù)是否可用，DNS-server是不保證的，假設(shè)有一個(gè)web-server掛了，部分服務(wù)會(huì)受到影響;
- 擴(kuò)容非實(shí)時(shí)：DNS解析有一個(gè)生效周期;
- 暴露了太多的外網(wǎng)ip;
簡(jiǎn)易擴(kuò)容方案(3)反向代理Nginx
tomcat的性能較差，但Nginx作為反向代理的性能就強(qiáng)很多，假設(shè)線(xiàn)上跑到1w，就比tomcat高了10倍，可以利用這個(gè)特性來(lái)做擴(kuò)容。
此時(shí)的架構(gòu)圖如上：
- 站點(diǎn)層與瀏覽器層之間加入了一個(gè)反向代理層，利用高性能的Nginx來(lái)做反向代理;
- Nginx將http請(qǐng)求分發(fā)給后端多個(gè)web-server;
優(yōu)點(diǎn)：
- DNS-server不需要?jiǎng)?
- 負(fù)載均衡：通過(guò)Nginx來(lái)保證;
- 只暴露一個(gè)外網(wǎng)ip，Nginx->tomcat之間使用內(nèi)網(wǎng)訪(fǎng)問(wèn);
- 擴(kuò)容實(shí)時(shí)：Nginx內(nèi)部可控，隨時(shí)增加web-server隨時(shí)實(shí)時(shí)擴(kuò)容;
- 能夠保證站點(diǎn)層的可用性：任何一臺(tái)tomcat掛了，Nginx可以將流量遷移到其他tomcat;
畫(huà)外音：反向代理，能夠更實(shí)時(shí)，更方便的擴(kuò)容了。
缺點(diǎn)：
- 時(shí)延增加+架構(gòu)更復(fù)雜了：中間多加了一個(gè)反向代理層;
- 反向代理層成了單點(diǎn)，非高可用：tomcat掛了不影響服務(wù)，Nginx掛了怎么辦?
高可用方案(4)keepalived
為了解決高可用的問(wèn)題，keepalived出場(chǎng)了。
- 做兩臺(tái)Nginx組成一個(gè)集群，分別部署上keepalived，設(shè)置成相同的虛IP，保證Nginx的高可用;
- 當(dāng)一臺(tái)Nginx掛了，keepalived能夠探測(cè)到，并將流量自動(dòng)遷移到另一臺(tái)Nginx上，整個(gè)過(guò)程對(duì)調(diào)用方透明;
優(yōu)點(diǎn)：
- 解決了高可用的問(wèn)題;
畫(huà)外音：反向代理的高可用也解決了。
缺點(diǎn)：
- 資源利用率只有50%;
- Nginx仍然是接入單點(diǎn)，如果接入吞吐量超過(guò)的Nginx的性能上限怎么辦，例如qps達(dá)到了50000咧?
scale up擴(kuò)容方案(5)lvs/f5
Nginx是應(yīng)用軟件，性能比tomcat好，但總有個(gè)上限，超出了上限，還是扛不住。
lvs就不一樣了，它實(shí)施在操作系統(tǒng)層面;f5的性能又更好了，它實(shí)施在硬件層面;它們性能比Nginx好很多，例如每秒可以抗10w，這樣可以利用他們來(lái)擴(kuò)容，常見(jiàn)的架構(gòu)圖如下：
- 如果通過(guò)Nginx可以擴(kuò)展多個(gè)tomcat一樣，可以通過(guò)lvs來(lái)擴(kuò)展多個(gè)Nginx;
- 通過(guò)keepalived+VIP的方案可以保證可用性;
99.9999%的公司到這一步基本就結(jié)束了，解決了接入層高可用、擴(kuò)展性、負(fù)載均衡的問(wèn)題。
畫(huà)外音：上游再加一層擴(kuò)充性能。
***了嘛，還有什么潛在問(wèn)題?
好吧，不管是使用lvs還是f5，這些都是scale up的方案，根本上，lvs/f5還是會(huì)有性能上限，假設(shè)每秒能處理10w的請(qǐng)求，一天也只能處理80億的請(qǐng)求(10w秒吞吐量*8w秒)，那萬(wàn)一系統(tǒng)的日PV超過(guò)80億怎么辦呢?
scale out擴(kuò)容方案(6)DNS輪詢(xún)
如之前文章所述，水平擴(kuò)展，才是解決性能問(wèn)題的根本方案，能夠通過(guò)加機(jī)器擴(kuò)充性能的方案才具備***的擴(kuò)展性。
facebook，google，baidu的PV是不是超過(guò)80億呢，它們的域名只對(duì)應(yīng)一個(gè)ip么，終點(diǎn)又是起點(diǎn)，還是得通過(guò)DNS輪詢(xún)來(lái)進(jìn)行擴(kuò)容。
畫(huà)外音：DNS輪詢(xún)解決擴(kuò)展性問(wèn)題。
- 通過(guò)DNS輪詢(xún)來(lái)線(xiàn)性擴(kuò)展入口lvs層的性能;
- 通過(guò)keepalived來(lái)保證高可用;
- 通過(guò)lvs來(lái)擴(kuò)展多個(gè)Nginx;
- 通過(guò)Nginx來(lái)做負(fù)載均衡，業(yè)務(wù)七層路由;
總結(jié)
稍微做一個(gè)簡(jiǎn)要的總結(jié)：
- 接入層架構(gòu)要考慮的問(wèn)題域?yàn)椋焊呖捎?、擴(kuò)展性、反向代理、負(fù)載均衡;
- Nginx、keepalived、lvs、f5可以很好的解決高可用、擴(kuò)展性、反向代理、負(fù)載均衡的問(wèn)題;
- 水平擴(kuò)展scale out是解決擴(kuò)展性問(wèn)題的根本方案，DNS輪詢(xún)是不能完全被Nginx/lvs/f5所替代的;
希望大家有收獲。
【本文為51CTO專(zhuān)欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請(qǐng)聯(lián)系原作者】
