從0開始搭建堅不可摧的Web系統主流架構

轉自：http://mp.weixin.qq.com/s/HKqgdR0qM3FhdGWcWnlpug

主題簡介：

1、網站系統架構當前現狀

2、Web系統主流架構解析

3、互聯網技術團隊初期組建經驗分享

本文主要結合我之前在海爾電商平臺和現在公司的一些實際架構經驗，綜合實際情況和個人的理解，跟大家分享一下搭建Web系統的一些常用的技術架構和應用技巧。

首先要跟大家探討一個問題，就是當前傳統IT企業或是傳統企業的IT系統目前的系統架構是怎樣的呢？

就我所經歷的NEC軟件、海爾集團、青島航空等某種程度上都屬于傳統企業。我本人也是最近三年在海爾搞電商平臺的時候，才更多地接觸互聯網的思維和技術架構。

我在青島航空的這一年多時間里以及與青島其他IT同行討論時，發現了一個現象：就是目前很多傳統企業的技術架構跟互聯網企業的技術架構越來越相似了，或是傳統企業越來越傾向于互聯網的主流技術架構和服務器部署等方式。

雖然傳統企業可能沒有互聯網企業的大流量、數據量，高并發(互聯網企業真正大流量高并發的也就那么幾家)，但是兩者在技術架構上的很多方面、方向都是一致的，個人感覺這是一個比較好的現象。傳統企業借鑒互聯網企業的一些優秀的技術架構和部署方式，可以更好地保障自身的業務系統，提高系統的使用效率等。成熟的開源技術架構也可以為企業節省很多IT成本。

青島航空有自己的官網，偶爾搞個搶票，促銷或是暑運春運，有時候會受到一些網絡的惡意攻擊。這時雖然流量會陡增，但是在目前的技術架構上完全可以抵擋住。

本文將分析目前主流的一些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多號人，業務規劃卻遲遲沒有突破的情況，最終大批裁員，拼命掙扎的一種狀態。

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

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

Q&A

Q1：如果公司對于it不打算花太多成本，請問如果僅對于企業內部使用erp管理系統的架構 哪些節點可以省掉，哪些又是必須的呢？

A1：如果是打算上ERP的話，建議直接購買國內的ERP系統，一般價格相對便宜，功能比較齊全適合國人使用。我本人并沒有部署過成型的商業ERP系統，所以對于商業ERP系統這一塊不是特別理解。就我們青島航空而言呢，是購買的oracle的ERP系統，但是呢，只是購買了財務模塊，ERP和數據庫都是部署在一臺機器上，跟其他業務系統如官網等是分開隔離的。另外購買商業ERP系統的時候，供應商在實施的時候，一定要讓最好熱備(或是冷備)和數據庫相關的備份，避免單點故障導致整個公司的ERP系統難以運作影響正常經營。

總結

以上是生活随笔為你收集整理的从0开始搭建坚不可摧的Web系统主流架构的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。