對大型網(wǎng)站技術(shù)架構(gòu)的初解
剛剛進(jìn)入了一家新公司，哎在上海混了這么多年，終于到了一家像樣的公司，想想這個(gè)過程還真不容易啊，一定得要好好珍惜了，不廢話了，開始我的內(nèi)容了。
我現(xiàn)在的項(xiàng)目組的確是做純正大網(wǎng)站的項(xiàng)目組，雖然現(xiàn)在還沒做開發(fā)，對公司框架還沒完全熟悉，但是對公司的架構(gòu)的初步了解（初解）覺得還真有價(jià)值，都說大型網(wǎng)站應(yīng)用的開發(fā)和普通的web項(xiàng)目不一樣，但是你沒有做過大型網(wǎng)站終究還是不能理解它的技術(shù)結(jié)構(gòu)和我們常用的技術(shù)框架結(jié)構(gòu)有何不同。在講之前我要申明：我是一名java工程師，所以我講的技術(shù)都是以java技術(shù)為基礎(chǔ)，或許其他技術(shù)實(shí)現(xiàn)同樣的功能會有所不同，但我相信主要思想一定是相似的。
普通的javaweb項(xiàng)目就是按照mvc模式進(jìn)行的，在前面的博文里我也寫了一個(gè)非常簡單的ssi的框架（struts2+ibatis+spring），這種架構(gòu)只適合中小心的管理軟件或者是中小型的網(wǎng)站，到了大點(diǎn)的應(yīng)用項(xiàng)目它的局限性就大了。我今天仔細(xì)想想，這個(gè)局限性的癥結(jié)就是不管我們?nèi)绾谓g盡腦汁為項(xiàng)目進(jìn)行邏輯分層從而降低層與層之間的耦合度，任然擺脫不了各個(gè)邏輯層任然在同一個(gè)項(xiàng)目下面的現(xiàn)實(shí)，這就導(dǎo)致各層的耦合度永遠(yuǎn)都會有一個(gè)瓶頸區(qū)，因此導(dǎo)致一些更加有效的優(yōu)化和安全處理實(shí)在很難進(jìn)行下去，而更大型的項(xiàng)目往往會對優(yōu)化和安全要求更高，這樣的項(xiàng)目狀態(tài)實(shí)在很難滿足大型項(xiàng)目的需求。
我新公司的框架里對于這樣的局限性有了一種很好的解決方案，下面是我新公司技術(shù)框架的架構(gòu)圖（這是我自己畫的，時(shí)間倉促畫的不好還請大伙多多包含了）：
我現(xiàn)在定位主要做前端，所以對于后臺的服務(wù)端與數(shù)據(jù)庫的交互是不是也是通過通訊層來進(jìn)行的這個(gè)我不太確定，不過我個(gè)人認(rèn)為不太會，因?yàn)槿绻褦?shù)據(jù)庫和程序之間的sql語句替換成通信報(bào)文，這是一件太難的事情，而且效果往往也不太好，所以我的理解是后臺服務(wù)器和數(shù)據(jù)庫沒有別的通訊層，對于java而言就是直接通過jdbc對數(shù)據(jù)庫進(jìn)行操作，另外客戶機(jī)到前端服務(wù)器集群直接的路由設(shè)備，我個(gè)人猜測這個(gè)路由設(shè)備大致完成下面的工作：
解析域名，找到對應(yīng)的ip地址列表，這就是通常所說的DNS吧；
對客戶的請求做負(fù)載均衡操作。大型的工作這些操作更多還是通過硬件設(shè)備完成，而小點(diǎn)的公司估計(jì)是通過軟件來實(shí)現(xiàn)。
?。▽τ谏厦娴膬?nèi)容，我個(gè)人了解不多，但是很感興趣如果有那位童鞋了解這些可以給我講解下。）
這樣的架構(gòu)帶來的好處有那些了，這里我把我知道的總結(jié)如下（如果那位童鞋有更好的意見可以補(bǔ)充?。?/p>
前端和服務(wù)端獨(dú)立成項(xiàng)，那么如果客戶訪問的是靜態(tài)資源可以不用請求到服務(wù)端程序，而是從客戶端處理完直接返回到客戶端，當(dāng)遇到服務(wù)端請求時(shí)候就會和服務(wù)端通信，這樣的結(jié)果會使系統(tǒng)更快，因?yàn)殪o態(tài)資源的訪問速度總會比服務(wù)端要快。這樣就處分了不同性質(zhì)請求，可以讓我們根據(jù)***的辦法處理不同客戶端請求。
前端程序和服務(wù)端程序之間有一個(gè)通訊層，也就是說前端程序和服務(wù)端程序不是直接進(jìn)行訪問的，它們之間有我們專門編寫的通訊協(xié)議（數(shù)據(jù)報(bào)文），那么如果黑客侵入到了客戶端，想通過客戶端程序直接訪問服務(wù)端的數(shù)據(jù)不是那么容易了，這樣大大的提高了系統(tǒng)的安全性。這里附帶提一下，很高興新公司的架構(gòu)里通訊報(bào)文是采取的json格式很符合我前面博文里講到的用鍵值對做通訊格式的構(gòu)想。
按照網(wǎng)絡(luò)安全的要求，大型網(wǎng)站的核心服務(wù)器一般都不是和外網(wǎng)相連，核心服務(wù)器集群往往是在一個(gè)獨(dú)立內(nèi)網(wǎng)環(huán)境，和外網(wǎng)的溝通都是通過一些特殊授權(quán)的服務(wù)器進(jìn)行，這樣能保證整個(gè)核心服務(wù)器集群不會被外人輕易的訪問到，服務(wù)端程序和客戶端程序的分離正好體現(xiàn)了這個(gè)原理，服務(wù)端程序往往都是系統(tǒng)的核心所在，它和客戶端的通訊要通過我們的客戶端程序，這對于我們建立合理的安全保障機(jī)制提供了方便。
我想很多童鞋估計(jì)都做過大型網(wǎng)站的開發(fā)，所以上面這些內(nèi)容對這樣的童鞋一定不陌生，或許有些人還會覺得我的見解很淺陋吧，其實(shí)我到現(xiàn)在還沒做過真正的大型的網(wǎng)站項(xiàng)目，更不用說大型網(wǎng)站的架構(gòu)設(shè)計(jì)，所以對這些很新奇。不過當(dāng)我看我公司的技術(shù)架構(gòu)的確是眼前一亮，這個(gè)亮眼之處倒不是我上面提到的這些而是他們對maven的使用，公司的前輩們用maven很好組織了整個(gè)項(xiàng)目的技術(shù)架構(gòu)。大家可以試試想想，不管你的系統(tǒng)設(shè)計(jì)的如何復(fù)雜它們畢竟只有被組合起來才是一個(gè)完整的項(xiàng)目，把一個(gè)大項(xiàng)目拆分成若干小項(xiàng)目這樣的思想固然很好，但是實(shí)際開發(fā)中這樣做卻是困難叢叢啊。假如我們把每塊都獨(dú)立立項(xiàng)，大伙都分頭行事，做完后在一起聯(lián)調(diào)合并，我想結(jié)果肯定是痛苦的，痛苦的原因就是軟件標(biāo)準(zhǔn)化在中國實(shí)在太難，各個(gè)不同項(xiàng)目組獨(dú)立開發(fā)一定會帶來各個(gè)項(xiàng)目之間異構(gòu)性的問題，異構(gòu)性導(dǎo)致合并項(xiàng)目很不容易，而解決異構(gòu)性的辦法就是有效的溝通，但這樣的溝通成本或許會成為我們開發(fā)人員們不能承受之痛。
公司的架構(gòu)是通過maven來進(jìn)行管理的，架構(gòu)里包含了若干的項(xiàng)目，其中有一個(gè)項(xiàng)目是其他項(xiàng)目的根項(xiàng)目，其他項(xiàng)目之間也存在各種不同的依賴關(guān)系，大伙看下圖，這個(gè)用語言實(shí)在說不清楚:
通過maven就能把這些項(xiàng)目很好的融合到一起，我們只要構(gòu)建了根項(xiàng)目那么整個(gè)項(xiàng)目都會被成功的構(gòu)建。而且還能把項(xiàng)目里公共的部分抽取出來，形成通用模塊，讓我們server和client項(xiàng)目進(jìn)行瘦身，讓我們的核心項(xiàng)目更加的健壯。
Maven以前我不太熟悉，今天我發(fā)現(xiàn)這個(gè)技術(shù)是很值得學(xué)習(xí)的，它和ant相比，maven站的高度更高，甚至可以影響到你程序的架構(gòu)設(shè)計(jì)，我就想做成架構(gòu)師，而且要是大型系統(tǒng)的架構(gòu)師，那么maven一定要好好學(xué)習(xí)，說干就干，馬上開始。
原文鏈接：http://www.cnblogs.com/sharpxiajun/archive/2012/01/15/2322668.html
【編輯推薦】
