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

本文根據DBAplus社群第92期線上分享整理而成。

 

講師介紹  

戰學超

青航數據架構師

 

• 曾任職於NEC軟件、海爾B2B平台巨商匯，負責企業數據平台構建、B2B電商平台數據管理與搭建。

• 擁有豐富DBA、係統運維架構經驗，擅長數據庫、數據平台搭建、私有雲部署、自動化運維等。

 

主題簡介：

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係統難以運作影響正常經營。