? ? ? ?最近一個(gè)項(xiàng)目上的需求：要求在短期內(nèi)通過(guò)媒體發(fā)布消息，統(tǒng)一通過(guò)互聯(lián)網(wǎng)上的某入口進(jìn)行預(yù)約辦理業(yè)務(wù)。此需求涉及到高并發(fā)互聯(lián)網(wǎng)應(yīng)用的解決方案。
一、簡(jiǎn)介
二、網(wǎng)絡(luò)架構(gòu)優(yōu)化
2.1域名負(fù)載均衡
動(dòng)態(tài)DNS（英語(yǔ)：Dynamic DNS，簡(jiǎn)稱D-DNS）是一種把互聯(lián)網(wǎng)域名指往可變IP地址的系統(tǒng)。簡(jiǎn)單的說(shuō)，動(dòng)態(tài)域名可以在你的電腦每次上網(wǎng)得到新的IP之后，自動(dòng)設(shè)置了新域名的指向，使網(wǎng)上其他任何人訪問(wèn)該域名時(shí)，始終能定向到你機(jī)器的最新的正確IP上去，從而使得人們能使用一個(gè)能記憶的，對(duì)用戶來(lái)說(shuō)是永遠(yuǎn)不變的域名來(lái)訪問(wèn)你那臺(tái)IP每天都在變化的機(jī)器。從而也就能實(shí)現(xiàn)了將個(gè)人電腦變成可以供任何人訪問(wèn)的“服務(wù)器”了。
當(dāng)然，我所關(guān)心的是動(dòng)態(tài)DNS技術(shù)在負(fù)載均衡方面的應(yīng)用，那么讓我們看看其實(shí)現(xiàn)原理：
DNS負(fù)載均衡技術(shù)的實(shí)現(xiàn)原理是在DNS服務(wù)器中為同一個(gè)主機(jī)名配置多個(gè)IP地址，在應(yīng)答DNS查詢時(shí)，DNS服務(wù)器對(duì)每個(gè)查詢將以DNS文件中主機(jī)記錄的IP地址按順序返回不同的解析結(jié)果，將客戶端的訪問(wèn)引導(dǎo)到不同的機(jī)器上去，使得不同的客戶端訪問(wèn)不同的服務(wù)器，從而達(dá)到負(fù)載均衡的目的。
主要優(yōu)點(diǎn)
這種技術(shù)的主要優(yōu)點(diǎn)如下：
第一，技術(shù)實(shí)現(xiàn)比較靈活、方便，簡(jiǎn)單易行，成本低，適用于大多數(shù)TCP/IP應(yīng)用。不需要網(wǎng)絡(luò)專家來(lái)對(duì)之進(jìn)行設(shè)定，或在出現(xiàn)問(wèn)題時(shí)對(duì)之進(jìn)行維護(hù)。
第二，對(duì)于Web應(yīng)用來(lái)說(shuō)，不需要對(duì)代碼作任何的修改。事實(shí)上，Web應(yīng)用本身并不會(huì)意識(shí)到負(fù)載均衡配置，即使在它面前。
第三，Web服務(wù)器可以位于互聯(lián)網(wǎng)的任意位置上。
主要缺點(diǎn)
DNS負(fù)載均衡技術(shù)在具有以上優(yōu)點(diǎn)的時(shí)候，其缺點(diǎn)也非常明顯，主要表現(xiàn)在：
第一，不能夠按照Web服務(wù)器的處理能力分配負(fù)載。DNS負(fù)載均衡采用的是簡(jiǎn)單的輪循負(fù)載算法，不能區(qū)分服務(wù)器之間的差異，不能反映服務(wù)器的當(dāng)前運(yùn)行狀態(tài)。所以DNS服務(wù)器將Http請(qǐng)求平均地分配到后臺(tái)的Web服務(wù)器上，而不考慮每個(gè)Web服務(wù)器當(dāng)前的負(fù)載情況。如果后臺(tái)的Web服務(wù)器的配置和處理能力不同，最慢的 Web服務(wù)器將成為系統(tǒng)的瓶頸，處理能力強(qiáng)的服務(wù)器不能充分發(fā)揮作用。不能做到為性能較好的服務(wù)器多分配請(qǐng)求，甚至?xí)霈F(xiàn)客戶請(qǐng)求集中在某一臺(tái)服務(wù)器上的情況。
第二，不支持高可靠性，DNS負(fù)載均衡技術(shù)沒有考慮容錯(cuò)。如果后臺(tái)的某臺(tái)Web服務(wù)器出現(xiàn)故障，DNS服務(wù)器仍然會(huì)把DNS 請(qǐng)求分配到這臺(tái)故障服務(wù)器上，導(dǎo)致不能響應(yīng)客戶端。
第三，可能會(huì)造成額外的網(wǎng)絡(luò)問(wèn)題。為了使本DNS服務(wù)器和其他DNS服務(wù)器及時(shí)交互，保證DNS數(shù)據(jù)及時(shí)更新，使地址能隨機(jī)分配，一般都要將DNS的刷新時(shí)間設(shè)置的較小，但太小將會(huì)使DNS流量大增造成額外的網(wǎng)絡(luò)問(wèn)題。
第四，一旦某個(gè)服務(wù)器出現(xiàn)故障，即使及時(shí)修改了DNS設(shè)置，還是要等待足夠的時(shí)間(刷新時(shí)間)才能發(fā)揮作用，在此期間，保存了故障服務(wù)器地址的客戶計(jì)算機(jī)將不能正常訪問(wèn)服務(wù)器。
2.2CDN
對(duì)于大型網(wǎng)站來(lái)說(shuō)增加CDN這一層是非常有必要的，CDN（Content Delivery Network，內(nèi)容分發(fā)網(wǎng)絡(luò)），它屬于網(wǎng)絡(luò)范疇的一個(gè)技術(shù)，它依靠部署在各個(gè)區(qū)域的邊緣服務(wù)器，實(shí)現(xiàn)負(fù)載均衡、內(nèi)容分發(fā)調(diào)度等功能。它使得用戶就近獲取內(nèi)容，降低網(wǎng)絡(luò)堵塞，提供用戶訪問(wèn)響應(yīng)速度。網(wǎng)絡(luò)應(yīng)用的很大一部分由靜態(tài)資源構(gòu)成,如圖片、CSS樣式文件、JavaScript腳本以及一些針對(duì)特定產(chǎn)品提前渲染好的頁(yè)面等，通過(guò)使用緩存，對(duì)于一些客戶的請(qǐng)求，不一定都去重新處理一遍，使用緩存，提高訪問(wèn)速度。遍布各地的CDN使得用戶可以從物理上靠近他們的地方來(lái)獲取網(wǎng)頁(yè)內(nèi)容，而不是每次都把數(shù)據(jù)從源頭搬到用戶那里。
來(lái)舉一個(gè)通俗點(diǎn)的例子：小明公司做了了一個(gè)針對(duì)全國(guó)用戶的業(yè)務(wù)，服務(wù)器放在了北京，但是深圳用戶在訪問(wèn)網(wǎng)站的時(shí)候非常卡頓，有時(shí)候甚至訪問(wèn)不到。經(jīng)排查，造成該問(wèn)題的原因是深圳用戶所在網(wǎng)絡(luò)到北京的機(jī)房延遲非常大。小明想到了一個(gè)辦法，他在深圳的某機(jī)房假設(shè)了一臺(tái)服務(wù)器，把北京服務(wù)器上的文件傳輸?shù)缴钲诘姆?wù)器上，當(dāng)深圳用戶訪問(wèn)網(wǎng)站時(shí)，讓該用戶直接去訪問(wèn)深圳的服務(wù)器，而不是訪問(wèn)北京的服務(wù)器。同理，其他城市也效仿深圳假設(shè)了類似的服務(wù)器，這樣全國(guó)各地的用戶訪問(wèn)公司業(yè)務(wù)都很順暢了。
例子中的解決方案其實(shí)就是CDN實(shí)現(xiàn)原理，當(dāng)然，真正的CDN技術(shù)要復(fù)雜得多，要考慮很多問(wèn)題，比如邊緣服務(wù)器的分布、機(jī)房的網(wǎng)絡(luò)、帶寬、服務(wù)器的存儲(chǔ)、智能DNS解析、邊緣服務(wù)器到真實(shí)服務(wù)器之間的網(wǎng)絡(luò)優(yōu)化、靜態(tài)和動(dòng)態(tài)資源的區(qū)分、緩存的優(yōu)化、壓縮、SSL等等問(wèn)題。關(guān)于這些細(xì)節(jié)技術(shù)我不做過(guò)多解釋，但希望大家能通過(guò)我的描述了解CDN在架構(gòu)中存在的意義。
CDN是處于整個(gè)架構(gòu)體系中最前端的一層，它是直接面對(duì)用戶的，CDN會(huì)把靜態(tài)的請(qǐng)求（圖片、js、css等）直接消化掉，然后把動(dòng)態(tài)的請(qǐng)求往后傳遞。實(shí)際上，一個(gè)網(wǎng)站（比如，淘寶網(wǎng)）超過(guò)80%的請(qǐng)求都是靜態(tài)的請(qǐng)求，那也就意味如果前端架設(shè)了CDN，即使并發(fā)1億，也只有2000萬(wàn)到了后端的WEB上。那么你可能會(huì)問(wèn)，CDN能支持8000萬(wàn)的并發(fā)嗎？這個(gè)主要取決于CDN廠商的實(shí)力，如果他們搞10000個(gè)節(jié)點(diǎn)（即邊緣服務(wù)器），每個(gè)節(jié)點(diǎn)上消化8000并發(fā)，如果搞10萬(wàn)個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)只需要消化800個(gè)并發(fā)而已。然而，一臺(tái)普通的Nginx服務(wù)器（配置2核CPU4G內(nèi)存）輕松處理5萬(wàn)個(gè)并發(fā)（前提是做過(guò)優(yōu)化，并且處理的請(qǐng)求是靜態(tài)請(qǐng)求、或者只是轉(zhuǎn)發(fā)請(qǐng)求）。
2.3帶寬
無(wú)論上邊提到的域名負(fù)載均衡還是多臺(tái)就近CDN，都要注意網(wǎng)絡(luò)的帶寬瓶頸。例如，動(dòng)態(tài)域名的多個(gè)IP最好是分布在不同的鏈路和網(wǎng)絡(luò)上，這樣效果明顯。如果多個(gè)IP處于同一機(jī)房的同一網(wǎng)絡(luò)鏈路上，網(wǎng)絡(luò)壓力還是不能減輕，那么域名負(fù)載均衡對(duì)網(wǎng)絡(luò)壓力就沒有緩解的效果。
3、服務(wù)優(yōu)化
3.1動(dòng)靜分離
? ? ? ?大家都知道，效率最高、消耗最小的就是純靜態(tài)化的html頁(yè)面，所以我們盡可能使我們的網(wǎng)站上的頁(yè)面采用靜態(tài)頁(yè)面來(lái)實(shí)現(xiàn)，這個(gè)最簡(jiǎn)單的方法其實(shí)也是最有效的方法。但是對(duì)于大量?jī)?nèi)容并且頻繁更新的網(wǎng)站，我們無(wú)法全部手動(dòng)去挨個(gè)實(shí)現(xiàn)，于是出現(xiàn)了我們常見的信息發(fā)布系統(tǒng)CMS，像我們常訪問(wèn)的各個(gè)門戶站點(diǎn)的新聞?lì)l道，甚至他們的其他頻道，都是通過(guò)信息發(fā)布系統(tǒng)來(lái)管理和實(shí)現(xiàn)的，信息發(fā)布系統(tǒng)可以實(shí)現(xiàn)最簡(jiǎn)單的信息錄入自動(dòng)生成靜態(tài)頁(yè)面，還能具備頻道管理、權(quán)限管理、自動(dòng)抓取等功能，對(duì)于一個(gè)大型網(wǎng)站來(lái)說(shuō)，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發(fā)布類型的網(wǎng)站，對(duì)于交互性要求很高的社區(qū)類型網(wǎng)站來(lái)說(shuō)，盡可能的靜態(tài)化也是提高性能的必要手段，將社區(qū)內(nèi)的帖子、文章進(jìn)行實(shí)時(shí)的靜態(tài)化、有更新的時(shí)候再重新靜態(tài)化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網(wǎng)易社區(qū)等也是如此。
同時(shí)，html靜態(tài)化也是某些緩存策略使用的手段，對(duì)于系統(tǒng)中頻繁使用數(shù)據(jù)庫(kù)查詢但是內(nèi)容更新很小的應(yīng)用，可以考慮使用html靜態(tài)化來(lái)實(shí)現(xiàn)。比如論壇中論壇的公用設(shè)置信息，這些信息目前的主流論壇都可以進(jìn)行后臺(tái)管理并且存儲(chǔ)在數(shù)據(jù)庫(kù)中，這些信息其實(shí)大量被前臺(tái)程序調(diào)用，但是更新頻率很小，可以考慮將這部分內(nèi)容進(jìn)行后臺(tái)更新的時(shí)候進(jìn)行靜態(tài)化，這樣避免了大量的數(shù)據(jù)庫(kù)訪問(wèn)請(qǐng)求。
? ? ? ?對(duì)于Web服務(wù)器來(lái)說(shuō)，不管是Apache、IIS還是其他容器，圖片是最消耗資源的，于是我們有必要將圖片與頁(yè)面進(jìn)行分離，這是基本上大型網(wǎng)站都會(huì)采用的策略，他們都有獨(dú)立的、甚至很多臺(tái)的圖片服務(wù)器。這樣的架構(gòu)可以降低提供頁(yè)面訪問(wèn)請(qǐng)求的服務(wù)器系統(tǒng)壓力，并且可以保證系統(tǒng)不會(huì)因?yàn)閳D片問(wèn)題而崩潰。
在應(yīng)用服務(wù)器和圖片服務(wù)器上，可以進(jìn)行不同的配置優(yōu)化，比如apache在配置ContentType的時(shí)候可以盡量少支持、盡可能少的LoadModule，保證更高的系統(tǒng)消耗和執(zhí)行效率。
3.2流量?jī)?yōu)化
圖片縮略顯示圖不要用原圖，可以生成靜態(tài)的縮略圖以減輕流量壓力。JS庫(kù)也要采用壓縮的模式不要用開發(fā)調(diào)試模式。從內(nèi)容上盡量減少下載的數(shù)據(jù)量。
3.3數(shù)據(jù)庫(kù)優(yōu)化
將數(shù)據(jù)庫(kù)的最大連接數(shù)調(diào)大，同時(shí)調(diào)大數(shù)據(jù)鏈接池的空閑連接數(shù)。
3.4緩存優(yōu)化
Redis 是一個(gè)高性能的key-value數(shù)據(jù)庫(kù)。 redis的出現(xiàn)，很大程度補(bǔ)償了memcached這類key/value存儲(chǔ)的不足，在部 分場(chǎng)合可以對(duì)關(guān)系數(shù)據(jù)庫(kù)起到很好的補(bǔ)充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。
?對(duì)頻繁訪問(wèn)且更新頻率低的數(shù)據(jù)，放到redis里，由于redis里的數(shù)據(jù)存于內(nèi)存之中，這樣減少了對(duì)磁盤的訪問(wèn)從而提升了服務(wù)的吞吐量。
3.5隊(duì)列優(yōu)化
MQ，就是簡(jiǎn)單的在隊(duì)列中插入一條消息，這個(gè)時(shí)間成本，顯然比B服務(wù)的時(shí)間要低。而B服務(wù)，會(huì)自己去MQ讀取相關(guān)消息，并進(jìn)行相應(yīng)的操作，如插入日志等。
MQ，消息隊(duì)列，消息可以理解為一個(gè)業(yè)務(wù)現(xiàn)場(chǎng)，而隊(duì)列則是保存這個(gè)業(yè)務(wù)現(xiàn)場(chǎng)的容器，而B服務(wù)對(duì)消息的處理，則是一個(gè)對(duì)業(yè)務(wù)現(xiàn)場(chǎng)的異步處理。所以，消息隊(duì)列的本質(zhì)，就是將某個(gè)業(yè)務(wù)現(xiàn)場(chǎng)暫存下來(lái)，異步處理。
優(yōu)點(diǎn)如下：
1． 異步。正如上面的demo，異步就是MQ的第一個(gè)能力?？梢詫⒁恍┓呛诵牧鞒?，如日志，短信，郵件等，通過(guò)MQ的方式異步去處理。這樣做的好處是縮短主流程的響應(yīng)時(shí)間，提升用戶體驗(yàn)。
2． 解耦。假設(shè)現(xiàn)在，日志不光要插入到數(shù)據(jù)庫(kù)里，還要在硬盤中增加文件類型的日志，同時(shí)，一些關(guān)鍵日志還要通過(guò)郵件的方式發(fā)送給指定的人。那么，如果按照原來(lái)的邏輯，A可能就需要在原來(lái)的代碼上做擴(kuò)展，除了B服務(wù)，還要加上日志文件的存儲(chǔ)和日志郵件的發(fā)送。但是，如果你使用了MQ，那么，A服務(wù)是不需要做更改的，它還是將消息放到MQ中即可，其它的服務(wù)，無(wú)論是原來(lái)的B服務(wù)還是新增的日志文件存儲(chǔ)服務(wù)或日志郵件發(fā)送服務(wù)，都直接從MQ中獲取消息并處理即可。這就是解耦，它的好處是提高系統(tǒng)靈活性，擴(kuò)展性。
3． 消峰。這個(gè)其實(shí)也很好理解，因?yàn)镸Q的本質(zhì)就是業(yè)務(wù)的排隊(duì)。所以，面對(duì)突然到來(lái)的高并發(fā)，MQ也可以不用慌忙，先排好隊(duì)，不要著急，一個(gè)一個(gè)來(lái)。消峰的好處就是避免高并發(fā)壓垮系統(tǒng)的關(guān)鍵組件，如某個(gè)核心服務(wù)或數(shù)據(jù)庫(kù)等。
異步，解耦，消峰，MQ的三大主要應(yīng)用場(chǎng)景。
采用MQ對(duì)請(qǐng)求進(jìn)行處理，當(dāng)服務(wù)無(wú)法及時(shí)響應(yīng)請(qǐng)求時(shí)放到MQ里暫存來(lái)緩解峰值對(duì)服務(wù)的壓力。
3.6Nginx調(diào)優(yōu)
Nginx調(diào)優(yōu)最核心的參數(shù)有兩個(gè)：
1、worker_processes auto;? #這樣nginx會(huì)自動(dòng)根據(jù)核心數(shù)為生成對(duì)應(yīng)數(shù)量的worker進(jìn)程。
2、events {
? ? ? ? use epoll;? ?#采用Linux下epoll模型，比傳統(tǒng)的select模型性能提高一個(gè)數(shù)量級(jí)
? ? ????worker_connections? 65535;
????}
