国产成人综合一区精品,久久精品爱国产免费久久,中文精品视频一区二区在线观看

在許多小公司和小企業，尤其是涉及電子廣告和電子資訊類的網站，其網站的日PV不超過一百萬，但由于其重要性，也要求網站應該具備負載均衡高可用的特點;另一方面，由于成本的制約，公司都會要求系統架構師設計的方案能夠用最少的預算來滿足這個要求，作為運維架構師的我們，應該如何滿足這個要求呢?

首先是機房的選擇，如果公司有自己的機房那是最好不過的了;如果沒有自己的機房，建議放在BGP機房內托管，最好是選擇帶有硬件防火墻的BGP機房，在安全方面會更有保障。另外，如何選擇服務器呢?在有了負載均衡高可用的集群環境后，我們完全可以自己組裝服務器，這在性價比上也是較高的。像IBM和DELL等品牌的服務器，雖然質量有保障，但價格還是比較昂貴的。當然了，一切以穩定為前提和原則。



另外，如果考慮用云產品來部署自己的網站，可以對比下阿里云和亞馬遜云的價格，亞馬遜AWS宣布入華后，阿里云的全線產品下降了30%。而云計算相比傳統IT的較大優勢在于成本。如果對比下同等規模的機器，可以發現阿里云在價格上具有絕對的優勢。所以對于小型網站來說，可以考慮采用阿里云的方式進行部署。

網站架構設計首先要考慮的是負載均衡設備的選擇。這里有兩種選擇，一種是通過硬件來進行，常見的硬件有比較昂貴的NetScaler、F5 BIG-IP等商用的負載均衡器，優點就是有專業的維護團隊來對這些服務進行后期維護;缺點就是開銷太大，所以對于規模較小的網絡服務來說暫時還沒有使用的需要。另外一種就是類似于LVS/HAProxy、Nginx等基于Linux的負載均衡軟件策略，這些都是通過軟件級別來實現的，所以費用非常低廉，小型企業和公司大都會選擇軟件級別的負載均衡。至于負載均衡高可用架構，首推是Nginx/HAProxy+Keepalived架構，可能有讀者會有疑問，為什么不選擇基于LVS/DR+Keepalived的集群方案呢?這是因為我們部署的網站一般都會有動靜分離、正則分發的需求，如果最初始選用LVS+Keepalived的架構，那么至少又要在中間加一層二級負載均衡的機器，這樣會比較耗機器，無形中也會增加整個網站的成本。另外，很多朋友都比較擔心的一個問題，認為Nginx/HAProxy+Keepalived的穩定性不如LVS+Keepalived，這其實是個誤解。我們通過十幾個項目的實施和幾年的觀察，發現這些軟件級別的負載均衡器的穩定性確實很好，在高并發的情況下宕機的可能性微乎其微。而近期實施的一個商業網站，用的就是HAProxy+Keepalived，在億PV/日高并發流量的沖擊下，HAProxy穩如磐石。而小公司的并發和流量一般不是特別大，大概一天持續在100萬~500萬PV/日之間，所以這里也向大家推薦使用HAProxy+Keepalived。

在實際的項目實施過程中筆者發現，像這樣的集群方案也比較耗費資源，特別是對于網站規模較小，機器非常少的情況，效果會不太好。筆者之前維護的公司有一個新聞類網站(此域名做了無害處理，非真實域名)，其服務器就比較少，而且是阿里云主機，前期做的是HAProxy+Keepalived集群方案，但發現效果并不是特別好，因為阿里云主機的帶寬都是共享100MB，實際上分配到網站入口的帶寬僅僅只有10MB左右，繁忙的時候會嚴重影響業務，雖然每個月我們通過加錢的方式來增加HAProxy+Keepalived的入口帶寬，但并不是完美的解決方案，其他機器的共享帶寬沒有得到充分的利用。此外，由于所有的機器都是獨享型主機，二層交換機也并不集中在一個機柜上，若在中間加一層HAProxy代理，網站的速度很明顯又會變慢。這時候，筆者突然想到了最簡單和原始的負載均衡機制，即DNS輪詢，通過在美國的HostMonster(DNS提供商，國內像新網和萬網均提供DNS輪詢功能)上配置3個www的A主機，這樣就解決了上面所說的一系列問題，后期如果流量持續增加，還可以增加機器，將網站入口由原先的單一入口模式改成分布式的，而且完全不影響網站的訪問速度。當然了，平時一定要注意服務器的監控和服務器的穩定情況，畢竟每宕機一臺服務器，肯定會有用戶受到影響的。

