① 網站的基本架構是什麼
網站架構按照製作步驟分為硬架構和軟架構。
一、硬架構
1、機房：在選擇機房的時候，根據網站用戶的地域分布，可以選擇網通、電信等單機房或雙機房。
2、帶寬：預估網站每天的訪問量，根據訪問量選擇合適的帶寬，計算帶寬大小主要涉及峰值流量和頁面大小兩個指標。
3、伺服器：選擇需要的伺服器，如圖片伺服器，頁面伺服器，資料庫伺服器，應用伺服器，日誌伺服器，對於訪問量大點的網站而言，分離單獨的圖片伺服器和頁面伺服器相當必要。
二、軟架構
1、網站的框架：現在的PHP框架有很多選擇，比如：CakePHP，Symfony，Zend Framework，根據創作團隊對各個框架熟悉程度選擇。
2、邏輯的分層
1）表現層：所有和表現相關的邏輯都應該被納入表現層的范疇。
2）應用層：主要作用是定義用戶可以做什麼，並把操作結果反饋給表現層。
3）領域層：包含領域邏輯的層，就是告訴用戶具體的操作流程的。
4）持久層：即資料庫，保存領域模型保存到資料庫，包含網站的架構和邏輯關系等。
(1)web日誌系統架構擴展閱讀
網站的分類
1、根據網站所用編程語言分類：例如asp網站、php網站、jsp網站、Asp. net網站等；
2、根據網站的用途分類：例如門戶網站（綜合網站）、行業網站、娛樂網站等；
3、根據網站的功能分類：例如單一網站（企業網站）、多功能網站（網路商城）等等。
4、根據網站的持有者分類：例如個人網站、商業網站、政府網站、教育網站等。
5、根據網站的商業目的分類：營利型網站（行業網站、論壇）、非營利性型網站（企業網站、政府網站、教育網站）。
② 如何用IIS架構WEB網站
親，對詳情描述里的兩問題的回答：
1、網站發布首先需要解決域名解析的問題，做好的網站要發布且在個人電腦里可以選擇花生殼域名軟體來映射內外網地址發布。詳情請網路「花生殼」。
2、右擊瀏覽可以的話，網站主目錄就沒有問題。那麼
a.你的網站TCP埠不是默認的80，請如下圖一改回即可。
b.當然也可以在輸完IP地址後加 「 : 埠號 」來訪問網頁。
c.如果因為安全級別問題可以將internet屬性里的安全級別調低點，並將網址添加到受信任的站點里。
對標題問題的回答：
可以使用伺服器系統來搭建，web網站可以有三種方式表達，IP地址、埠、主機頭。
以主機頭實驗為例如下圖
伺服器設置
③ web2.0是什麼它的到來有什麼意義么
WEB2.0概念詮釋
Web2.0，是相對Web1.0（2003年以前的互聯網模式）的新的一類互聯網應用的統稱，是一次從核心內容到外部應用的革命。由Web1.0單純通過網路瀏覽器瀏覽html網頁模式向內容更豐富、聯系性更強、工具性更強的Web2.0互聯網模式的發展已經成為互聯網新的發展趨勢。
Web1.0到Web2.0的轉變，具體的說，從模式上是單純的「讀」向「寫」、「共同建設」發展；由被動地接收互聯網信息向主動創造互聯網信息邁進！從基本構成單元上，是由「網頁」向「發表/記錄的信息」發展；從工具上，是由互聯網瀏覽器向各類瀏覽器、rss閱讀器等內容發展；運行機制上，由「Client Server」向「Web Services」轉變；作者由程序員等專業人士向全部普通用戶發展；應用上由初級的「滑稽」的應用向全面大量應用發展。
總之，Web2.0是以 Flickr、Craigslist、Linkedin、Tribes、Ryze、 Friendster、Del.icio.us、43Things.com等網站為代表，以Blog、TAG、SNS、RSS、wiki等應用為核心，依據六度分隔、xml、ajax等新理論和技術實現的互聯網新一代模式。
應用：
1、 Blog（from wiki）
歷史：
Blog一詞本起源於 weblog，意思是網上日誌。1997年由 Jorn Barger所提出。在1998年， infosift 的編輯Jesse J. Garrett (http://www.jjg.net)，將一些類似blog的網站收集起來，寄給Cameron Barrett。 Cameron隨後將名單發布在CamWorld網站上，許多人亦陸續將blog的URL給Cameron，慢慢的，一個新的網路社區儼然成型。1999年，Brigitte Eaton (http://www.eatonweb.com)成立一個weblog 目錄，收集她所知道的blog站。1999年，Peter Merholz (http://www.peterme.com)首次使用縮略詞「blog」，成為今天常用的術語。但是，blog 真正開始快速發展的轉折點，是在1999年6月，當時Pitas開始提供免費的weblog服務，緊接著8月，Pyra lab推出了現在的blogger.com。blogger.com 提供了簡單易學的說明，以及能通過FTP直接將blog發表在個人網站上的功能，這帶給使用者很大的方便。目前已經有了很多Blog託管服務商(BSP)，業內人士對其盈利前景，持謹慎樂觀態度。
Blog的特點
Blog是個人或群體以時間順序所作的一種記錄，並且不斷更新。blog之間的交流主要是通過回溯引用（TrackBack）和回響/留言/評論（comment）的方式來進行的。blog的操作管理用語，也借鑒了大量檔案管理用語。一個blog亦可被視為一個檔案（archives），或是卷宗（fonds）。與傳統檔案不同的是，blog的寫作者（blogger），既是這份檔案的創作人（creator），也是其檔案管理人（archivist）。
Blog大量採用了RSS（Really Simple Syndication或者Rich Site Summary或者RDF Site Summary）技術，所有的RSS文件都必須符合由W3C發布的XML 1.0規范。對讀者來說，可以通過RSS訂閱一個blog，確知該blog作者最近的更新。對Blog作者來說，RSS可以使自己發布的文章易於被計算機程序理解並摘要。
對知識管理和創造而言，blog提供了新的形態和途徑。對漢語為母語的人而言，blog寫作既接續了漢語筆記文學的優秀傳統，更充分鼓勵了個人表達。從交往形態考察，網志空間（blogosphere）設定了積極的讀者、作者、編者互動轉換關系，「言者互重，閱者相惜 」。
2、 Tag （from blogbus）
什麼是Tag？
Tag（標簽）是一種更為靈活、有趣的日誌分類方式，您可以為每篇日誌添加一個或多個Tag（標簽），然後您可以看到BlogBus上所有和您使用了相同Tag的日誌，並且由此和其他用戶產生更多的聯系和溝通。不僅如此，我們還通過與Technorati的合作，把您的Tag發送到全球Blog空間，和全世界的人們共同分享。
Tag體現了群體的力量，使得日誌之間的相關性和用戶之間的交互性大大增強，可以讓您看到一個更加多樣化的世界，一個關聯度更大的Blog空間，一個熱點實時播報的新聞台。Tag為您提供前所未有的網路新體驗……
當然，您也可以簡單地把一個Tag（標簽）理解為一個日誌分類，但是Tag和分類的不同之處也很明顯：
首先，分類是您在寫日誌之前就定好的，而Tag是在您寫完日誌之後再添加的；
其次，您可以同時為一篇日誌貼上好幾個Tag（標簽），方便自己隨時查找，而原先一篇日誌只能有一個分類；
再次，當您積累了一定數量的Tag之後，您可以看看自己在Blog中最經常寫的是哪些話題；
最後，您可以看到有哪些人和自己使用了一樣的Tag（標簽），進而找到和您志趣相投的Blogger。
舉一個例子，比如說：您寫了一篇到西湖旅遊的日誌，原來您都是把這一類的日誌放到自己的「驢行天下」分類下，但是有了Tag之後，您可以給這篇日誌同時加上「旅遊」、「杭州」、「西湖」、「驢行天下」等幾個Tag，當瀏覽者點擊其中任何一個Tag，他都可以看到您的這篇日誌。同時您自己也可以通過點擊這幾個Tag，看看究竟有誰最近也去了杭州旅遊，或許你們還可以交流一下旅遊心得，成為下一次出遊的夥伴呢！
3、 SNS
Social Network Service，社會性網路軟體，依據六度理論，以認識朋友的朋友為基礎，擴展自己的人脈。並且無限擴張自己的人脈，在需要的時候，可以隨時獲取一點，得到該人脈的幫助。
SNS網站，就是依據六度理論建立的網站，幫你運營朋友圈的朋友。
4、 RSS（from wiki）
RSS是一種用於共享新聞和其他Web內容的數據交換規范，起源於網景通訊公司的推"Push"技術，將訂戶訂閱的內容傳送給他們的通訊協同格式(Protocol)。RSS可以是以下三個解釋的其中一個：
Really Simple Syndication（真正簡單的整合）
RDF (Resource Description Framework) Site Summary
Rich Site Summary（豐富站點摘要）
但其實這三個解釋都是指同一種Syndication的技術。
目前RSS規范的主要版本有0.91、1.0和2.0。
0.91版和1.0版完全不同，風格不同，制定標準的人也不同。0.91版和2.0版一脈相承。1.0版更靠攏XML標准。
RSS目前廣泛用於blog、wiki和網上新聞頻道，世界多數知名新聞社網站都提供RSS訂閱支持。
5、 Wiki（from wiki）
Wiki一詞源自夏威夷語的「wee kee wee kee」，本是「快點快點」之意。在這里Wiki指的是一種超文本系統。這種超文本系統系支持那些面向社群的協作式寫作，同時也包括一組支持這種寫作的輔助工具。有人認為，Wiki系統屬於一種人類知識的網路系統，我們可以在Web的基礎上對Wiki文本進行瀏覽、創建、更改，而且這種創建、更改、及發布的代價遠比HTML文本小；與此同時Wiki系統還支持那些面向社群的協作式寫作，為協作式寫作提供了必要的幫助；最後，Wiki的寫作者自然構成了一個社群，Wiki系統為這個社群提供了簡單的交流工具。與其它超文本系統相比，Wiki有使用簡便且開放的優點，所以Wiki系統可以幫助我們在一個社群內共用某個領域的知識。
Wiki起源
1995年沃德?坎寧安（Ward Cunningham）為了方便模式社群的交流創建了全世界第一個wiki系統－WikiWikiWeb，並用它建立了波特蘭模式知識庫（Portland Pattern Repository）。在建立這個系統的過程中，沃德?坎寧安創造了Wiki的概念和名稱，並且實現了支持這些概念的服務系統。這個系統是最早的Wiki系統。從1996年至2000年間，波特蘭模式知識庫圍繞著面向社群的協作式寫作，不斷發展出一些支持這種寫作的輔助工具，從而使Wiki的概念不斷得到豐富。同時Wiki的概念也得到了傳播，出現了許多類似的網站和軟體系統。
Wiki的歷史不長，無論是Wiki概念本身，還是相關軟體系統的特性，都還在熱烈的討論中；所以怎樣的一個站點才能稱得上是一個Wiki系統還是有爭議的。與Wiki相關新近出現的技術還有blog，它們都降低了超文本寫作和發布的難度。這兩者都是同內容管理系統密切相關的。
Wiki的特點
使用方便
維護快捷：快速創建、存取、更改超文本頁面（這也是為什麼叫作 "wiki wiki" 的原因）。
格式簡單：用簡單的格式標記來取代 HTML 的復雜格式標記。（類似所見即所得的風格）
鏈接方便：通過簡單標記，直接以關鍵字名來建立鏈接（頁面、外部連接、圖像等）。
命名平易：關鍵字名就是頁面名稱，並且被置於一個單層、平直的名空間中。
可增長
可增長：頁面的鏈接目標可以尚未存在，通過點擊鏈接，我們可以創建這些頁面，從而使系統得以增長。
修訂歷史：記錄頁面的修訂歷史，頁面的各個版本都可以被獲取。
開放性
開放的：社群內的成員可以任意創建、修改、或刪除頁面。
可觀察：系統內頁面的變動可以被來訪者清楚觀察得到。
由於Wiki的自組織，可增長以及可觀察的特點，使Wiki本身也成為一個網路研究的對象。對Wiki的研究也許能夠讓人們對網路的認識更加深入
理論和技術：
1、 六度關系理論
目前流行的「六度分隔」理論是20世紀60年代由美國的心理學家米格蘭姆（Stanley Milgram）提出的，這個理論可以通俗地闡述為： 最多通過六個人你就能夠認識任何一個陌生人。「六度分隔」成為人際關繫世界中無可否認而又令人震驚的特徵，許多社會學上的深入研究也給出令人信服的證據，說明這一特徵不只是特例，在一般情形下也存在。 最近，美國哥倫比亞大學社會學系的瓦茨教授領導的EMAIL試驗也再次證明了這一人際關繫世界中驚人的規律。然而，在現實世界中，六十億人怎麼可能真的構成如此緊密的相互關聯呢？是互聯網使一切成為現實。
2、 Xml
XML即可擴展標記語言（eXtensible Markup Language）。標記是指計算機所能理解的信息符號，通過此種標記，計算機之間可以處理包含各種信息的文章等。如何定義這些標記，既可以選擇國際通用的標記語言，比如HTML，也可以使用象XML這樣由相關人士自由決定的標記語言，這就是語言的可擴展性。XML是從SGML中簡化修改出來的。它主要用到的有XML、XSL和XPath等。
3、 AJAX
Ajax並不是一種技術。它實際上是幾種已經在各自領域大行其道技術的強強結合。Ajax混合了：
* 基於XHTML/CSS
* 由DOM（Document Object Model）實現動態顯示與交互
* 通過XML和XSLT進行數據交換及處理
* 使用JavaScript整合上述技術
直觀一點的說Ajax能夠實現不刷新瀏覽器窗口（當然更不用安裝額外的插件）而滿足用戶的操作，現在一些看上去很Cool的網站，很多是用這項技術實現的，其中包括：orkut、Gmail、Google Group、Google Suggest、Google Maps、Flickr、A9.com等。2SIMPLE的Co-mment系統雖然沒有用到XML/XSLT，其理念已經暗合容Ajax，實現了不刷新網頁提供動態內給用戶。
現有的產品：
Wiki網路、Wallop 、yahoo360 、openbc 、 cyworld 、43things 、 flickr、 del.icio.us、 cragslist 、glob 、客齊集、 friendster 、 linkin 、UU通 、 優友 、 天際網 、愛米網 、linkist 、新浪點點通、skype、億友、cyworld
現在說說web2.0的具體應用。
歷史很重要。對一個技術的學習也應當從歷史出發，通過其在時間形成歷史的流變，得以知曉現狀，甚至能夠預知未來。
那Web 1.0是什麼呢？
他們說，記得靜態HTML的WWW時代么？
（那個時代的WWW應用、人們的Web體驗、對社會的影響如何？）
那麼動態HTML和靜態HTML下的Web相比，是多少版本？1.5？對了，他們是真這么叫的。
（在效果和影響上，與1.0相比，擴展和加深多少？）
要呈現的數據存儲在資料庫中，通過Web服務端的程序，應用戶的請求，取出數據，加上事先設計的模板，動態的生成Html代碼，發送到用戶的瀏覽器那裡。
他是1.0系列，應為用戶在瀏覽器中所見和Web 1.0一樣，它有0.5的升級，因為數據不是事先製作並發布，而是動態生成，和用戶的需要交互生成。
那好，在加0.5，到Web 2.0，變化是在哪裡呢？
（看到了正在崛起的和改變的，會繼續朝著什麼方向改變互聯網和社會呢？）
更新：關於各個版本的差別，看看亞馬遜的例子。
事情沒有那麼幸運，Web 2.0並不是一個具體的事物，而是一個階段，是促成這個階段的各種技術和相關的產品服務的一個稱呼。所以，我們無法說，Web 2.0是什麼，但是可以說，那些是Web 2.0。
WikiPedia的Web 2.0條目下列出了這些條件：
* CSS 和語義相關的 XHTML 標記
* AJAX 技術
* Syndication of data in RSS/ATOM
* Aggregation of RSS/ATOM data
* 簡潔而有意義的 URLs
* 支持發布為 weblog
* RESTian (preferred) 或者 XML Webservice APIs
* 一些社會性網路元素
必須具備的要素有：
* 網站應該能夠讓用戶把數據在網站系統內外倒騰。
* 用戶在網站系統內擁有自己的數據
* 完全基於Web，所有的功能都能透過瀏覽器完成。
（以上內容引用自英文版維基網路）
雖然這只是一家之言，不過，對於其中談到的幾個要素，大家還是公認的。
- 基於RSS/ATOM/RDF/FOAF等XML數據的同步、聚合和遷移。
數據不再和頁面和網站混粘在一起，它獨立了，它跟著用戶走。這是Web 2.0的很重要特徵。這也是為什麼Blog是Web 2.0的代表的原因。在網志上，常主角的是相互獨立的一則則的網志。
獨立，然後有物理表現。現在，就能讓他們活躍起來。透過對XML數據的處理，這些內容能被自由的組合，被各種應用程序，不論是Web程序還是桌面程序等呈現和處理。
（更新：參看商業周刊的All Your Info in One Place）
當然，最重要的是背後的人。
- 社會性因素。
內容跟著人走，內容又能夠被用戶自由的組合，也就是說，用戶能夠自由的藉助內容媒介，創建起一個個的社群，發生各種社會性的（網路）行為。
此外還有標簽以及建立在開放標簽系統之上的Folksonomy。
- 第三個公認的因素是開放API，這個技術性稍強些，得另花時間研習，可以先看看例子：amazon、flickr、google map等。
（Web 2.0是個大筐，裝了好多東西）
從Web應用的產品/服務生產者角度來說，該如何創建Web 2.0的產品呢？
重要的是要抓住這么幾點，一個是微內容（這里有定義），一個是用戶個體。除了這兩個最基本的之外，還可以考慮社群內的分享以及提供API。
微內容：英文是microcontent。用戶所生產的任何數據都算是微內容，比如一則網志，評論，圖片，收藏的書簽，喜好的音樂列表、想要做的事情，想要去的地方、新的朋友等等。這些微內容，充斥著我們的生活、工作和學習，它的數量、重要性，還有我們對它的依賴，並不亞於那些道貌岸然、西裝革履的正統文章、論文、書籍。
對微內容的重新發現和利用，是互聯網所開創的平等、***、自由風氣的自然衍生，也是互聯網相關技術消減信息管理成本之後的一個成果。
我們每天都生產眾多的微內容，也消費著同樣多的微內容。對於Web 2.0來說，如何幫助用戶管理、維護、存儲、分享、轉移微內容，就成了關鍵。
用戶個體。對於Web 1.0的典型產品/服務來說，用戶沒有具體的面貌、個性，它只是一個模糊的群體的代名詞而已。但是對於Web2.0的產品和服務來說，用戶是個實實在在的人。Web 2.0所服務的，是具體的人，而不是一個如同幽靈般的概念。並且，這個人的具體性，會因為服務本身而不斷地充實起來。
如何為這個具體的個體服務，是Web 2.0設計的起點。
因此，一類可以被稱作Web 2.0的產品/服務將是這樣：
服務於用戶個體的微內容的收集、創建、發布、管理、分享、合作、維護等的平台。
這是表。
里呢，恐怕就設計到好些人提到的，微內容的XML表現；微內容的聚合；微內容的遷移；社會性關系的維護；界面的易用性等等。
其質，是否就是開源、參與、個人價值、草根、合作等等？
Web2.0是許多方面起頭並進又相互牽連的一個新的階段的到來。因此，不同的人，有著不同的看法。那麼，對於Web開發人員來說，Web2.0意味著什麼呢？
他們說Web2.0階段，Web是一個平台，或者說，Web正在變得可編程，可以執行的Web應用。野心家們設想這個它的終極目標是Web OS。
Web 1.0時候，Web只是一個針對人的閱讀的發布平台，Web由一個個的超文本鏈接而成。現在的趨勢發生了變化，Web不僅僅是Html文檔的天下，它成了交互的場所。
Web 2.0 Conference網站的橫幅引用Jeff Bezos的話說「Web 1.0 is making the internet for people，web 2.0 is making the internet better for computers」。
具體來講，他們說Web成為一個開發環境，藉助Web服務提供的編程介面，網站成了軟體構件。
這些，就是Web Service的目標吧，信息孤島通過這些Web Service的對話，能夠被自由構建成適合不同應用的建築來。
一些例子：del.icio.us、flickr、a9、amazon、yahoo、google、msn等提供的編程介面衍生出的各種應用。
為什麼要開放APIs，這涉及到集市中的商業方面的技術策略。當然，還有更深層的原因，那是什麼呢？
這種交互不僅體現在不同的網站服務之間，同時還體現在用戶和Web之間在瀏覽器上的交互。這也是為什麼在美味書簽的收藏中Web2.0和AJAX如此相關的一個原因。
在Web頁面上使用桌面程序有的那些便利，真的是很享受的事情。這恐怕也是Web可編程的一個方面，Web頁面不再是標記和內容混合那樣的簡單，它就是一個可以編程的地方（是這樣理解吧？）
有人反對說，AJAX的使用對搜索引擎不友好，只有Web 1.0的站長才關心這個事情吧，在Web 2.0時候，站長應該關心的是用戶參與的便利、用戶的自由度，至於搜索，有RSS/ATOM/RDF等，更本用不著操心，Google不是已經順應這個趨勢，讓大家主動提交了么？
可編程的第三個方面，是否在於Web應用和桌面應用之間的無縫連接趨勢的出現？類似這里說的「從工具上，是由互聯網瀏覽器向各類瀏覽器、rss閱讀器等內容發展」
......
自己不是專業開發人員，對Web OS的學習就點到為止，下次換個方向，否則我非頭大不可。
---------------------
cathayan和Live21說Web 2.0其實思路很古老，就是internet 1.0的回歸。
Live21那裡提到「關於概念的炒做應該不是一次兩次的問題了」。
提到概念炒作，我還真見到過，今天在一篇報道中看到作為WEB 2.0的BSP的字眼，好笑得很。
不過，我真想說明，在目前中文Blog空間內能查閱到的學習、探討Web 2.0的資料都不是炒作，因為包括我在內，大家都沒有任何商業背景（注意，新聞報道中的那些Web 2.0除外）。
[Web 2.0是個歷史學的概念，而非是個技術性的概念，它是對Web發展歷史斷代的成果。對這個概念的梳理，能幫助我更好的把握互聯網正在發生的技術與文化。]
中文網志圈談論的Web 2.0內容摘要：
- 「我覺得最有價值的一個是， web應用的數據格式開始逐漸出現了交換「標准」...這些標准...更加容易被機器自動化處理...能幫助人更好地過濾和定製化信息。其次，更多的服務將以web service的形式來提供，...這使得web 服務可以被互相集成， 從而誕生更多新的服務...人的重要性被提高了。過去web更多注重在信息提供， 而現在的越來越多的應用更加關注人，也就是所謂「社會性」。此外web的可用性改進正在被越來越重視...」[老冒：朝web 2.0潑點冷水]
- 「RSS逐漸成為在線內容提供服務的標准發行平台。Blog以及user-generated內容的興起。My Yahoo提供的RSS整合型服務。同時提出了值得密切關注的一些發展中領域，其中包括搜索技術，個性化，User-Generated內容（包括 blog，評論，圖像和聲音），音樂，短視頻和Accessibility(易訪問性）」[Owen：Mary Meeker新作 - 關於Digital World的發展報告的摘取]
- 「我們談論的Web2.0帶給我們的是一種可讀寫的網路，這種可讀寫的網路表現於用戶是一種雙通道的交流模式，也就是說網頁與用戶之間的互動關系由傳統的「Push」模式演變成雙向交流的「Two- Way Communication」的模式。而對於Web服務的開發者來說，Web2.0帶來的理念是服務的親和力，可操作性，用戶體驗以及可用性。」[Owen：BaCKpACK-體驗可讀寫的Web服務]
- 「web 2.0是一種可以被分發的信息概述，web文檔被格式化成了web數據。我們不會再看到不同舊地信息，現在我們所注意到是一種聚合、再混合內容的工具。」[songzhen：也說Web 2.0的翻譯]
- 「從這些應用中可以看到：如果基於傳統的HTML，同樣的功能實現將變得非常復雜和不穩定，數據的再生產和交換成本是很高的。所以：RSS這個標准最終要的貢獻就是使得互聯網的大部分網站變得可編程：類似的例子還有Blog中的：TrackBack Ping等機制，這些機制都是依賴XML/RPC實現的。當初為Lucene設計一個RSS/XML的介面也是為了這個初衷，它使得全文檢索服務可以輕松的嵌入到各種應用中，通過關鍵詞將各種內容之間實現更豐富的關聯(Well Referenced)。」[車東：RSS，簡單協議使得互聯網可編程]
- 「聚合的可能性以及如何更好地聚合（通常來說，更好的聚合應該基於個人知識管理和人際關系管理）很顯然應該成為新一代或者說web2.0架構的核心之一。還有，你會重新發現，恰好是分散帶動了聚合，聚合促進了分散，通過聚合的思維，互聯網的網路狀變得越來越豐富和密集，web2.0就變得越來越有趣味，它將web1.0時代的碩大節點即門戶網站不斷消解，去努力創造一個更加和諧的自然網路圖譜。」[Horse：rss，聚合的無數可能]
- 「新的web2.0網站都依賴於用戶參與、用戶主導、用戶建設」。[Horse：Web 2.0這個詞]
- Keso：Web 1.0與Web 2.0的區別
- 「表面上看，Bloglines取代了門戶，成為一個新的中心，但這里有一個重大的區別。門戶是只讀的，它帶有某種鎖定的性質。你可以離開門戶，但你無法帶走門戶的內容。Bloglines則完全不同，你覺得它好用，就會繼續使用，有一天你不再喜歡Bloglines，你完全可以導出你的OPML，到另一個 RSS訂閱網站，或者乾脆用客戶端軟體瀏覽同樣的內容。所以，像Bloglines這樣的網站，是可寫的，你可以導入，也可以導出。就像你對信息擁有選擇權，對服務提供商也同樣擁有選擇權，沒有人可以鎖定你，主動權在你自己手上。」[Keso：再說信息選擇權]
- 「Flickr、del.icio.us、Bloglines等Web 2.0服務，通過開放API獲得了很多有趣、有用的想法，並藉助外部的力量，讓用戶獲得了更好的體驗。更多大公司也加入到開放API的潮流中，Google、Yahoo!、Amazon、Skype。Google桌面搜索今年3月才開放API，很快就產生了大量的創造，大大擴充了可搜索的文件格式。」[Keso：開放API]
- 「歸納：web1.0天天談門戶，web2.0談個人化；web1.0談內容，web2.0談應用；web1.0商業模式，web2.0談服務；web1.0談密閉、大而全，web2.0大家談開放、談聯合；web1.0網站中心化，web2.0談個人中心化；web1.0一對一，web2.0談社會性網路；web1.0不知道你是狗，web2.0你去年夏天幹了什麼我一清二楚甚至想要干什麼呢。。。」[van_wuchanghua：發現了N.HOOLYWOOD，我還知道你今年夏天要干什麼]
- 「我認為Web2.0有下面幾個方面的特性: 個性化的傳播方式. 讀與寫並存的表達方式. 社會化的聯合方式.標准化的創作方式. 便捷化的體驗方式.
④ 基於Web的MES系統安全架構設計及分析(2)
基於Web的MES系統安全架構設計及分析
3.2.2基於角色的訪問控制
在對MES系統業務功能、業務流程及其干係人分析整理的基礎上，能夠抽象出系統的各種用戶角色，每種角色通過一組系統功能完成一定的業務處理，需要將這一組系統功能賦予該角色，使其具有完成這一業務的能力，也就形成了允許訪問控製表，包括菜單的允許訪問列表和功能的允許操作列表。
為了構成系統的完全訪問邊界，需要明確禁止某類操作。因此設計了禁止訪問控製表，包括：菜單的禁止訪問列表和功能的禁止操作列表。
3.2.3用戶及許可權管理
構建了角色的訪問控制，將角色賦予用戶，用戶即具備了相應的訪問許可權。在企業的MES應用中，每個企業用戶都具有一個系統訪問賬號，這個賬號是用戶身份的唯一標識。為保證系統賬號的合法性，所有用戶的賬號只能由系統的賬號管理員進行分配和管理。同時，每個用戶在企業承擔著某個崗位的職責，對應於MES系統來說，這個用戶就具備著一個或者多個系統角色，通過角色許可權的控制形成用戶的許可權控制。本著最小許可權的原則，應當合理分配和控制角色許可權，並通過禁止訪問控製表限制用戶的`訪問范圍，構成系統的安全訪問邊界。
3.3 安全運行管理
多數MES系統都採用單一管理員(甚至是超級用戶)對系統進行管理。雖然簡單易行，但卻存在巨大安全隱患。一旦管理員賬號信息泄露，其他安全措施將形同虛設。因此必須進行系統許可權的分割，使其相互制約，避免許可權過分集中。本架構的劃分策略：首先是用戶管理員，只負責企業用戶賬號的分配、鎖定和吊銷，用戶崗位角色的分配，以及用戶密碼的復位操作;其次是安全管理員，負責菜單與功能矩陣的維護，以及角色訪問控制列表的制定。
用戶管理員和安全管理員相互制約，只有協調一致才能夠完成用戶的許可權分配。同時又可以分級管理，按照分廠、車間等組織架構，或者依據業務范圍，劃分出不同層級、不同范圍的用戶管理員和安全管理員，他們只能在自己的許可權范圍內行使權力。由此形成了可集中管理也可分化管理的技術模型，企業可以依據自身規模和管理模式靈活組織設計。
3.4 系統安全審計
本架構設計了完備的行為捕獲和記錄系統，對系統關鍵執行動作留有記錄，對用戶的操作和行蹤留有日誌，同時記錄了非法用戶的入侵嘗試，且滿足不可抵賴性，形成可靠證據。尤其是用戶和安全管理員的所有操作，是系統監控的重點。企業安全審計人員可以隨時調取這些記錄，進行審計，一旦發現有違反安全策略的行為，即可對行為後果進行調查，採取相應處理措施。
3.5 會話安全策略
HTTP是一個無狀態的協議，此協議無法維護兩個事務之間的聯系，而MES系統的大量應用需要與用戶進行交互操作，並且記錄這些交互，這就需要保持會話狀態。會話狀態通常需要在客戶端cookie中記錄用戶信息，或者是在伺服器端session中記錄，但也需要在用戶請求與伺服器應用程序間傳遞一個會話ID，這些信息都會成為攻擊的對象，一旦被竊取，會話就可能被冒用，成為會話劫持，造成超越許可權的訪問和數據操作。為防範此類攻擊，一方面對用戶信息、會話ID等薄弱環節採取加密措施，增加截獲難度。另一方面制定安全策略監視會話狀態，進行會話鎖定和異常保護及報警。
會話鎖定：提供互動式會話的鎖定和解鎖能力及終止會話能力。在會話進入非活動周期後對終端進行鎖定或結束會話。在用戶的靜止期超過規定的值時，通過以下方式鎖定該用戶的互動式會話：(1)在顯示設備上清除或塗抹，使當前的內容不可讀;(2)取消會話解鎖之外的所有用戶數據的存取/顯示的任何活動;(3)在會話解鎖之前再次進行身份鑒別。
異常保護及報警：在會話期間通過用戶請求進行監視分析用戶操作行為，對異常行為採取操作保護動作，並產生記錄和報警，如頻繁、重復的數據操作，或者同一用戶在不同地點創建多個會話的請求等等。
3.6 Web安全防護策略
基於Web的MES系統遭受的典型網路攻擊事件包括sql注入、cookie破壞、會話劫持、目錄遍歷以及緩沖區溢出等，只有建立涵蓋事前、事中、事後的綜合防控體系，事前及時識別隱患和漏洞並採取修補措施，事中實時監測，積極防禦，早發現，早處置，才能將風險和損失降到最小。
本架構針對Web設計了安全防護策略，實現自動化的Web漏洞檢測，以及對網頁被掛馬、網頁被篡改、網頁出現敏感信息、系統被拒絕服務等攻擊事件的一體化監測預警。從而幫助企業構建自動化的系統安全監測系統，第一時間掌握MES應用的安全狀況，降低系統安全風險，增強安全防護等級。
4 MES系統運行安全的防護措施
MES系統的運行安全不能僅僅依靠MES自身的安全設計，需要根據企業對MES的技術經濟要求，綜合考慮信息安全技術和安全管理與防護措施。
在物理安全層面，建立MES系統安全運行相適應的安全環境，包括機房安全防護、設備安全可用、存儲介質安全等。
資料庫系統的安全至關重要，需要對數據依據其敏感性進行分類進行不同強度的加密，防止敏感信息泄露。同時資料庫要制定有備份和容災措施，資料庫管理人員定時對系統進行備份，防止系統數據損壞和丟失。一旦在系統崩潰或癱瘓的情況下，可利用備份數據迅速將系統恢復起來。
在運行安全方面，通過安全風險分析與評估，制定系統安全運行策略，建立安全檢測與監控機制，加強安全審計和系統邊界安全防護，採用防火牆、安全認證、入侵檢測等措施來阻止攻擊，綜合運用數據加密和VPN等技術，對包括計算機病毒在內的惡意代碼進行必要的安全防護，確保網路傳輸的安全要求。運用入侵檢測技術，主動保護MES系統免受攻擊，為MES系統提供了實時保護，是防火牆之後的第二道安全閘門。
依據國家計算機應急響應中心發布的數據，信息系統安全問題中的95%是可以通過科學的信息安全管理措施來避免。因此，加強信息安全意識，制定有效的安全運維策略是保障信息安全的重要基礎，已經成為企業管理的一個重要組成部分。
;⑤ 5g上網日誌系統三層架構合成層和應用層之間是什麼介面
無線介面。
5G提供數據連接和服務。定義和縮寫相關定義：5GAccessNetwork：連接到5G核心網的包含5G-RAN和/或non-3GPP接入網的一個接入網路。5GCoreNetwork：當前文檔指明的核心網路。它與5G接入網連接。
⑥ 分布式日誌系統Graylog、Loki及ELK的分析和對比
日誌系列：
企業級日誌平台新秀Graylog，比ELK輕量多了
日誌系統新貴Loki，比ELK輕量多了
1. 為什麼需要集中的日誌系統？
在分布式系統中，眾多服務分散部署在數十台甚至是上百台不同的伺服器上，要想快速方便的實現查找、分析和歸檔等功能，使用Linux命令等傳統的方式查詢到想要的日誌就費時費力，更不要說對日誌進行分析與歸納。
如果有一個集中的日誌系統，便可以將各個不同的伺服器上面的日誌收集在一起，不僅能方便快速查找到相應的日誌，還有可能在眾多日誌數據中挖掘到一些意想不到的關聯關系。
作為DevOps工程師，會經常收到分析生產日誌的需求。在機器規模較少、生產環境管理不規范時，可以通過分配系統賬號，採用人肉的方式登錄伺服器查看日誌。然而高可用架構中，日誌通常分散在多節點，日誌量也隨著業務增長而增加。當業務達到一定規模、架構變得復雜，靠人肉登錄主機查看日誌的方式就會變得混亂和低效。解決這種問題的方法，需要構建一個日誌管理平台：對日誌進行匯聚和分析，並通過Web UI授權相關人員查看日誌許可權。
2. 日誌系統選擇與對比
關於企業級日誌管理方案，比較主流的是ELK stack和Graylog。
常見的分布式日誌系統解決方案有經典的ELK和商業的splunk。為什麼沒有選擇上面的兩種方案呢，原因主要是如下兩種：
ELK目前很多公司都在使用，是一種很不錯的分布式日誌解決方案，但是需要的組件多，部署和維護相對復雜，並且佔用伺服器資源多，此外kibana也在高版本中開始商業化。
splunk是收費的商業項目，不在考慮范圍。
3. 認識graylog
3.1 簡介
graylog是一個簡單易用、功能較全面的日誌管理工具，graylog也採用Elasticsearch作為存儲和索引以保障性能，MongoDB用來存儲少量的自身配置信息，master-node模式具有很好的擴展性，UI上自帶的基礎查詢與分析功能比較實用且高效，支持LDAP、許可權控制並有豐富的日誌類型和標准（如syslog，GELF）並支持基於日誌的報警。
在日誌接收方面通常是網路傳輸，可以是TCP也可以是UDP，在實際生產環境量級較大多數採用UDP，也可以通過MQ來消費日誌。
3.2 優勢
部署維護簡單
資源佔用較少
查詢語法簡單易懂(對比ES的語法…)
內置簡單的告警
可以將搜索結果導出為 json
UI 比較友好
3.3 graylog單機架構圖
3.4 graylog集群架構
4、基於 GrayLog & ELK 的日誌監控
Collector
FileBeat：輕巧佔用資源少，但是功能有點弱。「想起了一些東西，都是淚」
Fluentd：個人理解在Logstash與FileBeat中間，可以簡單處理一些日誌，插件豐富「要再研究下」
自己弄：架構圖裡面只是mysql調用了自己實現的解析工具，但是其實當日誌大到一定的量的還是必須自己來的，類似日誌抽樣、降級、控制頻率等功能，是要真真切切的花費大量時間精力下去的一個sidecar並非動動嘴巴就能搞定的。「都是淚」
Queue
Kafka：王者地位「量小的時候也可以不用這個直接朝後面輸出，有很多中間方案大家自己腦補」，不同的日誌分不同的topic，嚴格區分日誌所屬類型，為後續消費打下基礎，比如A業務進入A Topic並在日誌中打上所屬語言類型的Tag。
Consumer
Logstash：其實這個東西也可以作為收集端來使用，就是比較耗費資源有點重，還會莫名其妙掛了「應該是我不會玩」
GrayLog：本人最喜歡的一個組件，集解析、報警、簡單分析、Dashboard、日誌TTL的綜合體，有這個東西吧其實Kibana就沒啥用了，畢竟誰沒事天天去分析日誌。
Storage
ElasticSearch：全文索引Engine，其實並沒有官方說的那麼牛，當到一定的並發寫入、大量查詢之後其實根本不是加機器能解決的，怎麼分shard，是按照天保存還是按照條數保存「我比較喜歡按照條數保存，這樣可以保證每個index都差不多大小，對於reblance是有好處的，重復利用多盤」如何保存是需要不斷調整的。「我們這邊不討論MongoDB去存日誌，看著都不靠譜」
規范
其實日誌系統最關鍵的是怎麼打、什麼格式打、但是這個東西需要消耗大量的時間去定義與各個部門Pk，遇到過大量不講理的輸出，直接線上Debug，600k的並發寫入，日誌又大又臭誰能扛得住「阿里雲的SLS是真的很牛」
捲起袖子加油干，少動嘴，多動手，日誌很好玩。在容器化的大環境下也越發的重要。
Flunted + Elasticsearch + Kibana的方案，發現有幾個缺點：
不能處理多行日誌，比如Mysql慢查詢，Tomcat/Jetty應用的Java異常列印
不能保留原始日誌，只能把原始日誌分欄位保存，這樣搜索日誌結果是一堆Json格式文本，無法閱讀。
不符合正則表達式匹配的日誌行，被全部丟棄。
對比圖
總結
雖然兩種解決方案在功能上非常相似，但仍有一些差異需要考慮。
兩者之間最重要的區別在於，從一開始，Graylog就定位為強大的日誌解決方案，而ELK則是大數據解決方案。Graylog可以通過網路協議直接從應用程序接收結構化日誌和標准syslog。相反，ELK是使用Logstash分析已收集的純文本日誌的解決方案，然後解析並將它們傳遞給ElasticSearch。
在ELK中，Kibana扮演儀表盤的角色並顯示從Logstash收到的數據。Graylog在這點上更方便，因為它提供了單一應用程序解決方案（不包括ElasticSearch作為靈活的數據存儲），具有幾乎相同的功能。因此，部署所需的時間更短。此外，與ELK相比，Graylog開箱即用，且具有出色的許可權系統，而Kibana則不具備此功能。作為Elasticsearch的粉絲，我更喜歡Graylog而不是ELK，因為它完全符合我在日誌管理方面的需求。
Graylog具有直觀的GUI，並提供警報、報告和自定義分析功能。最重要的是，它能在多個日誌源和跨機房收集數TB的數據。基於這些優勢，我更喜歡用Graylog而不是另一個具有類似功能的流行堆棧——ELK。
如果有需要領取免費資料的小夥伴們， 可以點擊此處領取資料哦！
⑦ 如何設計日誌採集存儲分析的架構
如何設計日誌採集存儲分析的架構
架構方面：
□ Flume OG有三種角色的節點：代理節點agent、收集節點collector、主節點master
□ agent負責從各個數據源收集日誌數據、將收集到的數據集中到collector,再由collector節點匯總存入到HDFS.而master負責管理agent\collector的活動
□ agent、collector都稱為node,node的角色根據配置的不同分為邏輯節點和物理節點,對於邏輯節點的區分、配置、使用非常復雜.
□ agent、collector由source、sink組成,表示當前節點的數據從source傳送到sink
以上相對於Flume NG來說:
□ Flume NG只有一種角色節點：代理節點agent
□ 沒有collector、master節點,這是最核心的變化.
□ 去除邏輯節點和物理節點的概念和內容
□ agent節點的組成發生變化,由source 、sink、channel三個組件組成
Zookeeper方面：
□ Flume OG的穩定性依賴zookeeper,它需要zookeeper對其多類節點的工作進行管理,雖然OG可以使用內存的方式對各類節點進行管理,但需要用戶忍受機器出現故障時信息丟失的出現.
□ Flume NG的節點角色數量由原來的3個縮減為1個,不存在多類角色的問題,所以不再需要zookeeper對各類節點協調的作用,由此脫離了對zookeeper的依賴.
⑧ efk 日誌集群架構了解
0.基礎架構：
說明：filebeat日誌直接傳送給es，直接從界面查看日誌
1.架構圖
使用filebeat收集日誌直接寫入kafka，然後再由logstash從kafka讀取寫到elasticsearch
其中各組件說明如下：
Filebeat：輕量級數據收集引擎。早期的ELK架構中使用Logstash收集、解析日誌，但是Logstash對內存、cpu、io等資源消耗比較高。如果用它來對伺服器進行日誌收集，將加重伺服器的負載。相比 Logstash，Beats所佔系統的CPU和內存幾乎可以忽略不計，所以filebeat作為一個輕量級的日誌收集處理工具(Agent)，它可以用來替代Logstash，由於其佔用資源少，所以更適合於在各個伺服器上搜集日誌後傳輸給Logstash，這也是官方推薦的一種做法。【收集日誌】
Logstash：數據收集處理引擎。支持動態的從各種數據源搜集數據，並對數據進行過濾、分析、豐富、統一格式等操作，然後存儲以供後續使用。【對日誌進行過濾、分析】
Elasticsearch：分布式搜索引擎。是基於Lucene的開源分布式搜索伺服器，具有高可伸縮、高可靠、易管理等特點。可以用於全文檢索、結構化檢索和分析，並能將這三者結合起來。【搜集、分析、存儲數據】
Kibana：可視化平台。它能夠搜索、展示存儲在 Elasticsearch 中索引數據。使用它可以很方便的用圖表、表格、地圖展示和分析數據。【圖形化展示日誌】
如果還是遇到性能瓶頸
使用filebeat收集日誌，先轉發到beat端的logstash1，然後logstash1轉發到kafka，然後再由logstash2從kafka讀取寫到elasticsearch。
2.架構升級：
架構解釋：
（1）首先用戶通過nginx代理訪問ELK日誌統計平台，這里的Nginx可以設置界面密碼。
（2）Nginx將請求轉發到kibana
（3）kibana到Elasticsearch中去獲取數據，這里的Elasticsearch是兩台做的集群，日誌數據會隨機保存在任意一台Elasticsearch伺服器。
（4）Logstash1從Kafka中取出數據並發送到Elasticsearch中。
（5）Kafka伺服器做日誌數據的持久化保存，避免web伺服器日誌量過大的時候造成的數據收集與保存不一致而導致日誌丟失，其中Kafka可以做集群，然後再由Logstash伺服器從Kafka持續的取出數據。
（6）logstash2從Filebeat取出的日誌信息，並放入Kafka中進行保存。
（7）Filebeat在客戶端進行日誌的收集。
注1：【Kafka的加入原因與作用】
整個架構加入Kafka，是為了讓整個系統更好的分層，Kafka作為一個消息流處理與持久化存儲軟體，能夠幫助我們在主節點上屏蔽掉多個從節點之間不同日誌文件的差異，負責管理日誌端（從節點）的人可以專注於向 Kafka里生產數據，而負責數據分析聚合端的人則可以專注於從 Kafka內消費數據。所以部署時要把Kafka加進去。
而且使用Kafka進行日誌傳輸的原因還在於其有數據緩存的能力，並且它的數據可重復消費，Kafka本身具有高可用性，能夠很好的防止數據丟失，它的吞吐量相對來說比較好並且使用廣泛。可以有效防止日誌丟失和防止logsthash掛掉。綜合來說：它均衡了網路傳輸，從而降低了網路閉塞，尤其是丟失數據的可能性，
注2：【雙層的Logstash作用】
這里為什麼要在Kafka前面增加二台logstash呢？是因為在大量的日誌數據寫入時，容易導致數據的丟失和混亂，為了解決這一問題，增加二台logstash可以通過類型進行匯總分類，降低數據傳輸的臃腫。
如果只有一層的Logstash，它將處理來自不同客戶端Filebeat收集的日誌信息匯總，並且進行處理分析，在一定程度上會造成在大規模日誌數據下信息的處理混亂，並嚴重加深負載，所以有二層的結構進行負載均衡處理，並且職責分工，一層匯聚簡單分流，一層分析過濾處理信息，並且內層都有二台Logstash來保障服務的高可用性，以此提升整個架構的穩定性。
⑨ 日誌管理分析系統架構設計求助
日誌管理分析系統架構設計
這個是一個可以難也可以簡單的系統~~~