<var id="rhdfd"><strike id="rhdfd"><thead id="rhdfd"></thead></strike></var>
<cite id="rhdfd"><video id="rhdfd"><menuitem id="rhdfd"></menuitem></video></cite>
<var id="rhdfd"></var>
<var id="rhdfd"><video id="rhdfd"></video></var>
<var id="rhdfd"><dl id="rhdfd"><listing id="rhdfd"></listing></dl></var><var id="rhdfd"></var><var id="rhdfd"></var>
<var id="rhdfd"></var>
<menuitem id="rhdfd"></menuitem>
<var id="rhdfd"><strike id="rhdfd"><thead id="rhdfd"></thead></strike></var><var id="rhdfd"><video id="rhdfd"></video></var>
<cite id="rhdfd"><video id="rhdfd"><menuitem id="rhdfd"></menuitem></video></cite>
<var id="rhdfd"></var>
<cite id="rhdfd"><span id="rhdfd"><menuitem id="rhdfd"></menuitem></span></cite><var id="rhdfd"></var>

網站建設資訊

聯系我們

相關推薦

網站建設資訊

首頁 > 新聞動態 > 網站建設資訊 > >

大型網站要怎么設計

發布日期:2017-08-24來源:www.bikipduongtrangda.com

  假如說1980年代是PC的時代,1990年代是互聯網的時代,那么當下呢?當下是移動互聯網的時代。移動互聯網的基本要義,一言以蔽之,就是把手機與網站相連,每部手機在網站上都有獨立的個人空間,成為手機的鏡像。

  一部小小的手機里面,可能同時裝載著數十個軟件。而且在同一時刻,可能好幾個軟件在同時運行。另外,還得時刻預備暫停運行,把手機CPU等資源讓給電話通話等優先級別高的工作。還有,時刻需要預備應付網絡連接中斷,手機電池耗盡等等情況??傊?,手機軟件的結構設計,是做小的藝術。

  移動網站的架構設計,與手機軟件的架構設計有著本質的不同。假如說手機軟件的特點在于小,那么網站的特點在于大。僅中國就有幾億手機用戶,作為服務于移動業務的網站,它的質量來自于是否能夠同時為大規模并發用戶提供服務,是否能夠處理海量數據,是否能夠在需要擴大網站吞吐量的時候,只需要增加機器,而不需要對網站架構做大手術。這是做大的藝術。

  提到做大規模網站,大家一定會想到云計算,想到Google File System,Chubby, BigTable,MapReduce等等。這些技術固然很好,但是它們僅僅是構成一個大型網站的技術要素。實際構建一個大型網站時,光知道技術要素是不夠的,還得明白如何把各個要素有機地結合到一起。

  “Flickr 網站架構研究”是一篇值得反復閱讀的好文章。這篇文章不僅對一個大型網站的架構進行了系統解剖,逐條梳理,而且行文深進淺出??上н@樣的文章未幾見。關于大型網站實例的討論,散落在各處,而且內容零散。

  學習和把握構建大型網站的架構,需要匯總散落的文章,梳理零散的內容。做好這項工作很有意義,但是也比較困難。我們的體會是,不妨捉住以下幾個主題,逐個分析大型網站的實例,然后橫向比較。

  數據存儲歷來是麻煩,尤其是需要存儲海量數據的時候,往往單個數據庫容量不夠,甚至一個數據庫集群也不夠。常見的解決辦法是分割,譬如按用戶ID把海量數據分割成若干塊,每塊存儲到一個獨立的數據庫里往。但是分割的做法降低了join操縱的效率。

  Google Bigtable的效率如何?好處是什么,缺陷是什么?Bigtable對什么樣的情景最適用?根據Bigtable原理實現的開源軟件,Hadoop/HBase的運行效率如何?

  用戶訪問網站時,通常讀的操縱比寫的操縱更頻繁。為了進步讀的操縱,不妨把相關內容緩存到內存里,減少Disk IO的消耗。

  MemCached 最近大熱,Wikipedia, YouTube, Digg, Twitter等等大型網站都在用MemCached作為緩存工具。SquidCache和Varnish等等工具,也與緩存沾邊。Twitter的做法是把MemCached和Varnish結合起來,同時使用。什么樣的內容,應該用什么樣的緩存工具?不同的工具間如何協調?各大網站的實際運行的結果,有哪些經驗和教訓?

  有些內容,既沒必要存放在數據庫里,也不適合存放在緩存中,譬如log 和images。在這種情況下,我們需要文件系統。當有海量內容需要存放在文件系統中時,我們需要使用分布式文件系統。Google File System對于什么樣的情景適用,什么樣的情景不適用?分布式文件系統經常需要相應的鎖機制,保證并發的讀寫操縱不相互干擾。Chubby有什么好處?什么情形下不適用?

  據說MogileFS更適合存儲大量的,但是單體尺寸不大的文件,譬如images。而Google File System更適合存放大尺寸但是數目未幾的文件。有沒有可能把小尺寸的多個文件,合并成一個大文件,然后存儲到Google File System中往。在這種情況下,比較MogileFS與Google FS的性能,是否有高下之分?

 

