剛剛進(jìn)入了一家新公司，哎在上?；炝诉@么多年，終于到了一家像樣的公司，想想這個(gè)過(guò)程還真不容易啊，一定得要好好珍惜了，不廢話了，開(kāi)始我的內(nèi)容了。

　　我現(xiàn)在的項(xiàng)目組的確是做純正大網(wǎng)站的項(xiàng)目組，雖然現(xiàn)在還沒(méi)做開(kāi)發(fā)，對(duì)公司框架還沒(méi)完全熟悉，但是對(duì)公司的架構(gòu)的初步了解（初解）覺(jué)得還真有價(jià)值，都說(shuō)大型網(wǎng)站應(yīng)用的開(kāi)發(fā)和普通的web項(xiàng)目不一樣，但是你沒(méi)有做過(guò)大型網(wǎng)站終究還是不能理解它的技術(shù)結(jié)構(gòu)和我們常用的技術(shù)框架結(jié)構(gòu)有何不同。在講之前我要申明：我是一名java工程師，所以我講的技術(shù)都是以java技術(shù)為基礎(chǔ)，或許其他技術(shù)實(shí)現(xiàn)同樣的功能會(huì)有所不同，但我相信主要思想一定是相似的。

　　普通的javaweb項(xiàng)目就是按照mvc模式進(jìn)行的，在前面的博文里我也寫了一個(gè)非常簡(jiǎn)單的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)都會(huì)有一個(gè)瓶頸區(qū)，因此導(dǎo)致一些更加有效的優(yōu)化和安全處理實(shí)在很難進(jìn)行下去，而更大型的項(xiàng)目往往會(huì)對(duì)優(yōu)化和安全要求更高，這樣的項(xiàng)目狀態(tài)實(shí)在很難滿足大型項(xiàng)目的需求。

　　我新公司的框架里對(duì)于這樣的局限性有了一種很好的解決方案，下面是我新公司技術(shù)框架的架構(gòu)圖（這是我自己畫的，時(shí)間倉(cāng)促畫的不好還請(qǐng)大伙多多包含了）：

　　我現(xiàn)在定位主要做前端，所以對(duì)于后臺(tái)的服務(wù)端與數(shù)據(jù)庫(kù)的交互是不是也是通過(guò)通訊層來(lái)進(jìn)行的這個(gè)我不太確定，不過(guò)我個(gè)人認(rèn)為不太會(huì)，因?yàn)槿绻褦?shù)據(jù)庫(kù)和程序之間的sql語(yǔ)句替換成通信報(bào)文，這是一件太難的事情，而且效果往往也不太好，所以我的理解是后臺(tái)服務(wù)器和數(shù)據(jù)庫(kù)沒(méi)有別的通訊層，對(duì)于java而言就是直接通過(guò)jdbc對(duì)數(shù)據(jù)庫(kù)進(jìn)行操作，另外客戶機(jī)到前端服務(wù)器集群直接的路由設(shè)備，我個(gè)人猜測(cè)這個(gè)路由設(shè)備大致完成下面的工作：

　　解析域名，找到對(duì)應(yīng)的ip地址列表，這就是通常所說(shuō)的DNS吧；

　　對(duì)客戶的請(qǐng)求做負(fù)載均衡操作。大型的工作這些操作更多還是通過(guò)硬件設(shè)備完成，而小點(diǎn)的公司估計(jì)是通過(guò)軟件來(lái)實(shí)現(xiàn)。

　　（對(duì)于上面的內(nèi)容，我個(gè)人了解不多，但是很感興趣如果有那位童鞋了解這些可以給我講解下。）

　　這樣的架構(gòu)帶來(lái)的好處有那些了，這里我把我知道的總結(jié)如下（如果那位童鞋有更好的意見(jiàn)可以補(bǔ)充?。?/p>

　　前端和服務(wù)端獨(dú)立成項(xiàng)，那么如果客戶訪問(wèn)的是靜態(tài)資源可以不用請(qǐng)求到服務(wù)端程序，而是從客戶端處理完直接返回到客戶端，當(dāng)遇到服務(wù)端請(qǐng)求時(shí)候就會(huì)和服務(wù)端通信，這樣的結(jié)果會(huì)使系統(tǒng)更快，因?yàn)殪o態(tài)資源的訪問(wèn)速度總會(huì)比服務(wù)端要快。這樣就處分了不同性質(zhì)請(qǐng)求，可以讓我們根據(jù)***的辦法處理不同客戶端請(qǐng)求。

