1. 常見的網路架構有哪些
常見的網路拓撲結構有以下幾種：1.匯流排型網路拓撲結構；2.星型網路拓撲結構；3.環形網路拓撲結構；4.樹型網路拓撲結構；5.網狀網路拓撲結構；6.混合網路型拓撲結構。網路拓撲結構是指用傳輸媒體對各種設備進行連接的物理布局。
1.匯流排型網路拓撲結構
匯流排型結構是將網路中的所有設備通過相應的硬體介面直接連接到公共匯流排上，結點之間按廣播方式通信，一個結點發出的信息，匯流排上的其它結點均可「收聽」到。 匯流排型結構就像一張樹葉,有一條主幹線,主幹線上面由很多分支。
2.星型網路拓撲結構
星型結構是一種以中央節點為中心，把若干外圍節點連接起來的輻射式互聯結構。這種結構適用於區域網，特別是近年來連接的區域網大都採用這種連接方式。這種連接方式以雙絞線或同軸電纜作連接線路。
3.環形網路拓撲結構
環形結構各結點通過通信線路組成閉合迴路，環中數據只能單向傳輸，信息在每台設備上的延時時間是固定的，特別適合實時控制的區域網系統。環形結構就如一串珍珠項鏈,環形結構上的每台計算機就是項鏈上的一個個珠子。
4.樹型網路拓撲結構
樹型拓撲結構是一種層次結構，結點按層次連結，信息交換主要在上下結點之間進行，相鄰結點或同層結點之間一般不進行數據交換。樹型拓撲結構是就是數據結構中的樹。
5.網狀網路拓撲結構
網路拓撲結構又稱作無規則結構，結點之間的聯結是任意的，沒有規律。
6.混合網路型拓撲結構
混合型網路拓撲結構就是指同時使用上面的5種網路拓撲結構種兩種或兩種以上的網路拓撲結構。
2. 當前比較流行的網站架構有哪些
目前功能相似的能解決同類需求的主要是國外的開源框架，如Bootstrap、Foundation、Semantic UI。Bootstrap是由Twitter在2011年8月推出的開源WEB前端框架，集合CSS和HTML，使用了最新的瀏覽器技術，為快速WEB開發提供了一套前端工具包，包括布局、網格、表格、按鈕、表單、導航、提示，其核心就是基於Less框架構建的CSS。Bootstrap框架擁有美觀的樣式和封裝完善的JQ插件，使用方便，基於Bootstrap的擴展也很多，這是其他框架所無法比擬的，也是其最受歡迎的條件之一。
Foundation宣稱是世界最好的響應式前端框架，默認支持5種網格布局，是三款框架中最復雜也是最靈活的。Bootstrap默認支持四種網格布局，Pure默認支持一種。
Semantic UI是語義化設計的前端框架，開發更加直觀，UI組建可實時調試輸出，其最大的特點是充分利用CSS3動畫特效，簡潔實用漂亮的樣式。以上各種產品我們也用過，當時我們發現全球有將近6%的網站是基於Bootstrap做的。不過對於中國開發者來說，Bootstrap門檻仍然較高，而且本土化支持不夠好。
首先，Bootstrap只支持英文字體，並沒有對中文字體做設置。在不同操作系統、不同瀏覽器下，默認的中文字體可能是不一樣的，這樣會導致網頁在某些時候顯示得不太好看。而且英文字型大小和中文字型大小的大小也不一樣，直接用Bootstrap來做文字排版並不能達到最好的效果。另外，國內瀏覽器種類繁多，Bootstrap也無法照顧到對國內瀏覽器的支持，我們希望不斷加強對各種本土瀏覽器的支持，幫助廣大前端開發者從最繁瑣痛苦的瀏覽器性問題中解脫出來。其次，Bootstrap還沒有把重點放在豐富界面組件上，而Amaze UI非常注重提高開發者的效率，我們會不斷增加跨屏的界面組件，讓開發者盡量少些代碼。第三，Bootstrap 因為最早是從PC端開始做的，所以有些地方是先PC後移動，而Amaze UI的思路是先移動後PC。例如，Bootstrap使用了jQuery庫，而Amaze UI使用了Zepto.js，Zepto.js的體積不到jQuery的1/3，對移動端的性能很大提升。
因此，一個針對中國市場的、移動優先的跨屏前端開發框架開發者有很強的需求，也是一個行業的空白。
Amaze UI應該是中國首個HTML5跨屏前端開發框架，其不僅兼容前幾者的優勢，還具有以下優勢：
1、加入更多符合中國市場特性的元素：中文排版更優化，兼容中國本土主流瀏覽器
2、更輕量化，不僅適用於桌面端，更適合移動端3、包含一些封裝好的Widgets，其他框架則沒有
3. 網站建設要建設哪些基本結構
一、網站目錄結構的確定
網站目錄結構的確定這點是不容忽視的，主要是指建立網站時創建的文件夾。在創建本地站點時，首先要建立本地站點根文件夾和images子文件夾，再創建多個子文件夾，然後將站點的文件分類儲存到相應的子文件夾中，而不是將所有文件都存放在根文件夾下。其實，目錄結構的好壞，對瀏覽者來說並沒有太大影響，但是對於站點本身的上傳和維護、內容的擴充和移植有著重要的影響。
目錄結構建立的好壞，對於企業後期進行網站維護是有直接聯系的，專業與不專業網站建設公司這些也是有差別的，你會發現不專業的建站公司有時候從目錄中你都找不到想要的文件夾，而專業的一看文件夾名字就可以輕而易舉找到。
二、網站鏈接結構的確定
上海雍熙認為，網站鏈接結構也是要提前確定好的，我們這里所說的網站鏈接結構主要指的是網站中各個子網頁之間相互的鏈接關系，它映射著網站主題與主題相關的內容以及網站設計者建立此站點的目的。
好的網站鏈接結構不僅可以讓訪客在瀏覽時輕松自如的進行各頁面之間的跳轉，搜索引擎在爬取的時候速度也會更快，網站收錄也會更快。說到網站鏈接結構我們不得不提麵包屑導航了。
網站建設，一般鏈接結構包含樹狀鏈接結構和星狀鏈接結構，而在進行企業建站的時候用的比較多的就是樹狀鏈接結構。從某種程度上，網站結構的好壞直接影響著搜索引擎對於這個網站收錄的快慢，所以我們在進行建站的時候要特別的注意。
4. 網站結構主要包括哪些方面
網站結構主要包括四方面：
一，友好的網站結構
1， 扁平or樹型：
2， 鏈接結構
1）首頁鏈接應該鏈向重要的頻道頁，頻道頁再鏈向下面的節點頁或普通頁面。同時，頻道頁、節點頁和普通頁面都應該可以鏈回到首頁
2）無論哪些頁面之間互相鏈接，都需要一個描述恰當的錨文本
3）鏈接不要放在JS、FLASH等搜索引擎不可見的位置，使用圖片做鏈接入口應該完善alt標簽
二，通過導航讓網路更好地認識站點
對於用戶，導航要解決的問題是：我在網站的什麼位置，我想看上一級、甚至上上一級更多內容的入口在哪裡；對於spider，導航要解決的問題是：這個頁面屬於哪個領域，要表達的主題是什麼。所以說，清晰的導航系統不僅有助於提高用戶體驗，對SEO的意義也是重大的，所有SEO做得出色的網站基本都擁有清晰明確的導航。
三，合理的domain結構
除了在網站建設的時候站長會思考到底使用二級域名還是子目錄，在網站運營的過程中，也會考慮是否要把子目錄的內容拆分成二級域名。
四，url結構很重要
1，url結構規律化：同一個網頁有不同url，會造成多個url同時被用戶推薦導致權值分散；同時網路最終選擇展現的那個url不一定符合你的預期。站點應該盡量不把sessionid和統計代碼等不必要的內容放在url，如果一定要這樣做可以通過robots禁止網路抓取這些非規范url
2，最好能讓用戶從url即可判斷出網頁內容，便於蜘蛛解析的同時便於用戶間傳播
3，url盡量短
4，不要添加蜘蛛難以解析的字元
5，動態參數不要太多太復雜，目前網路對動態url已經有了很好的處理，但是參數過多過復雜的url有可能被蜘蛛認為不重要而拋棄
5. 開發動態網站有哪幾種常用的架構
常見的web前端開發框架如下：
1、Bootstrap：
主流框架之一，Bootstrap 是基於 HTML、CSS、JavaScript的，它簡潔靈活，使得 Web 開發更加快捷。
2、html5-boilerplate：
該框架可以快速構建健壯，且適應力強的web app或網站。
3、Meteor：
Meteor是新一代的開發即時web應用的開源框架，它能在較短時間內完成開發。
4、Materialize：
基於材料設計的現代響應前端框架。可以提供默認樣式，自定義組件。此外，Materialize還改進了動畫和過渡，為開發人員提供了流暢的體驗。
5、Amaze UI：
中國首款開源HTML5跨屏前端框架產品系列，支持中文排版更好，本地組件豐富。產品線包括Amaze UI Touch，一個混合HTML5應用程序開發框架的移動應用程序，和Amaze UI Web跨屏幕HTML5網頁。
(5)網站系統架構有哪些擴展閱讀：
web框架程序的作用
Web框架使得在進行Web應用開發的時候，減少了工作量。Web框架主要用於動態網路開發，動態網路主要是指現在的主要的頁面，可以實現數據的交互和業務功能的完善。
當使用Web框架進行Web開發時，在數據緩存、資料庫訪問、數據安全驗證等方面不需要重新實現，但可以將業務邏輯相關的代碼寫入框架中。也就是說，通過主觀地「修補」Web框架，您可以實現自己的Web開發需求。
以PHP為例，您可以在apache伺服器上進行Web開發，而無需使用框架。當使用PHP打開時，資料庫連接需要在沒有框架的情況下獨立完成，頁面生成和顯示也是如此。例如，框架可以完成避免SQL注入的工作，而使用PHP，您可以在不使用框架的情況下自己完成這項工作。
6. 電子商務網站常用的系統架構哪些
前台系統包括：商品展示，內容展示，訂單確認，支付系統，用戶中心四大模塊
一. 商品展示
站內搜索(搜索提示，搜索規則，搜索成功頁，搜索不成功頁，相似推薦)
導航(頻道導航，其他導航如銷售排行，廣告位，推薦位，文字鏈，also buy等)
商品分類(品牌分類，品類分類，屬性分類如剪裁形式)
登陸頁(商品列表頁，商品詳細頁，商品活動頁)
這里的訪問邏輯是：a /b/c分流消費者去往相對個性化的頁面，由登陸頁體現商家的核心訴求和價值傳遞，完成call-to-action的第一步。
二. 內容展示：內容展示較為簡單，對純購物品牌而言包括：
公告區
幫助中心
論壇(如需商城與論壇發生交互，則需自行開發，否則可集成discuz做同步登陸即可)
三. 訂單確認
訂單確認，就是幫助消費者正確提交訂單信息的環節，看似簡單，實則非常復雜，需要對很多信息邏輯判斷和處理，一般由2個部分組成：
購物車
訂單提交(返回購物車，收貨地址&地址薄，支付方式判斷，配送方式，發票，訂單標記，實付金額計算等等)
四. 支付系統
與一般的想像不同，支付系統其實並不簡單等於第三方支付工具接入：
外部支付系統(支付寶將介面，財付通介面，網銀直聯埠，信用卡分期埠)
內部支付系統(賬戶余額，積分，禮品卡，優惠券)
支付系統的邏輯設計不但需要考慮到各種極端情況的發生(如一張訂單先用禮品卡，再用積分，最後網銀支付)，還要預留財務做賬所需的相關欄位，並充分考慮訂單取消之後如何回滾各類內部賬戶。
五. 用戶中心
用戶中心的實質是用戶自助功能的dashboard，一般4個部分組成：
注冊&登陸(快速注冊，完整注冊，注冊有禮，推薦注冊，密碼找回，主站id登陸，open-id登陸如qq，新浪微博等)
訂單中心(歷史訂單狀態，中間狀態訂單修改，物流追蹤)
服務中心(各類自助服務如退款申請，退換貨申請，建議與投訴等)
信息管理(用戶基本信息管理和賬戶信息管理)
後台系統包括：商品&促銷，crm，訂單處理，wms，采購管理，財務管理，報表管理，系統設置，wa系統9大模塊
一. 商品&促銷
商品管理(品類管理，品牌管理，單品管理)
促銷管理(活動管理和自定義活動模板管理)
在上述模塊中，最重要的是2個部分：單品管理中的批量產品生成的自動程序和活動管理中「共享與互斥」管理。前者用於大幅提升上新速度，後者避免促銷活動失控。
二. crm ：crm是對b2c核心資源—會員的管理，服務與再營銷系統，包括如下部分：
會員管理(會員信息的增刪改查和到其他系統的鏈接)
用戶關懷(條件觸發和人工觸發相關edm &簡訊& ob)
定向營銷(會員分組和營銷活動管理)
客服管理(內容非常多，集成所有需前台與後台交互的功能，詳情還是看圖吧)
呼叫中心(ivr，坐席管理，統計報表，參數傳遞與窗口嵌入)
值得注意的，edm和簡訊通道市面上已經有成熟的外包服務商，一般都會外包；呼叫中心和在線客服自行開發成本太高，特別是呼叫中心系統，業務初期也都是外包的。
三. 訂單處理：訂單處理是在訂單未正式進入倉儲部門處理之前，對訂單的前置性處理環節。
訂單錄入(電話訂購，網上下單，外部團購訂單，無金額訂單錄入如禮品單)
訂單審核(自動審核和人工審核)
rma處理(rma申請單和rma處理單)
四. wms(warehouse management system倉庫管理系統)
wms的流程很長，功能模塊也很多，大致分為入庫管理，庫存管理，出庫管理和票據管理4個模塊四個模塊
五. 采購管理
供應商管理(供應商信息管理，合同發票管理)
采購單管理(po單管理，負po單管理)
庫存管理(庫存查詢，庫存佔用單，庫存變動log)
六 .財務管理：b2c的財務管理，主要是對供應商，渠道和內部費用支出的成本控制。
供應商結算
渠道結算
配送結算
內部結算
七. 報表管理：報表是b2c業務的宏觀表現，理論上說，每個部門的kpi都應該從中找到。
搜索報表(站內搜索量查詢)
銷售報表(多個維度銷量查詢，優惠券使用情況，報表導出)
財務報表
客服報表(客服日報和坐席報表)，前者反映與消費者發生的日常交互(包括正常與異常)，後者考核客服的工作績效
倉儲物流報表，這幾塊報表，是業務運作的核心，涉及到公司機密，就不能寫的太細了，見諒。
八. 系統設置：這塊大家都知道是幹嘛的，也就不多說了，分成三塊。
基礎設置(和業務有關的一些欄位值)
許可權設置(不同賬號的操作許可權和操作記錄)
其他設置
九. wa系統(web analytcis)
網站分析系統，幾乎全是外購，很少有能夠自建的，即使自建，最多做幾個簡單的模塊。用於實戰的，要麼是免費的ga(google analytics)，要麼是昂貴的omniture。
7. 常見的網路架構有哪些
常見網路架構的有星形、匯流排形、環形和網狀形等。
1、星形網路拓撲結構：
以一台中心處理機（通信設備）為主而構成的網路，其它入網機器僅與該中心處理機之間有直接的物理鏈路，中心處理機採用分時或輪詢的方法為入網機器服務，所有的數據必須經過中心處理機。
星形網的特點：
（1）網路結構簡單，便於管理（集中式）；
（2）每台入網機均需物理線路與處理機互連，線路利用率低；
（3）處理機負載重（需處理所有的服務），因為任何兩台入網機之間交換信息，都必須通過中心處理機；
（4）入網主機故障不影響整個網路的正常工作，中心處理機的故障將導致網路的癱瘓。
適用場合：區域網、廣域網。
2、匯流排形網路拓撲結構：
所有入網設備共用一條物理傳輸線路，所有的數據發往同一條線路，並能夠由附接在線路上的所有設備感知。入網設備通過專用的分接頭接入線路。匯流排網拓撲是區域網的一種組成形式。
匯流排網的特點：
（1）多台機器共用一條傳輸信道，信道利用率較高；
（2）同一時刻只能由兩台計算機通信；
（3）某個結點的故障不影響網路的工作；
（4）網路的延伸距離有限，結點數有限。
適用場合：區域網，對實時性要求不高的環境。
3、環形網路拓撲結構：
入網設備通過轉發器接入網路，每個轉發器僅與兩個相鄰的轉發器有直接的物理線路。環形網的數據傳輸具有單向性，一個轉發器發出的數據只能被另一個轉發器接收並轉發。所有的轉發器及其物理線路構成了一個環狀的網路系統。
環形網特點：
（1）實時性較好（信息在網中傳輸的最大時間固定）；
（2）每個結點只與相鄰兩個結點有物理鏈路；
（3）傳輸控制機制比較簡單；
（4）某個結點的故障將導致物理癱瘓；
（5）單個環網的結點數有限。
適用場合：區域網，實時性要求較高的環境。
4、網狀網路拓撲結構：
利用專門負責數據通信和傳輸的結點機構成的網狀網路，入網設備直接接入結點機進行通信。網狀網路通常利用冗餘的設備和線路來提高網路的可靠性，因此，結點機可以根據當前的網路信息流量有選擇地將數據發往不同的線路。適用場合：主要用於地域范圍大、入網主機多（機型多）的環境，常用於構造廣域網路。
8. 什麼是網站架構
網站架構，一般認為是根據客戶需求分析的結果，准確定位網站目標群體，設定網站整體架構，規劃、設計網站欄目及其內容，制定網站開發流程及順序，以最大限度地進行高效資源分配與管理的設計。其內容有程序架構，呈現架構，和信息架構三種表現。而步驟主要分為硬架構和軟架構兩步程序。網路架構是現代網路學習和發展的一個必須的基礎技術。
中文名
網站架構
一般認為
根據客戶需求分析的結果
制定
網站開發流程及順序
內容
程序架構，呈現架構
快速
導航
軟架構八個方案
硬架構
機房的選擇
在選擇機房的時候，根據網站用戶的地域分布，可以選擇網通或電信機房，但更多時候，可能雙線機房才是合適的。越大的城市，機房價格越貴，從成本的角度看可以在一些中小城市託管伺服器，比如說北京的公司可以考慮把伺服器託管在天津，廊坊等地，不是特別遠，但是價格會便宜很多。
帶寬的大小
通常老闆花錢請我們架構網站的時候，會給我們提出一些目標，諸如網站每天要能承受100萬PV的訪問量等等。這時我們要預算一下大概需要多大的帶寬，計算帶寬大小主要涉及兩個指標（峰值流量和頁面大小），我們不妨在計算前先做出必要的假設：
第一：假設峰值流量是平均流量的5倍。
第二：假設每次訪問平均的頁面大小是100K位元組左右。
如果100萬PV的訪問量在一天內平均分布的話，摺合到每秒大約12次訪問，如果按平均每次訪問頁面的大小是100K位元組左右計算的話，這12次訪問總計大約就是1200K位元組，位元組的單位是Byte，而帶寬的單位是bit，它們之間的關系是1Byte = 8bit，所以1200K Byte大致就相當於9600K bit，也就是9Mbps的樣子，實際情況中，我們的網站必須能在峰值流量時保持正常訪問，所以按照假設的峰值流量算，真實帶寬的需求應該在45Mbps 左右。
當然，這個結論是建立在前面提到的兩點假設的基礎上，如果你的實際情況和這兩點假設有出入，那麼結果也會有差別。
伺服器的劃分
先看我們都需要哪些伺服器：圖片伺服器，頁面伺服器，資料庫伺服器，應用伺服器，日誌伺服器等等。
對於訪問量大點的網站而言，分離單獨的圖片伺服器和頁面伺服器相當必要，我們可以用lighttpd來跑圖片伺服器，用apache來跑頁面伺服器，當然也可以選擇別的，甚至，我們可以擴展成很多台圖片伺服器和很多台頁面伺服器，並設置相關域名，如img.domain和 www.domain，頁面里的圖片路徑都使用絕對路徑，如<img src="http://img.domain/abc.gif" />，然後設置DNS輪循，達到最初級的負載均衡。當然，伺服器多了就不可避免的涉及一個同步的問題，這個可以使用rsync軟體來搞定。
資料庫伺服器是重中之重，因為網站的瓶頸問題十有八九是出在資料庫身上。一般的中小網站多使用MySQL資料庫，不過它的集群功能似乎還沒有達到stable的階段，所以這里不做評價。一般而言，使用MySQL資料庫的時候，我們應該搞一個主從（一主多從）結構，主資料庫伺服器使用innodb表結構，從數據伺服器使用myisam表結構，充分發揮它們各自的優勢，而且這樣的主從結構分離了讀寫操作，降低了讀操作的壓力，甚至我們還可以設定一個專門的從伺服器做備份伺服器，方便備份。不然如果你只有一台主伺服器，在大數據量的情況下，mysqlmp基本就沒戲了，直接拷貝數據文件的話，還得先停止資料庫服務再拷貝，否則備份文件會出錯。但對於很多網站而言，即使資料庫服務僅停止了一秒也是不可接受的。如果你有了一台從資料庫伺服器，在備份數據的時候，可以先停止服務（slave stop）再備份，再啟動服務（slave start）後從伺服器會自動從主伺服器同步數據，一切都沒有影響。但是主從結構也是有致命缺點的，那就是主從結構只是降低了讀操作的壓力，卻不能降低寫操作的壓力。
為了適應更大的規模，可能只剩下最後這招了：橫向/縱向分割資料庫。所謂橫向分割資料庫，就是把不同的表保存到不同的資料庫伺服器上，比如說 用戶表保存在A資料庫伺服器上，文章表保存在B資料庫伺服器上，當然這樣的分割是有代價的，最基本的就是你沒法進行LEFT JOIN之類的操作了。所謂縱向分割資料庫，一般是指按照用戶標識（user_id）等來劃分數據存儲的伺服器，比如說：我們有5台資料庫伺服器，那麼 「user_id % 5 + 1」等於1的就保存到1號伺服器，等於2的就保存到2號伺服器，以此類推，縱向分隔的原則有很多種，可以視情況選擇。不過和橫向分割資料庫一樣，縱向分割資料庫也是有代價的，最基本的就是我們在進行如COUNT, SUM等匯總操作的時候會麻煩很多。綜上所述，資料庫伺服器的解決方案一般視情況往往是一個混合的方案，以其發揮各種方案的優勢，有時候還需要藉助memcached之類的第三方軟體，以便適應更大訪問量的要求。
如果有專門的應用伺服器來跑PHP腳本是最合適不過的了，那樣我們的頁面伺服器只保存靜態頁面就可以了，可以給應用伺服器設置一些諸如app.domain之類的域名來和頁面伺服器加以區別。對於應用伺服器，我還是更傾向於使用prefork模式的apache，配上必要的xcache之類的PHP緩存軟體，載入模塊要越少越好，除了mod_rewrite等必要的模塊，不必要的東西統統舍棄，盡量減少httpd進程的內存消耗，而那些圖片伺服器，頁面伺服器等靜態內容就可以使用lighttpd或者tux來搞，充分發揮各種伺服器的特點。
如果條件允許，獨立的日誌伺服器也是必要的，一般小網站的做法都是把頁面伺服器和日誌伺服器合二為一了，在凌晨訪問量不大的時候cron運行前一天的日誌計算，不過如果你使用awstats之類的日誌分析軟體，對於百萬級訪問量而言，即使按天歸檔，也會消耗很多時間和伺服器資源去計算，所以分離單獨的日誌伺服器還是有好處的，這樣不會影響正式伺服器的工作狀態。
軟架構
框架的選擇
PHP框架有很多選擇，比如：CakePHP，Symfony，Zend Framework等等，至於應該使用哪一個並沒有唯一的答案，要根據Team里團隊成員對各個框架的了解程度而定。很多時候，即使沒有使用框架，一樣能 寫出好的程序來，比如Flickr據說就是用Pear+Smarty這樣的類庫寫出來的，所以，是否用框架，用什麼框架，一般不是最重要的，重要的是我們 的編程思想里要有框架的意識。
邏輯的分層