① 网站的基本架构是什么
网站架构按照制作步骤分为硬架构和软架构。
一、硬架构
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来保障服务的高可用性，以此提升整个架构的稳定性。
⑨ 日志管理分析系统架构设计求助
日志管理分析系统架构设计
这个是一个可以难也可以简单的系统~~~