網站建設

  一套工序通常由若干任務組成。多線程的辦法是由一根線程全權負責整套工序的操縱。另外一個辦法是把工序斬成幾段,每一段由一根或幾根線程負責,這種辦法稱為工作臺。

  常見的是多線程的辦法。但是工作臺的做法有利于集中計算資源處理繁重的任務,避免瓶頸的出現。但是缺陷是需要在不同線程之間,傳遞記錄中間狀態的數據。么樣的情形適適用多線程,什么時候用工作臺?

  同一個網站通常會提供多種服務,不同的服務需要調用不同的業務邏輯。有些業務邏輯可以在同一臺服務器上完成,但是當業務邏輯復雜的時候,需要調用多臺服務器合作完成。不同服務的受眾對象不同,流量也不同,不同時段的流量也不同,同一時段不同服務的流量也不同,所以需要動態地分配計算資源。這是 scheduler的工作。

  Scheduler給不同服務器分配工作時,最簡單的辦法是啟動預先安裝在該服務器上的相關程序。由于不能保證每個程序都十分完美,當一個程序發生錯誤時,應當避免整個服務器因此而崩潰,影響其它工作的正常進行。是否需要動用virtual machine,實現各個不同工作之間相互隔盡?

  大型網站后臺系統經常由眾多服務器組成,服務器與服務器之間時不時會發生數據交換,譬如Web Server解析完用戶請求后,把請求轉發給某一臺App Server,這一臺App Server完成了部分工作后,把中間數據轉發給下一臺App Server。而第二臺App Server完成任務后,整個工作就結束了,結果應該返回給Web Server。

  題目是如何讓第一臺App Server如何知道應該把中間結果給第二臺App Server,而第二臺App Server又如何知道它的目的地是Web Server?一個比較有效率的做法,是區別數據流和控制流。Server與Server之間常設通道,專供控制流使用,傳遞指令往控制數據流的發送。數據流不占用控制流通道,只有在需要時,才建立數據流的通道??刂屏骱蛿祿鞯慕M織,需要結合具體的業務邏輯,才能優化設計,減少帶寬消耗,縮短數據傳輸的時間。

  網站后臺各個部分是否運轉正常,哪里是瓶頸,哪里空閑。這些都需要實時監控。不僅及時避免整個后臺系統的崩潰,而且可以分析各個部分運行的規律,從而找到優化系統的途徑。題目是,應該選用什么樣的監控工具,才能夠盡量減少對系統程序的干擾,同時提供有價值的信息?

  通常網站面對的是形形色色的用戶,盡大多數用戶的行為是友好的,但是不排除少數用戶蓄意惡作劇。假如事先沒有設計防范措施,少數惡意用戶的胡作非為,會干擾其他用戶享受正常的服務。

  題目是,如何防范并且及時制止惡意行為的發生?

  不論預先設想有多周密,實際運行時,總會碰到這樣那樣的意外情況。譬如敏感詞的出現,往往事先沒有征兆。所以,在設計系統架構時,應該給網管提供必要工具,應付突發事件。


案例推薦:

在線咨詢

業務咨詢微信
返回頂部