通過這次成功的項目實施，我也明白了一個道理：集群的部署不應該一成不變，而應該根據具體情況具體分析，哪種方案實用就用哪種，哪怕是最簡單的DNS輪詢。

如果網站是放在IDC機房托管，而機房的最前面也沒有硬件防火墻防護，那么應該盡量做好流量監控的工作，筆者一般會在主Nginx/HAProxy上安裝Nload軟件來對流量進行監控，Nload可以對流量進行即時監控。

很多對集群感興趣的讀者經常問我，如果網站要部署負載均衡高可用的Linux集群方案，而公司又想用最節省成本的方式來實施的話，一般需要幾臺服務器呢?如果資金比較充裕，推薦大家用7臺來實施，即LB(2臺)+Web(2臺)+MySQL(2臺)+NFS(1臺);如果資金非常不充裕，這個方案其實還是可以壓縮的，即2+2架構，最前面是2臺Nginx/HAProxy+Keepalived機器，后面是2臺配置比較好的Web機器(推薦DELL R710)，MySQL數據庫采用一主一從的方式，分別放在2臺Web機器上，監控的Nagios部署在從Nginx/HAProxy機器上，流量監控一般放在主Nginx/HAProxy上，軟件采用的是MRTG+Nload的方式，文件服務器這里用的是單NFS，放在備HAProxy機器上，Web機器采用掛載NFS的目錄作為本地的代碼或圖片存放的方法;當然了，如果大家的公司對文件服務器有更高要求的時候(比如網站的圖片數量比較多的時候)，可以考慮再增加一臺圖片服務器。

在類似以上的小公司集群架構里，應如何解決Session同步的問題呢?可以采用Nginx的ip_hash和HAProxy的balance source算法，它們算法的原理是一樣的，都會讓某一客戶機在相當長的一段時間內只訪問固定的后端的某臺真實的Web服務器。這樣Session會話就會得以保持，我們在網站的頁面上進行登錄的時候，就不會在兩臺Web服務器之間跳來跳去了，自然也不會出現登錄一次后網站又提醒你重新登錄的情況，事實上，在千萬級PV/日的網站上我們也嘗試過用這些方式來解決Session同步的問題，效果也是相當不錯的。

另外，小公司的Web服務器也至少有兩種選擇：一種是Apache，另一種是Nginx。在流量和并發量不大的環境下，完全可以選擇Apache作為我們的Web服務器，雖然它的抗并發能力不高，但它的穩定性是最好的，筆者的許多電子商務網站都是基于Apache來提供Web應用的。

MySQL在這里用的就是一主一從的設計，雖然很多朋友覺得這種設計比較簡單，但事實證明，它也是最穩定的。我的電子商務網站采用的也是這種架構，幾年下來，從來沒有因為數據庫的故障而發生丟單現象。另外，從MySQL機器并非僅僅只起一個備份和備機的作用，我們設計的數據庫讀寫分離，可將后臺的復雜查詢轉到從MySQL機器上以減輕主MySQL數據庫的壓力。當然了，MySQL的主從復制狀態監控也是非常重要的，筆者一般是通過Nagios和Shell腳本進行雙監控的方式。

如何能幫企業節約和省錢，這其實也是運維架構師的工作職責之一，希望大家在工作中能領悟到這點。這樣設計出來的網站，極具性價比，同時又具備高可用的特點，特別適合流量不大，但穩定性要求比較高的網站，有需求的朋友可以參考此架構設計。
?