從0開始搭建Web架構

架構總圖


接下來進入正題，首先看這張總圖：

從0開始搭建Web架構
 


網絡接入層


 


1防火牆


全部的訪問請求(企業內部訪問可能除外)都是要通過企業級的防火牆設備。不論是企業自身的機房仍是託管的IDC機房，通常最外層都是由防火牆把關全部訪問請求。對於一些惡意的木馬植入等，防火牆會抵擋住大部分。做爲Web架構，最外層必定要選好防火牆，並且防火牆的架構最低通常會選擇不一樣型號的兩臺。


2安全設備


防火牆以後會接入IPS(入侵防護系統)，WAF(Web應用防禦系統)。這一塊區域主要對網絡安全，系統安全作檢測和防禦的，能夠採用商業設備(推薦)，資金不足的企業也能夠採用開源設備，這裏推薦一款開源產品OSSIM，有興趣的同窗能夠了解一下。


3負載均衡


通過網絡安全防禦以後，接下來是咱們的硬負載設備（該層無關緊要），通常硬負載均衡設備主要有F5，A10，相對比較貴，企業能夠根據狀況選擇。


硬負載接下來通常會有一層軟負載(固然軟負載和硬負載能夠只留一種也能夠都有)。軟負載層通常也會部署反向代理服務器，用做反向代理，也起到了防禦安全的做用。


通常在網絡規劃上，該層位於DMZ區域，該層之下的服務器位於內網。這塊隔離了外部請求和內網的直接交互，安全上有所提升。通常該層的技術選擇有Nginx，Apache，Haproxy，LVS等。大部分應該是一Nginx居多，既能夠作負載均衡，也能夠作反向代理，而且相對而言高併發效率更好。


關於這幾者的區別，網上也有不少，有興趣的同窗能夠多多比較。其中說明一點的是LVS是工做在網絡4層之上僅做分發之用，沒有流量的產生，其餘三種是工做在7層之上，若是不適用硬負載設備的話，建議使用LVS做爲流量轉發的負載設備，而後再是Nginx或是Haproxy。Apache在一些傳統企業存在或是使用得比較多，也比較穩定。


前端架構


 


通常在負載均衡後面是掛載的各類各樣的應用服務器。在部署應用服務器的時候通常會將靜態資源（JS，CSS，圖片，文件）等單獨一臺服務器部署，以減輕應用服務器的帶寬和IO，提升訪問效率。將這些靜態資源部署在靜態資源服務器、文件服務器、圖片服務器等。通常地若是咱們有CDN，會將這些靜態資源放在CDN上以提升網絡加載速度。常見的文件服務器和圖片服務器的技術架構有FastDFS，MogileFS，GraphicsMagick等。


可是中小企業建議直接購買雲服務。一是能夠減小運維成本，二是能夠提升訪問的速度，通常雲服務都搭配CDN。本身搭建文件或圖片服務器的運維成本仍是比較高，對技術要求也比較深刻。這裏你們在架構的時候須要仔細考慮好。


應用服務器


 


1web應用服務器


應用服務器通常是tomcat，IIS，resin等。通常有一個應用視狀況會有多臺服務器(最少2臺)，應用之間要解耦，應用之間的依賴儘可能採用接口交互（儘可能避免數據庫方面dblink等方式）。各位在作應用系統解耦的時候能夠參考如今比較流行的服務化，微服務等技術架構如dubbox等，可是須要對開發有必定的瞭解。雖然咱們的團隊經歷過和正在作dubbox的服務化，可是本人蔘與不是不少，因此也但願可以向你們多學習。


2消息隊列服務器


增長消息隊列服務器有如下幾點好處：


1.因爲消息隊列服務器的速度遠高於數據庫，可以快速處理並返回數據；
2.消息隊列服務器具備更好的擴展性；
3.在高併發的狀況下，延遲寫入數據庫，能夠有效下降數據庫的壓力。


消息隊列常常用在高併發應用（如搶購），不一樣系統模塊間高速數據交互等。經常使用的消息隊列技術有ActiveMQ，RabbitMQ等，這些技術自己就有很好的集羣或是主備機制，而且有監控的頁面，很是方便快速擴展和使用。監控在使用的時候，通常須要腳本(CURL獲取監控頁面的值和監控頁面的http staus)或其餘方式監控，實現故障自動告警。


3緩存服務器


數據緩存服務器，常有的部署有Memcached，Redis等，目前應該是以Redis居多吧。另外應用應用服務器集羣的session問題也經常用到Redis。Redis自身的哨兵模式，集羣Cluster(3.0以上版本支持)能夠避免單點故障，方便橫向和縱向擴展，緩存熱點數據提升訪問效率，在高併發環境也是常常用到的技術。


這裏要注意一下，並非全部的Web架構都須要消息隊列或是數據庫緩存，視狀況而定，根據系統的併發量和訪問量評估。合適本身的纔是最好的。


數據庫層


 


1數據庫鏈接池


