1、網站架構圖設計用什麼軟體好?急求!
如果是繪制一般的架構設計圖,如邏輯視圖、物理視圖、部署視圖等架構視圖,甚至狀態圖、序列圖等,你使用IBM的Rational software architect軟體就可以,或者用EA軟體也行。
如果視圖比較簡單,就用Visio,甚至powepoint也無妨。
2、如何一個人打造日PV百萬的網站架構
這么大流量,一個人做,只能是搞垃圾流量站,搞小說站,笑話站等獲取垃圾流量。否則一個人很難完成正規大網站的運營。
3、如何構建千萬用戶級別 後台資料庫架構設計的思路
(1). 一定要區分業務類型,可能達到千萬用戶級別的應用業務場景,可歸類描述為: SNS社交平台、SNS社交遊戲、即時通信IM系統、電子商務、郵件系統、新聞門戶網站等,這些不同類型的業務場景做法會不一樣,主要是由他們業務性質決定,後續分析項中逐一描述;
(2). 應用業務的核心KPI數值,產品每天的日活躍用戶量大概多少?若是網站類型應用,還需要加入其他參數PV,UV等數據輔助決策,即時通信IM的消息量,郵件系統的新增郵件數,SNS社交平台的Feeds量等核心數據;
(3). 系統中每個用戶可能產生的數據量大概多大,分固定部分,以及動態部分的方式統計分析,對非固定部分以參考值和結合實踐跨度(注釋:1年為硬性指標,2年為預期,3年可選,再長的時間段不考慮)的方式進行分析,然後預測出整個系統的用戶鎖產生的數據條數和數據容量大概的估值;
4、50w pv 網站api介面怎麼架構比較好
50萬pv的量不算大,在web服務上層做個負載均衡解決伺服器單點就可以了
5、一個10wPV的網站Discuz的架構做的門戶和論壇,需要什麼樣的伺服器和帶寬
5M獨享 足夠了 運行個DZ論壇 沒必要搞得那麼大 2W預算足夠
6、什麼是網站總體架構設計
網站結構是指網站中頁面間的層次關系,按性質可分為邏輯結構及物理結構。是現代網路學習和發展的一個必須的基礎技術。根據需求分析的結果,准確定位網站目標群體,設定網站整體架構,規劃、設計網站欄目及其內容,制定網站開發流程及順序。
網站架構的內容有哪些?
有程序架構,呈現架構,和信息架構三種表現,步驟主要分為硬架構和軟架構兩步程序。

網站總體框架示意圖是網站後台支撐系統的想法,一般取決於網站本身的建設意圖。
網站架構水平的高低決定著網站的整體性能和運營模式的時效性和經濟性,它的設計必須考慮到網站的模式、運營思路、用戶群體使用習慣、網站的功能等等。
網站結構對網站的搜索引擎友好性及用戶體驗有著非常重要的影響。網站結構在決定頁面權重上起著非常關鍵的作用,會直接影響到搜索引擎對頁面的收錄。一個合理的網站結構可以引導搜索引擎抓取到更多、更有價值的網頁。如果網站結構混亂,往往就會造成搜索引擎陷入死循環、抓取不到頁面等問題。網站結構的好壞會決定用戶瀏覽的體驗度,合理的網站結構是優化網站關鍵詞排名的前提。
所以,網站結構可以影響網站內部頁面的重要性,合理的內部鏈接策略就可以對重要頁面進行突出、推薦等操作。
繪制網站概要圖符號



網站概要圖模板