　　前端程序和服務(wù)端程序之間有一個(gè)通訊層，也就是說(shuō)前端程序和服務(wù)端程序不是直接進(jìn)行訪問(wèn)的，它們之間有我們專門編寫的通訊協(xié)議（數(shù)據(jù)報(bào)文），那么如果黑客侵入到了客戶端，想通過(guò)客戶端程序直接訪問(wèn)服務(wù)端的數(shù)據(jù)不是那么容易了，這樣大大的提高了系統(tǒng)的安全性。這里附帶提一下，很高興新公司的架構(gòu)里通訊報(bào)文是采取的json格式很符合我前面博文里講到的用鍵值對(duì)做通訊格式的構(gòu)想。

　　按照網(wǎng)絡(luò)安全的要求，大型網(wǎng)站的核心服務(wù)器一般都不是和外網(wǎng)相連，核心服務(wù)器集群往往是在一個(gè)獨(dú)立內(nèi)網(wǎng)環(huán)境，和外網(wǎng)的溝通都是通過(guò)一些特殊授權(quán)的服務(wù)器進(jìn)行，這樣能保證整個(gè)核心服務(wù)器集群不會(huì)被外人輕易的訪問(wèn)到，服務(wù)端程序和客戶端程序的分離正好體現(xiàn)了這個(gè)原理，服務(wù)端程序往往都是系統(tǒng)的核心所在，它和客戶端的通訊要通過(guò)我們的客戶端程序，這對(duì)于我們建立合理的安全保障機(jī)制提供了方便。

　　我想很多童鞋估計(jì)都做過(guò)大型網(wǎng)站的開(kāi)發(fā)，所以上面這些內(nèi)容對(duì)這樣的童鞋一定不陌生，或許有些人還會(huì)覺(jué)得我的見(jiàn)解很淺陋吧，其實(shí)我到現(xiàn)在還沒(méi)做過(guò)真正的大型的網(wǎng)站項(xiàng)目，更不用說(shuō)大型網(wǎng)站的架構(gòu)設(shè)計(jì)，所以對(duì)這些很新奇。不過(guò)當(dāng)我看我公司的技術(shù)架構(gòu)的確是眼前一亮，這個(gè)亮眼之處倒不是我上面提到的這些而是他們對(duì)maven的使用，公司的前輩們用maven很好組織了整個(gè)項(xiàng)目的技術(shù)架構(gòu)。大家可以試試想想，不管你的系統(tǒng)設(shè)計(jì)的如何復(fù)雜它們畢竟只有被組合起來(lái)才是一個(gè)完整的項(xiàng)目，把一個(gè)大項(xiàng)目拆分成若干小項(xiàng)目這樣的思想固然很好，但是實(shí)際開(kāi)發(fā)中這樣做卻是困難叢叢啊。假如我們把每塊都獨(dú)立立項(xiàng)，大伙都分頭行事，做完后在一起聯(lián)調(diào)合并，我想結(jié)果肯定是痛苦的，痛苦的原因就是軟件標(biāo)準(zhǔn)化在中國(guó)實(shí)在太難，各個(gè)不同項(xiàng)目組獨(dú)立開(kāi)發(fā)一定會(huì)帶來(lái)各個(gè)項(xiàng)目之間異構(gòu)性的問(wèn)題，異構(gòu)性導(dǎo)致合并項(xiàng)目很不容易，而解決異構(gòu)性的辦法就是有效的溝通，但這樣的溝通成本或許會(huì)成為我們開(kāi)發(fā)人員們不能承受之痛。

　　公司的架構(gòu)是通過(guò)maven來(lái)進(jìn)行管理的，架構(gòu)里包含了若干的項(xiàng)目，其中有一個(gè)項(xiàng)目是其他項(xiàng)目的根項(xiàng)目，其他項(xiàng)目之間也存在各種不同的依賴關(guān)系，大伙看下圖，這個(gè)用語(yǔ)言實(shí)在說(shuō)不清楚:

　　通過(guò)maven就能把這些項(xiàng)目很好的融合到一起，我們只要構(gòu)建了根項(xiàng)目那么整個(gè)項(xiàng)目都會(huì)被成功的構(gòu)建。而且還能把項(xiàng)目里公共的部分抽取出來(lái)，形成通用模塊，讓我們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í)，說(shuō)干就干，馬上開(kāi)始。

當(dāng)前文章：對(duì)大型網(wǎng)站技術(shù)架構(gòu)的初解
網(wǎng)頁(yè)路徑：http://uogjgqi.cn/article/djcciie.html