.net大型网站应该如何架构才合理？
如题，
.net大型网站应该如何架构才合理 ？
一般是怎么搭建的 ？
真心求教 ！
[解决办法]
第一、建立架构良好的网站地图
用SEOer的话说：“网站地图首先是一个网页，这个网页主要是描述它所在网站的架构布局，访问者可以通过它陈列的网站内部分类链接快速找到自己所需要的信息。”还不了解什么是网站地图的朋友可以去百度一下。
建立网站地图的重要性
网站地图对大型网站很有必要，因为搜索引擎蜘蛛顺着网站链接爬行的深度一般最大不会超过三级，而大型的网站链接深度一般会在三级以上，例如新浪：首页>新闻中心>国内新闻>新闻的时间档>正文。因为大型网站信息量比较大，无论出发点是针对搜索引擎还是网站访问用户，作个网站地图是很理智的。
基于网站地图的特殊性质，一旦搜索引擎收录了一个网站的网站地图，那么搜索引擎蜘蛛程序就可以通过这个网页更好地来了解整个网站的架构布局，它可以顺着网站地图提供的内部链接来搜寻其他网页。一个网站如果被搜索引擎收录的页面数越多，那么访问者通过搜索引擎查找到该网站的范围就越大，这是很有助于增加网站的流量的。
简单的说，对于“人”这个用户来说，index页就是网站的首页，而对于“蜘蛛”这个用户来说，网站地图sitemap页就是它的首页。
如果创建一个网站地图？
思域推荐大家一个快速的方法
１。快速创建网站地图
下面先讲讲创建网站地图的几个步骤：
A、创建网站地图：
给大家推荐一个工具，可以在线创建网站地图，中文的界面，这是英文的界面
地图文件生成后，先下载到本地，然后上传到站点跟目录下。
再通过google帐户进行把网站和地图文件提交给Google Sitemaps。提交方法请继续下面的操作：
B、创建 Google 帐户：我要创建一个新的google帐户
C、登陆 google 帐户：进入我的google帐户
D、添加网站以及添加站点地图文件；
E、完成添加工作；
创建网站地图要注意什么？
注意两条
第一、 网站地图不要出现太多的链接，控制在100个链接以内，因为蜘蛛也是用户，它也会耍脾气，弄太多链接它反而抓不到重点。
第二、 网站地图要实用，不要太花哨，花太多时间在美工上，把网站地图弄得五颜六色，没有必要。网站地图最好是纯文本的内容，这样访问速度比较快，另外蜘蛛对文字链接比较喜欢，这里就不赞成采用图片或者FLASH来制作网站地图了，尤其是FLASH！
作为网站的访问者来说，蜘蛛要比人好对付，人看页面，蜘蛛看代码，如何增强这两个用户的体验，要分开来考虑。
说到网站的地址结构，就要分两部分来说，一个是物理结构，一个是逻辑结构，好像有点文绉绉的，我们说简单一点，就是网站中页面与页面的层次和关系。
网站地址的物理结构
包括扁平结构和树型结构。
扁平结构：
www.yourlink.com/pageA.html
www.yourlink.com/pageB.html
www.yourlink.com/pageC.html
……
网站中所有的页面都是在根目录这一级别，形成一个扁平的物理结构。这比较适合于小型的网站，因为如果太多文件都放在根目录下的话，制作和维护起来比较麻烦。
树型结构：
http://www. yourlink.com/cat1/
http://www. yourlink.com/cat2/
http://www. yourlink.com/cat3/
……
在频道下再放入具体的内容网页:
http://www. yourlink.com/cat1/pageA.html
http://www. yourlink.com/cat1/pageB.html
http://www. yourlink.com/cat1/pageC.html
……
树型结构就是在一级目录下分为多个频道或者称支为目录，然后目录下面再放上属于这个频道的页面，首页、频道首页、频道下的内容就好比树干、树枝、树叶的关系。
而作为大型网站常常采用树型结构，这个结构模型是我们要重点讨论的。
大家一定注意到了，现在很多网站的虽然也是采用树型结构，但是页面的地址组成是不同的。
一般有这两种形式
第一种是目录形式：www. yourlink.com/cat1/pageA.html
第二种是二级域名形式：cat1. yourlink.com/ pageA.html
谁优谁劣？对于大型网站，思域建议用二级域名的形式。
首先：搜索引擎会把二级域名当作一个独立的站点来看待，也就是说www. yourlink.com和cat1. yourlink.com是两个互相独立的网站。目录形式的www. yourlink.com/cat1/就纯粹是www. yourlink.com的一部分了。
如果抛开其他因素只看这两个URL，
cat1. yourlink.com
www. yourlink.com/cat1/
那么二级域名cat1. yourlink.com的权威度稍微高一点，因为搜索引擎会把这个URL当作是网站的首页。另外很多人观察到主域名很多时候会传递一小部分信任度给二级域名。
所以单就URL来看，二级域名比一级目录天生的信任度稍微高一点。这是其一。
其二：从搜索引擎的角度来说。
二级域名和主域名既然是两个完全不同的网站，那么一个门户网站的频道越多也就是二级域名越多，对于搜索引擎的蜘蛛来说你的网站数量就越多，好比动画片《猫和老鼠》一样，分成了好几个故事，每集都是一个新的故事，这样观众不会因为错过了上集而不容易理解这集，而且故事可能永远不会到头。对于网站也是一样，特别是大型的门户网站，他们的频道与频道都是独立的，比如财经频道与交友频道，几乎可以没有任何瓜葛。简单的说，就是二级域名可以使网站变多，但同时使网站变小，因为每个频道都有他对应的用户，大型用户无法做到每个用户都喜欢他的所有频道，每次上网站都要每个频道逛一遍，而搜索引擎的蜘蛛在你网站上爬行的时候，它会颇有成就感的说：“这本书我越读越薄了！”
所以从URL自身还是从搜索引擎的角度出发，新浪、网易等几大门户他们的频道采用二级域名的形式是有他们的道理的。
另外，思域强调一点，网站最好采用静态页面，因为
1）、HTML格式的静态页面容易被搜索引擎收录，并且容易获得较好排名；
2）、HTML格式的静态页面比较节省你的服务器资源，不怕你网站人气增加的快；
3)、Html格式的静态页面不需要调用数据库、用户浏览起来速度非常快
最后，不要再让你的网站地址中出现哪个频道或者页面用拼音的第一个字母来起名的可笑事情了，完全可以用英文或者拼音全拼，网站的“关于我们”居然用gywm.html,蜘蛛毕竟还是一个程序，他如何识辨gywm是什么意思啊！而网页的RUL名称和你网站中的关键字是有关系的，如果两者符合对你关键字的排名有好处。现在google和百度都可以识别英文和全拼了。
网站链接的逻辑结构
逻辑结构就是由网页内部链接所形成的逻辑的或链接的网络图。比较好的情况是逻辑结构与前面的树型物理结构相吻合。
如上图所示
主页链接向所有的频道主页
主页一般不直接链接向内容页，除非是你非常想推的几个特殊的页
所有频道主页都连向其他频道主页
频道主页都连回网站主页
频道主页也连向属于自己本身频道的内容页
频道主页一般不连向属于其他频道的内容页
所有内容页都连向网站主页
所有内容页都连向自己的上一级频道主页
内容页可以连向同一个频道的其他内容页
内容页一般不连向其他频道的内容页
内容页在某些情况下，可以用适当的关键词连向其他频道的内容页
频道形成分主题
这个逻辑也许用户看不到，但是蜘蛛看得到，不要让蜘蛛迷路就要注意不要让你的内部链接架构混乱。从逻辑结构来看，更加说明了大型网站采用二级域名对蜘蛛的体验是有好处的！
第三、积极的更新网站的内容
其实SEO只是提高网站关键字排名的一种手段，最重要的还是网站的内容和人气，google的宗旨是不作恶，对于google而言，用户对你的信任值和认同感越强，那么google就给你更高的权重，这就是为什么好多关键字都是新浪、网易、阿里巴巴这些门户的排在前面的原因。
所以网站所真正要花大力气去作的，就是提高网站的内容质量和更新频率，并且增加用户的体验，增强用户黏性，这才是网站推广的王道。
[解决办法]
1.ASP.NET的确不适合做大型的互联网类型的网站
2.JSP和ASP.NET更倾向于企业级应用
3.PHP是动态语言，专门做WEB的，之前CSDN是用.NET做的，不过现在已经过度到PHP了，为什么，想想吧！
大型网站架构不得不考虑的10个问题
1、海量数据的处理
众所周知，对于一些相对小的站点来说，数据量并不是很大，select和update就可以解决我们面对的问题，本身负载量不是很大，最多再加几个索引就可以搞定。对于大型网站，每天的数据量可能就上百万，如果一个设计不好的多对多关系，在前期是没有任何问题的，但是随着用户的增长，数据量会是几何级的增长的。在这个时候我们对于一个表的select和update的时候(还不说多表联合查询)的成本的非常高的。
2、数据并发的处理
在一些时候，2.0的CTO都有个尚方宝剑，就是缓存。对于缓存，在高并发高处理的时候也是个大问题。在整个应用程序下，缓存是全局共享的，然而在我们进行修改的时候就，如果两个或者多个请求同时对缓存有更新的要求的情况下，应用程序会直接的死掉。这个时候，就需要一个好的数据并发处理策略以及缓存策略。
另外，就是数据库的死锁问题，也许平时我们感觉不到，死锁在高并发的情况下的出现的概率是非常高的，磁盘缓存就是一个大问题。
3、文件存贮的问题
对于一些支持文件上传的2.0的站点，在庆幸硬盘容量越来越大的时候我们更多的应该考虑的是文件应该如何被存储并且被有效的索引。常见的方案是对文件按照日期和类型进行存贮。但是当文件量是海量的数据的情况下，如果一块硬盘存贮了500个G的琐碎文件，那么维护的时候和使用的时候磁盘的Io就是一个巨大的问题，哪怕你的带宽足够，但是你的磁盘也未必响应过来。如果这个时候还涉及上传，磁盘很容易就over了。
也许用raid和专用存贮服务器能解决眼下的问题，但是还有个问题就是各地的访问问题，也许我们的服务器在北京，可能在云南或者新疆的访问速度如何解决?如果做分布式，那么我们的文件索引以及架构该如何规划。
所以我们不得不承认，文件存贮是个很不容易的问题
4、数据关系的处理
我们可以很容易的规划出一个符合第三范式的数据库，里面布满了多对多关系，还能用GUID来替换INDENTIFY COLUMN 但是，多对多关系充斥的2.0时代，第三范式是第一个应该被抛弃的。必须有效的把多表联合查询降到最低。
5、数据索引的问题
众所周知，索引是提高数据库效率查询的最方面最廉价最容易实现的方案。但是，在高UPDATE的情况下，update和delete付出的成本会高的无法想想，笔者遇到过一个情况，在更新一个聚焦索引的时候需要10分钟来完成，那么对于站点来说，这些基本上是不可忍受的。
索引和更新是一对天生的冤家，问题A，D，E这些是我们在做架构的时候不得不考虑的问题，并且也可能是花费时间最多的问题。
6、分布式处理
对于2.0网站由于其高互动性，CDN实现的效果基本上为0，内容是实时更新的，我们常规的处理。为了保证各地的访问速度，我们就需要面对一个绝大的问题，就是如何有效的实现数据同步和更新，实现各地服务器的实时通讯有是一个不得不需要考虑的问题。
7、Ajax的利弊分析
成也AJAX，败也AJAX，AJAX成为了主流趋势，突然发现基于XMLHTTP的post和get是如此的容易。客户端get或者post 到服务器数据，服务器接到数据请求之后返回来，这是一个很正常的AJAX请求。但是在AJAX处理的时候，如果我们使用一个抓包工具的话，对数据返回和处理是一目了然。对于一些计算量大的AJAX请求的话，我们可以构造一个发包机，很容易就可以把一个webserver干掉。
8、数据安全性的分析
对于HTTP协议来说，数据包都是明文传输的，也许我们可以说我们可以用加密啊，但是对于G问题来说的话，加密的过程就可能是明文了(比如我们知道的QQ，可以很容易的判断他的加密，并有效的写一个跟他一样的加密和解密方法出来的)。当你站点流量不是很大的时候没有人会在乎你，但是当你流量上来之后，那么所谓的外挂，所谓的群发就会接踵而来(从qq一开始的群发可见端倪)。也许我们可以很的意的说，我们可以采用更高级别的判断甚至HTTPS来实现，注意，当你做这些处理的时候付出的将是海量的database，io以及CPU的成本。对于一些群发，基本上是不可能的。笔者已经可以实现对于百度空间和qq空间的群发了。大家愿意试试，实际上并不是很难。
9、数据同步和集群的处理的问题
当我们的一台databaseserver不堪重负的时候，这个时候我们就需要做基于数据库的负载和集群了。而这个时候可能是最让人困扰的的问题了，数据基于网络传输根据数据库的设计的不同，数据延迟是很可怕的问题，也是不可避免的问题，这样的话，我们就需要通过另外的手段来保证在这延迟的几秒或者更长的几分钟时间内，实现有效的交互。比如数据散列，分割，内容处理等等问题。
10、数据共享的渠道以及OPENAPI趋势
Openapi已经成为一个不可避免的趋势，从google，facebook，myspace到海内校内，都在考虑这个问题，它可以更有效的留住用户并激发用户的更多的兴趣以及让更多的人帮助你做最有效的开发。这个时候一个有效的数据共享平台，数据开放平台就成为必不可少的途径了，而在开放的接口的情况保证数据的安全性和性能，又是一个我们必须要认真思考的问题了。
我在说一个：丰富的开源技术与免费的资源利用
这些个问题，微软的解决方案就捉襟见肘了...一种语言，一种应用范围。中小型的网站你还可以考虑，想做互联网的若选择了ASP.NET，要想做大，早晚要过度的，一种语言，也连带了一系列产品，这个后果和后期的成本可谓巨大啊~
目前来看，用ASP.NET构建大型网站的相对来说还较少。.NET更多是倾向于企业级应用的。包括ASP.NET技术
