大型網(wǎng)站架構(gòu)設(shè)計與分析案例匯總-全文預(yù)覽
【正文】 相冊一臺服務(wù)器，留言一臺服務(wù)器? 七 .看好你的程序員，如果沒有很好的激勵措施的話你的程序員很容易寫出敷衍性的代碼，而這個可能就是將來的大患，程序架構(gòu)定下來后要修改可能就要費牛勁了。不要小看這幾十秒，問題很大的，如果站點有交互式功能，比如 IM，可以想象一下是個什么結(jié)果。幾個建議? 四 .中國國情考慮，這個最致命，需要考慮電信和網(wǎng)通的問題，CDN并不能解決所有問題。? 二 .設(shè)計好程序架構(gòu)，找個高人指導(dǎo)一下，保持良好的擴(kuò)展性，考慮節(jié)約成本的話可以找兼職的系統(tǒng)架構(gòu)設(shè)計師做好系統(tǒng)架構(gòu)，確定將來的發(fā)展瓶頸。 (有海量訪問經(jīng)驗的 CTO不多 )。D公司? D公司是一個各個方面做的比較好的公司，做了 CDN加速；圖片也獨立分出了 N個服務(wù)器；數(shù)據(jù)庫不錯 (CTO是數(shù)據(jù)庫專家），系統(tǒng)崩潰的原因在于 WEB，按道理說 WEB很容易做集群的，但是發(fā)現(xiàn)集群并解決不掉問題，他們的集群只允許做 4臺的WEB集群，但是 4臺都當(dāng)?shù)袅恕Ｏ到y(tǒng)崩潰的原因其實很簡單，由于采用的是微軟的 SqlServer，而微軟直接就告訴了我們，SQLSERVER不支持集群（ 2023），他們的數(shù)據(jù)庫超負(fù)載， 100%就沒有下去過，只能橫向增加配置，采用了 4路 4核 CPU系統(tǒng)，但是系統(tǒng)還是崩潰了 ... 高互動注定了高負(fù)載。? 解決方案：修改程序架構(gòu)，做分布式文件存貯（程序修改用了 8天，但是文件轉(zhuǎn)移卻又用去了將近一個月）， 20萬用戶損失殆盡。? 結(jié)論： ，應(yīng)該認(rèn)真考慮一下底層和數(shù)據(jù)結(jié)構(gòu)。? 例如： SNS網(wǎng)站，當(dāng)一筆筆投資砸進(jìn)去的時候，當(dāng)流量上去的時候，困惑在什么地方？除了頁面靜態(tài)化，緩存和代碼安全等問題，討論一下發(fā)展之后的問題。在 IP世界，業(yè)務(wù)類型由終端 TCP或 UDP端口地址來決定，在第四層交換中的應(yīng)用區(qū)間則由源端和終端 IP地址、 TCP和 UDP端口共同決定。負(fù)載均衡技術(shù)發(fā)展了多年，有很多專業(yè)的服務(wù)提供商和產(chǎn)品可以選擇：? 硬件四層交換：第四層交換使用第三層和第四層信息包的報頭信息，根據(jù)應(yīng)用區(qū)間識別業(yè)務(wù)流，將整個區(qū)間段的業(yè)務(wù)流分配到合適的應(yīng)用服務(wù)器進(jìn)行處理。不同的 Web服務(wù)器、數(shù)據(jù)庫服務(wù)器及 Web編程語言都有自己不同的緩沖策略。我們在應(yīng)用程序中安裝業(yè)務(wù)和應(yīng)用或者功能模塊將數(shù)據(jù)庫進(jìn)行分離，不同的模塊對應(yīng)不同的數(shù)據(jù)庫或者表，再按照一定的策略對某個頁面或者功能進(jìn)行更小的數(shù)據(jù)庫散列，比如用戶表，按照用戶 ID進(jìn)行表散列，這樣就能夠低成本的提升系統(tǒng)的性能并且有很好的擴(kuò)展性。但是，在面對大量訪 問的時候，數(shù)據(jù)庫的瓶頸仍然會顯現(xiàn)出來，這時一臺數(shù)據(jù)庫將很快無法滿足應(yīng)用，于是我們需要借助于數(shù)據(jù)庫集群或者庫表散列技術(shù)。大型網(wǎng)站開發(fā)時的幾點建議 ? 存儲問題 ? 存儲也是一個大問題，一種是小文件的存儲，比如圖片這類；另一種是大文件的存儲，比如搜索引擎的索引。大型網(wǎng)站開發(fā)時的幾點建議 ? 頁面靜態(tài)化 ? 不要小看純靜態(tài)化的 HTML頁面！其實在很多情況下， HTML往往意味著 “效率最高、消耗最小 ”，所以我們盡可能使我們的網(wǎng)站上的頁面采用靜態(tài)頁面來實現(xiàn)。用 Amazon當(dāng)家人貝索斯的話說就是， “在現(xiàn)實世界的商店最有力的武器就是地段，地段，地段，而對于我們來說最重要的三件事就是技術(shù)，技術(shù)，技術(shù)。 2023年到現(xiàn)在，世界網(wǎng)絡(luò)業(yè)腥風(fēng)血雨。MySpace? 事實上， MySpace的 Web服務(wù)器和數(shù)據(jù)庫仍然經(jīng)常發(fā)生超負(fù)荷，其用戶頻繁遭遇 “意外錯誤 ”和 “站點離線維護(hù) ”等告示，他們不得不在論壇抱怨 …? MySpace正是在這樣不斷重構(gòu)站點軟件、數(shù)據(jù)庫和存儲系統(tǒng)中，才一步步走到今天。 SAN的引入解決了早期一些性能問題，但站點目前的要求已經(jīng)開始周期性超越 SAN的 I/O容量 —— 即它從磁盤存儲系統(tǒng)讀寫數(shù)據(jù)的極限速度。據(jù) MySpace的技術(shù)人員說，以后還可以按照這種模式以更小粒度劃分架構(gòu)，從而優(yōu)化負(fù)荷分擔(dān)?，F(xiàn)在，數(shù)據(jù)庫模型里只有一個用戶表，支持博客、個人資料和其他核心功能的數(shù)據(jù)都存儲在相同數(shù)據(jù)庫。這項措施極大提升了系統(tǒng)性能、正常運行時間和可靠性。這種方式在一段時間內(nèi)效果很好 —— 只要增加數(shù)據(jù)庫服務(wù)器，加大硬盤，就可以應(yīng)對用戶數(shù)和訪問量的增加。但到在 2023年早期，在 MySpace用戶數(shù)增長到五十萬后，其數(shù)據(jù)庫服務(wù)器已經(jīng)開始疲于奔命了。? 如果系統(tǒng)沒有數(shù)據(jù)庫，只是一個 broker，轉(zhuǎn)接者，使用 JMS比多線程強(qiáng)，不宜用多線程。 Spring會產(chǎn)生大量垃圾，頻繁啟動垃圾回收機(jī)制，系統(tǒng)的響應(yīng)就得暫停， Spring的動態(tài)代理 Proxy對象是每個請求信號都會產(chǎn)生的， 1分鐘處理 1000筆交易，那么一分鐘內(nèi)至少 1000個 Proxy對象，還有其他附帶對象，內(nèi)存可能不能支持。 ATM是使用TCP/IP協(xié)議的，而網(wǎng)銀是 協(xié)議的。 ? 建議：– 兩個團(tuán)隊組合成一個團(tuán)隊（虛擬的，相當(dāng)于遠(yuǎn)程協(xié)同開發(fā)），要共享需求任務(wù)列表。– 技術(shù)上，業(yè)務(wù)的變動必然帶來領(lǐng)域模型的變動。1分析、建議? 分析：– 主要是項目管理組織的問題。1問題? 問題：– 該項目目前的開發(fā)方式和現(xiàn)狀，效率相當(dāng)?shù)拖隆? 表現(xiàn)：– B方對需求的理解不完善，導(dǎo)致 SP經(jīng)常改動。? 開發(fā)模式： MVC模式三層都有 A方開發(fā)， A方的查詢業(yè)務(wù)基本上依賴于 SP， SP由 B方方面開發(fā)。即使B方修改了 SP第一時間通知 A方， A方修改相應(yīng)的模型層對象，重新構(gòu)造層與層之間的訪問參數(shù)以及返回類型也是相當(dāng)費時的事情。 A方需要做領(lǐng)域業(yè)務(wù)，但只能按照 B方的文檔來開發(fā)，甚至都不用知道業(yè)務(wù)。加之雙方?jīng)]有持續(xù)集成，很可
教學(xué)課件相關(guān)推薦
鄂ICP備17016276號-1