應用跟數據庫之間通常要儘可能避免應用直接鏈接數據庫，採用數據庫鏈接池的方式。數據庫鏈接池技術帶來的優點有資源複用、更快的相應速度、統一的鏈接管理、避免鏈接泄露等好處。經常使用的有c3p0,dbcp,druid等，這裏強烈推薦Druid。


2數據庫架構


數據庫鏈接池後面就是數據庫了。數據庫種類也比較多，經常使用的有Oracle，MySQL等。固然了，一個系統使用一套數據庫，儘可能避免多套應用系統使用同一個數據庫。


因爲數據庫的重要性，須要考慮到數據庫方案。包括實現數據庫的高可用、負載均衡等，有些電商平臺還須要實現讀寫分離，數據庫的橫向縱向拆分等，以實現複雜的數據庫應用。


Oracle的經常使用架構有RAC，DG(dataguard)，而Oracle的成本比較高，因此不少中小企業會選擇MySQL。MySQL也有不一樣的分支和技術方案，如官方版本的MariaDB，PerconaDB等。經常使用的高可用架構有複製，Cluster，不一樣分支都有支持，這裏我推薦你們使用MariaDB10.0以上的版本，效率相對較高。


MySQL的中間件也比較多，用來支持負載均衡，讀寫分離，分庫分表等。如OneProxy，MyCAT等都是很是優秀的MySQL數據庫中間件，建議你們有時間多研究，架構出穩定可靠的數據庫集羣。


數據庫的備份和恢復這裏就不單獨說了，在下面的災備方案中統一說明。


3存儲設備


通常企業會有專業的存儲設備。存儲設備的raid選擇、主備架構方案等都須要提早架構以及跟存儲廠商溝通討論。做爲最關鍵的設備之一，必定要避免單點故障，不然將致使整個IT系統宕機。


以上是關於常見的Web系統架構的一個概述，以及經常使用的一些技術方案的說明，有不足之處，請你們多多指教，相互學習。


災備方案


接下來跟你們介紹關於備份相關的問題。無論傳統企業仍是互聯網，備份必定是一個及其關鍵重要的工做。沒有備份，就意味着系統沒有最基本的保障。


常見的災備方案通常是同城熱備，異地災備的方式，即兩地三中心的方式。同城的網絡延遲通常能夠作到比較小，因此在用實時熱備的方式是可行的。將應用服務器、數據庫等經過實時同步的方式，數據傳輸到同城其餘機房，實現跨機房的熱備。


異地採用延遲備份的方式。將本地機房的備份集經過網絡傳輸傳送一份到異地機房實現異地災備。其中異地災備是有數據延遲的，通常一天。


不論是應用服務器，仍是數據備份的方式都有不少種，因時間限制就不一一跟你們分享了。這裏要着重注意的是備份集的測試方案，必定要與災備方案一塊兒，並根據測試方案嚴格定時執行，確保備份集的準確性。


其餘方面


做爲一套完整的IT技術架構方案，其實還有不少方面須要考慮，例如監控方案。咱們經常使用的監控方案有lepus監控數據庫、Zabbix、腳本三者結合的方式。經過郵件，阿里大於短信等方式發送報警，日誌服務器用於採集和分析日誌，如ELK等。還有通常企業會有數據平臺用於分析本身數據，這裏能夠參考個人另外一篇文章《數據即金錢，中小企業如何搭建數據平臺分得一杯羹？》


另一般企業爲了節省成本會考慮虛擬化，將服務器等硬件資源虛擬化，提升利用率節省企業的成本，進而爲企業的私有云搭建奠基基礎。之後但願有機會跟你們一塊兒交流虛擬化+私有云的技術方案，這也是咱們如今正在着手進行的，頗有實踐參考意義。


關於互聯網創業初期技術團隊


上面這些是關於技術方面的架構，接下來的時間簡單分享一下關於技術團隊初創期間的一些經驗教訓和想法，歡迎拍磚。


主要如下幾點：


1.以核心業務爲中心，初期技術團隊不斷知足業務需求。避免盲目擴張團隊規模和採用過於超強的技術架構，技術架構要匹配業務發展的需求和規模。
2.建議初期之外包爲主，可是核心業務和技術架構必須以本身團隊的人爲主且不能動搖。要有外包項目結束後能迅速接手的能力。
3.團隊要小而精，扁平化管理，少管理崗，多技術崗，團隊要有共同的目標和發展願景。


傳統企業轉型互聯網尤爲要注意，縱使財大氣粗，也要精打細算。就我的而言，經歷過IT團隊短短一年左右的時間從13人到200多號人，業務規劃卻遲遲沒有突破的狀況，最終大批裁人，拼命掙扎的一種狀態。


友情提醒一下各位，當注意到團隊成員工做並不飽和，但同一崗位還有招聘計劃時，必定要考慮一下是該招聘仍是該減員。


縱觀一批批倒下的初創公司，失敗的經驗教訓很值得咱們深刻研究和學習。