7、大型網站架構模式有哪些
1.分布式
對於大型網站,分層和分割的一個主要目的是為了切分後的模塊便於分布式部署,即將不同模塊部署在不同的伺服器上,通過遠程調用協同工作。分布式意味著可以使用更多的計算機完成同樣的功能,計算機越多,CPU、內存、存儲資源也就越多,能夠處理的並發訪問和數據量就越大,進而能夠為更多的用戶提供服務。
2.分層
分層是企業應用系統中最常見的一種架構模式,將系統在橫向維度上切分成幾個部分,每個部分負責一部分相對比較單一的職責,然後通過上層對下層的依賴和調用組成一個完整的系統。
分層結構在計算機世界中無處不在,網路的7層通信協議是一種分層結構;計算機硬體、操作系統、應用軟體也可以看作是一種分層結構。在大型網站架構中也採用分層結構,將網站軟體系統分為應用層、服務層、數據層。
3.分割
如果說分層是將軟體在橫向方面進行切分,那麼分割就是在縱向方面對軟體進行切分。
網站越大,功能越復雜,服務和數據處理的種類也越多,將這些不同的功能和服務分割開來,包裝成高內聚低耦合的模塊單元,一方面有助於軟體的開發和維護;另一方面,便於不同模塊的分布式部署,提高網站的並發處理能力和功能擴展能力。
4.集群
使用分布式雖然已經將分層和分割後的模塊獨立部署,但是對於用戶訪問集中的模塊(比如網站的首頁),還需要將獨立部署的伺服器集群化,即多台伺服器部署相同應用構成一個集群,通過負載均衡設備共同對外提供服務。
5.緩存
緩存就是將數據存放在距離計算最近的位置以加快處理速度。緩存是改善軟體性能的第一手段,現代CPU越來越快的一個重要因素就是使用了更多的緩存,在復雜的軟體設計中,緩存幾乎無處不在。大型網站架構設計在很多方面都使用了緩存設計。
6.非同步
計算機軟體發展的一個重要目標和驅動力是降低軟體耦合性。事物之間直接關系越少,就越少被彼此影響,越可以獨立發展。大型網站架構中,系統解耦合的手段除了前面提到的分層、分割、分布等,還有一個重要手段是非同步,業務之間的消息傳遞不是同步調用,而是將一個業務操作分成多個階段,每個階段之間通過共享數據的方式非同步執行進行協作。
8、大型視頻網站的技術架構方案
國內的不清楚,給你看看YOUTUBE的
YouTube 的架構擴展
在西雅圖擴展性的技術研討會上,YouTube 的 Cuong Do 做了關於 YouTube Scalability 的報告。視頻內容在 Google Video 上有(地址),可惜國內用戶看不到。
Kyle Cordes 對這個視頻中的內容做了介紹。裡面有不少技術性的內容。值得分享一下。(Kyle Cordes 的介紹是本文的主要來源)
簡單的說 YouTube 的數據流量, "一天的YouTube流量相當於發送750億封電子郵件.", 2006 年中就有消息說每日 PV 超過 1 億,現在? 更誇張了,"每天有10億次下載以及6,5000次上傳", 真假姑且不論, 的確是超乎尋常的海量. 國內的互聯網應用,但從數據量來看,怕是只有 51.com 有這個規模. 但技術上和 YouTube 就沒法子比了.
1. Web 伺服器
YouTube 出於開發速度的考慮,大部分代碼都是 Python 開發的。Web 伺服器有部分是 Apache, 用 FastCGI 模式。對於視頻內容則用 Lighttpd 。據我所知,MySpace 也有部分伺服器用 Lighttpd ,但量不大。YouTube 是 Lighttpd 最成功的案例。(國內用 Lighttpd 站點不多,豆瓣用的比較舒服。by Fenng)
2. 視頻
視頻的縮略圖(Thumbnails)給伺服器帶來了很大的挑戰。每個視頻平均有4個縮略圖,而每個 Web 頁面上更是有多個,每秒鍾因為這個帶來的磁碟 IO 請求太大。YouTube 技術人員啟用了單獨的伺服器群組來承擔這個壓力,並且針對 Cache 和 OS 做了部分優化。另一方面,縮略圖請求的壓力導致 Lighttpd 性能下降。通過 Hack Lighttpd 增加更多的 worker 線程很大程度解決了問題。而最新的解決方案是起用了 Google 的 BigTable, 這下子從性能、容錯、緩存上都有更好表現。看人家這收購的,好鋼用在了刀刃上。
出於冗餘的考慮,每個視頻文件放在一組迷你 Cluster 上,所謂 "迷你 Cluster" 就是一組具有相同內容的伺服器。最火的視頻放在 CDN 上,這樣自己的伺服器只需要承擔一些"漏網"的隨即訪問即可。YouTube 使用簡單、廉價、通用的硬體,這一點和 Google 風格倒是一致。至於維護手段,也都是常見的工具,如 rsync, SSH 等,只不過人家更手熟罷了。
3. 資料庫
YouTube 用 MySQL 存儲元數據--用戶信息、視頻信息什麼的。資料庫伺服器曾經一度遇到 SWAP 顛簸的問題,解決辦法是刪掉了 SWAP 分區! 管用。
最初的 DB 只有 10 塊硬碟,RAID 10 ,後來追加了一組 RAID 1。夠省的。這一波 Web 2.0 公司很少有用 Oracle 的(我知道的只有 Bebo,參見這里). 在擴展性方面,路線也是和其他站點類似,復制,分散 IO。最終的解決之道是"分區",這個不是資料庫層面的表分區,而是業務層面的分區(在用戶名字或者 ID 上做文章,應用程序控制查找機制)
YouTube 也用 Memcached.
9、做網站(金融+旅遊) 2000萬注冊用戶 200萬/天的PV 1萬/天的並發 伺服器需要什麼配置?架構做成什麼樣?
你好,並發數能夠達到1萬的網站已經算是規模較大的網站的,對伺服器配置、網路環境及帶寬要求就高的,一台伺服器甚至無法滿足網站正常運行,需要多台伺服器來做負載均衡的,網站數據硬碟接入磁碟櫃來減輕對伺服器自身的負荷,具體配置可以咨詢方案實施人員