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