商业源码 建门户网站需要什么技术?
0网站所选择的网络提供商：网通电信两个交叉通信很慢，考虑那些两个都接入速度很快的，比如网信通（我以前公司的网站和游戏都在上面）
1网站架构体系（WEB服务器？多少、数据库服务器多少？、缓存服务器、服务器、备份服务器）
2数据结构及数据算法（数据库结构一定要优化，如果表太大，请用分表设置模式，如果能分数据库参考petshop）
3缓存（大网站不能没有缓存：数据库缓存、数据缓存、页面缓存、缓存）
4压力测试（没有这个测试的大网站表搞笑了）
5代码优化（算法真tmd的很重要）
6开发架构（架构扩展性一定要考虑，很多时候架构能解决很多问题）
7测试测试再测试
8不停的监控在监控性能及运行状态
一个好的网站在进行实际页面的建置之前，首先要牢记用户优先，要考虑大多数人的连线状况、考虑使用者的浏览器，以及内容永远第一等等。
1、用户
无论什么时候，不管是着手准备设计HomePage之前，还是正在设计之中，甚或是已经设计完毕，有一个最高行动准则一定要牢记在心，那就是∶用户优先。因为没有用户去光顾，任何自认再好的HomePage都是没有意义的。
２、内容永远第一
“内容永远第一”，这句话适合书籍，更适合网络上的主页，而且几乎每个参与提供意见的人都举双手赞成这句话。没有内容的书籍令人讨厌，但至少您还可以很快判断出来，而HomePage呢？您可能得耗费一整个晚上的时间与金钱，才会发现原来站点里根本没有您要的东西，这种痛苦真不是三言两语可以形容。内容可以是任何东西，包括文字、、影像、声音等等，但请记住一点：一定要跟这个网站所要提供给人的讯息有关系。再提醒一次∶内容永远第一!
３、连线状况
您或许使用办公室的ISDN，也可能使用学校的高速专线，但您都必须想到，目前大多数人所使用的还是通过电话线路的缓慢连线方式 ，而且“塞车”塞得很严重。所以您在设计HomePage时就必需以这种普遍的连线状况为设计的参考量，不要放置一堆会加重塞车情形或让人等得发火的玩艺儿。最后，完成之后, 您最好自己使用“小猫”联网亲自测试一下。
４、浏览器
必需考虑使用者的浏览器软件，如果您想要让所有的人都可以毫无障碍地观看您的页面，那么最好使用所有浏览器都可以阅读的格式，不要使用只有部分浏览器支持的格式或程序技巧。如果想要展现自己的高超的技术又不想放弃一些潜在的观众，可以考虑在主页中设置几种不同的观赏模式选项（例如纯文字模式、Frame模式、Java模式等等），供浏览者自行选择。
再来看看在著手HomePage的实际建置过程中，应该重点掌握的几个原则。
５、着手规划、确定特色、锁定目标
不管做什么事，一定要进行规划，建设网站尤其如此。规划时必须确定自己网站的性质、提供的内容、目标用户，然后根据本身的软硬件及人员技术条件来设置范围。网络的特点是及时、新鲜、丰富、热闹，这是吸引大家上网的因素，如果本身条件强大，也可以根据上述原则使自己网站成为一个“全方位”信息的提供者，如果不足，就考虑提供单方面的信息；此外，还可以在特殊议题或主题上加以突出，进一步锁定目标观众。
6、首页
首页是最重要的部分，因为它是别人接触这个网站的第一眼。如果是新的站点，最好在第一页就对这个网站的性质与所提供的内容做个扼要说明与导引，让别人判断要不要继续点击。最好第一页就有很清楚的类别栏目选项，而且尽量人性化，让浏览者可以很快找到需要的东西。在设计上，最好秉持干净而清爽的原则。第一、若无需要，尽量不要放置大图或加上不当的程序，因为它会增加下载的时间，导致浏览者失去耐心； 第二、画面不要设计得太过杂乱无章，因为观赏者会找不到所要的东西。记住∶失败的首页会让许多人一去不返……
7、分类
内容的分类很重要，可以按主题分类、按性质分类、或按人类思考的习惯分类等等。一般而言，按大家思考的习惯分类会比较亲切。但无论哪一种分类方法，都要让使用者很容易地找到目标。此外要注意，分类标准最好保持一致，当然，在每个分类选项的旁边或下一行，加上这个选项内容的简要说明最好。
8、互动性
WWW的另一个特色就是“互动”。好的网站，HomePage应该与使用者有良好的互动性，包括在整个设计呈现、使用介面导引上等等，都应该掌握互动的原则，让使用者感觉他的每一步都确实得到适当的回应，这部分需要一些设计上的技巧与软硬件支持。事实上，好的网站设计肯定是个人技巧、经验累积以及软硬件技术的成功配合。如果你要在网页互动性上下功夫，那么flash是你最好的工具。
9、图形应用技巧
图形是网站的特色之一，它有醒目、吸引人以及传达讯息的功能。好的图形应用可以使页面增色，但不当的图形应用则会带来反效果，而其中又应以大量使用毫无意义的大图为戒。笔者建议，如果可以，应尽量缩小或省略图形。目前国内的网络传输资源极为有限，因此使用图形时一定要考虑传输时间的问题。根据经验与统计，用户可以忍受的最长等待时间大约是90秒钟，如果你的页面无法在这段时间内传输并显示完毕，那么浏览者就会不耐烦地掉头离去。因此必须依据页面文件的大小，考虑传输速率、延迟时间、网络交通状况，以及服务端与使用者端的软硬件条件，估传输与显示的时间。在图形使用上，要采用一般浏览器均支持的压缩图形格式，例如JPEG与GIF等，而其中JPEG的压缩效果较好，适合中大型的，可以节省传输时间。如果真要放置大型图形文件，最好将图形文件与HomePage分开，在HomePage中先显示一个具有链接功能的缩小图档或是一行说明文字，然后加上该图形文件大小的说明（例如160KB），如此，不仅加快HomePage的传输，而且可以让使用者判断是否继续点击观看。
10、图形加上说明
此外，还有一点要特别提醒，许多版主常常忽略了这件事——为了节省传输时间，许多浏览者习惯采用“关闭图形”的模式浏览你的站点。因此，在你在放置图形时，一定要记得为每个图形加上不显示时的“说明文字”（也就是在HTML文件中的图形文件后面加上alt文字说明），如此，使用者才能知道这个图形的内容，判断要不要观看。特别是如果这个图形具有链接的功能时，千万记得加上说明文字，并给其设置同样的链接功能。
11、背景底色
不少人喜欢在HomePage中加上背景图案，认为如此可以增加美观，但却不知这样会耗费传输的时间，而且容易影响阅读者的视觉，反而给人不好的印象。笔者建议，若没绝对必要，要避免使用背景图案，保持干净清爽的文本。但如果真的使用背景，那么最好使用单一色系，而且要跟前景的文字明显区别，最忌讳使用花俏多色的背景。
12、HTML格式的注意事项
有关HTML的撰写方面，应注意以下的一些注意事项：不少人在撰写HTML文件时，会简略一些命令格式，但为了日后维护方便，撰写HTML时最好架构完整，而且初学者也可以藉此对HTML语法有个充分的认识。另外，如果你的网站想让别人可以透过搜寻站来找到，那么千万不要忘了在〈Title〉指令中加上可供搜寻的“关键字”串。为了增加与使用者的互动，页面中最好加上可供使用者发表意见的E－mail信箱，在HTML中一定要注意它的格式命令写法，许多人在这个地方常常写错。另外，在PC系统下，文件的大小写不分，但在UNIX系统下，则大小写有区分，需要注意。
13、不要滥用技术
技术是令人着迷的东西，许多人喜欢玩弄技术——好的技术运用会让页面栩栩如生，令人叹为观止；但不当的技术则会适得其反。首先，使用技术时一定要考虑传输时间，不要成为他人浏览的沉重负担；其次，技术一定要与网站的性质及内容相配合，不要耍一大堆不相干的技术。有一个最常见的技术应用，就是利用javascript撰写一个“走马灯”的功能，让文字可以动态地显示在窗口的最下一栏，这种方式看起来似乎很酷，但却容易遮住该位置原本用来显示地址及传输状态的内容，反而造成不便。何况既然只是显示一两个文字，何不直接放在HTML本文中呢？Java小程序也是目前网络上的常见技术，它是一个好用的利器，擅长于动态物象的呈现，虽然只要浏览器支持就可以动，但同样要考虑传输时间，以及一般人的电脑系统负荷等问题。最后，技术最好不要用得太过多样而复杂，有些人似乎不展现功力就不爽，所以不管合不合适，就把所有可用的他会的技术全部用在里面，这时大家就会看到一个惨不忍睹的页面。
14、即时更新维护
不要忘记，大家都想看“新鲜”的东西，没人对过时的信息有兴趣，所以资料一定要注意即时性。有些网站半年没更新，感觉就像一池死水。如果想要经营一个带有“即时”性质的网站，除了注意内容外，资料还要记得每日更新。笔者建议，不妨每隔一阵子就对页面设计做一次小翻新，时时保持新鲜感。最后，须考虑的就是事后维护与管理的问题，写HomePage很简单，但维护管理就比较繁人，它的工作机械而死板。个人性质的网站在维护管理上比较简单，但公司网站的工作量就大了。
15、大胆地自我宣传
“毛遂自荐”想必大家都知道吧，INTERNET也同样适用。试想，茫茫INTERNET谁会发现你这只小舟，因此，多宣传自己才是上策。到YAHOO等站点留下一“笔”，相信会有更多的网友发现你的。
一、 补充方案说明
为了完善网站除了内容以外的其他需求，我们特意提出需要增加比如性能、页面大小、页面加载时间、安全等补充需求，使得用户更加快捷更加方便浏览和使用网站资源，根据实际情况整理出该补充方案。
二、 补充内容
1 网站运行技术框架要求
技术范围 说明
net20
MSSQL2005
JMAIL
IIS60
SERV-U
AJAX
HTML
W3C
JAVASCRIPT
2 网站浏览速度要求（10月份速度、页面大小要求）
网页的加载速度与网页内容大小成正比，网页越大，加载越慢，网页越小加载越快
1) 网页加载速度
标准 6秒
慢 > 10秒
非常慢 > 20秒
快 <5秒
非常快 <2秒
2) 网页大小
标准 350k
大 > 400k
非常大 > 500k
小 <250k
非常小 <150k
3) 首页加载速度必须小于6秒
4) 订餐网页加载速度必须小于8秒
5) 网页服务器缓存
6) 网页缓存
7) 减少页面大小
说明：此要求为10月份网站速度、页面大小要求。
3 网站兼容性要求
兼容浏览器 说明
IE6 完全兼容
Ie6补丁打全后 完全兼容
IE7 完全兼容
FIREFOX 完全兼容
TT 完全兼容
遨游 流畅订餐流程
4 网站安全性要求
1) 无SQL注入点
1 字符注入
2 数字注入
3 其他注入
2) 敏感Cookie必须加密
1 用户数字id
2 订单信息
3) 过滤cookie欺骗程序
4) 无错误明细输出给客户，返回我们定义好的错误信息给客户
5) 权限受限严格验证
5 稳定性要求
1) 程序无明显错误，如：不定期出现某些乱码问题
2) 并发用户达到500人/秒正常运行
6 可靠性要求
1) 保证安全性能
2) 保证稳定性
7 搜索引擎优化需求
1) 页面TITLE要求显示不同页不同TITLE，并显示豆丁网名称关键字
2) 页面内关键字
3) 网站遍历功能
4) 餐馆遍历功能
大型电子商务网站架构，摘抄7同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别===客户是自己公司，使用标准方法即可
8电子商务网站最多的就是商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)===采购成熟的规则引擎
9如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢
==电子商务一般要使用MQ，推荐IBMMQ；使用MSMQ也可
第一点是数据库要设计好，要达到什么级别，你可能需要考虑哪些表需要拆分，哪些表的核心数据需要冗余，如果是mysql，还要考虑其他的问题，比如存储引擎。
新闻肯定是要生成纯静态页，对数据库压力就小很多，不过静态页也有管理上的不方便，更新删除添加都要对磁盘文件进行操作
做一个自定义缓存层，对缓存逻辑进行控制，可以采用第三方缓存模块，如果使用net来做，可以层层缓存，页面缓存，数据缓存（memcache，不过在win下效率不高）
电子商务网站特点就是对事务的严格，需要数据库设计的时候要求高性能，也需要合适的索引，支持高并发，经常对产品表用户表等进行索引检查，是否有很多索引扫描和表扫描（即使是局部的，也要将“局部”控制到最小范围）
mssql语句对不需要事务的查询要附带上with(nolock),以利于并发更新。
有些功能模块不能按照想当然的方式开发，比如产品访问次数，切不可将这些更新非常频繁的字段置于核心表内，明确的做法是将其剥离开来还有就是切不可经常性将字段设计成bool类型，这样会给以后的扩展留出路，即使是男女这种字段，也建议采用tiny类型
其他还有就是在产品设计的时候充分考虑seo，网站目录结构清晰可读，而不是带着一串串的查询参数。
对安全要有整体的把握，最好全都是用存储过程，在项目上线前将数据库存储过程全部导出再查找貌似exec的语句，查找是否需要替换成sp_executesql。
另外，如果采用mssql，全文搜索直接用mssqlfte就可以，速度和精确度都还是可以的，最重要的是维护和管理开发很简单。
打折的处理可以按照电信的一次，二次批价功能，如果你做过电信方面的系统。
当然也可以设计得更简单的一些。静态的页面建议使用CDN加速，以解决网通和电信之间访问速度的问题；
数据的缓存方面建议考虑用memcache，另外也可以分别在表现层和数据层利用net中的现存缓存机制作业可；
简单执行的sql可以不用存储过程，存储过程会占用数据库服务器的处理时间，造成死锁；
mvc建议还是做些CMS的项目上应用，电子商城不是很适合，个人观点。url上可以做转义，使url显示更友好；
数据库建议建立分布数据库，这样可以转移查询和大访问量对数据库带来压力；
可以考虑单独放在一台服务器上；1三层架构
2使用手写sql,手写entity(生成也可),缓存反射绑定(不是缓存数据哦,缓存映射关系),要考虑网站的长期发展还是手写吧灵活性能也好
3没有这种问题,商业驱动的,纯购物就好了,千万别搞什么圈子,wiki
4纯net的mvc不建议,webform不搞viewstate,不搞服务端控件(除repeater)再加点mvc的思想已足够用了
5不需要缓存数据(除搜索产品部分),要考虑多台服务器的程序快速部署,config文件会很多,config要序列化缓存
6当然是先生成好了,参照jd吧,按业务每张对应几个不同大小的图
7据经验,电子商务网站仅靠中英双语来达到多语言是不靠谱的(文化用户习惯不是简单的语言切换),如果想真正运营英语的就要重新开发一个版本
8不搞模式
9负载均衡(web,db)+ssb异步处理数据
10你是业务类型的日志还是异常日志前台订单流程上异常日志不需要了,找个工具录个脚本不停的跑保证随时发现问题发邮件就可以了
11找第三方搜索组件类似endeca的
12负载均衡挺简单的,初期靠软件就可以,一切找第三方放cdn,前台网站用到ajax的地方很少,如果用的话jquery1，一个电子商务网站用户995%的行为时Find
2、对于商品检索部分，能不用数据库就不用数据库（网上切词等相关的开源平台很多）
3、分布式缓存（Memcached、Volecity），个人测试volecity3还是不错的
4、系统设计时必须要考虑可运营。从这个角度去设计系统
5、对于电子商务网站改动很频繁，必须考虑架构设计如何适应频繁的版本更新
6、必须设计一个好的单点登录系统。
7、建议能不用sqlserver就不用它。
8、对于大型电子商务网站来说，系统的I/O是起决定因素而不是CPU和内存。1项目划分是否会有问题,图中分别是实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
项目划分其实不重要，重要的的是你在写代码的时候是否能把代码合理的分到对应的项目里。
2数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层
开发效率优先，访问量大了以后，我相信是有钱投到硬件上的，在你程序写的不是很烂的情况下，升级硬件远比优化程序节省成本。
3网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢
那就做成自定义控件啦。
4ms的mvc10也出来不少时间了,是否已经够成熟运用到项目中或者是网站后台使用webform的,前台使用mvc
推荐使用使用webform的,前台使用mvc，对于前台来说使用mvc能更好的提升性能，更方便的更换页面表现形式。后台界面相对稳定，用webform可以提高开发效率。
5网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached
初期建议用hashtable，因为简单，将来升级到Memcached。
6缩略图的处理,我看有的网站是在上传的时候直接生成,有的是在httpmodle里处理,访问的时候生成
直接生成缩略图的好处是节约性能。httpmodle相反，每次浏览的时候都会生成新的，服务器压力大，建议直接生成。
7同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别
多语言建议使用aspnet自带的资源文件的方式实现，当前语言保存在cookie里面。
8电子商务网站最多的就是商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)
规则引擎
9如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢
使用MQ队列
10日志方面,log4net
log4net只能记录程序运行日志，主要目的是用来调试程序的，系统业务操作日志还你是得自己建一个表来保存。
11电子商务的全文检索,这也是个头疼的问题
lucene，微软索引服务，sqlserver全文检索，方案很多的。
12负载均衡方面,有什么好的文章推荐码
可以看windows2003集群方面的文章1项目划分是否会有问题,图中分别是实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
目前我也是这样分的,不过当数据表结构有修改时,会带动其它层的联级修改,非常不方便，所以开发之前最好将数据库设计地完善一点。另外，当网站分成多个以后，其它项目生成的DLL文件要部署到每个网站的bin文件夹里，更新一次都要重新部署，这也是个挺烦人的事，当然可以将DLL部署到GAC里来解决这个问题，不过这样的话本地调试起来就不太方便了，因为项目一有改动，就要将生成的DLL重新拷贝到GAC里才能看到效果。
2数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层
这个我也在考虑。目前我还没有采用ORM框架，都是在DAL里直接访问DB的。
3网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢
自定义控件。
4ms的mvc10也出来不少时间了,是否已经够成熟运用到项目中或者是网站后台使用webform的,前台使用mvc
正在学习这一块。
5网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached
现在我用的比较多的是net自带的数据缓存。
6缩略图的处理,我看有的网站是在上传的时候直接生成,有的是在httpmodle里处理,访问的时候生成
直接生成好，快一点。
7同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别
我没涉及到这一块，不过我觉得资源文件应该就是用来处理这个问题的。
8电子商务网站最多的就是商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)
这些都放在逻辑层好了。
9如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢
MSMQ
10日志方面,log4net
目前我是自已写代码存在库里的。
11电子商务的全文检索,这也是个头疼的问题
用lucenenet分词建索引，再直接从索引库里搜索，又快又准。
12负载均衡方面,有什么好的文章推荐码
不清楚了。这样的设计要达到新蛋的效果肯定不可能的，新蛋少说几百台服务器，不同数据库之间的发布订阅链路都有几千条。有复杂的缓存，负载均衡机制。新蛋所有的通讯都是基于WCF的。另外对于这么大型的网站来说，数据库一刻都不停止，所以读写分离也很重要，因为你也不可能让数据库停下来进行备份。总归要做到新蛋这样的大型电子商务网站，靠你上面画的这点好像远远不够。
不过关于公共的header,footer,我不建议做成自定义控件，这个维护起来不方便，稍有变动就要发布dll，麻烦的。
如果你的header和footer不是很大的话，建议采用js+css的方式。然后加上压缩和cdn缓存，应该效率上能接受。
一个小型的网站，比如个人网站，可以使用最简单的html静态页面就实现了，配合一些达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单，随着互联网业务的不断丰富，网站相关的技术经过这些年的发展，已经细分到很细的方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。
大型网站，比如门户网站。在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。但是除了这几个方面，还没法根本解决大型网站面临的高负载和高并发问题。
上面提供的几个解决思路在一定程度上也意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性，下面我从低成本、高性能和高扩张性的角度来说说我的一些经验。
1、HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。
2、服务器分离
大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，是最消耗资源的，于是我们有必要将与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的服务器，甚至很多台服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为问题而崩溃，在应用服务器和服务器上，可以进行不同的配置优化，比如apache在配置ContentType的时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。
3、数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。
在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。
上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。
4、缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memory Cache是常用的缓存接口，可以在web开发中使用，比如用Java开发的时候就可以调用MemoryCache对一些数据进行缓存和通讯共享，一些大型社区使用了这样的架构。另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块，Java就更多了，net不是很熟悉，相信也肯定有。
5、镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。
6、负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择，我个人接触过一些解决方法，其中有两个架构可以给大家做参考。
1）硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。 第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。
在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。
2）软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常容易。这样的架构我准备空了专门详细整理一下和大家探讨。
一：高并发高负载类网站关注点之数据库
没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web20的应用，数据库的响应是首先要解决的。
一般来说MySQL是最常用的，可能最初是一个mysql主机，当数据增加到100万以上，那么，MySQL的效能急剧下降。常用的优化措施是M-S（主-从）方式进行同步复制，将查询和操作和分别在不同的服务器上进行操作。我推荐的是M-M-Slaves方式，2个主Mysql，多个Slaves，需要注意的是，虽然有2个Master，但是同时只有1个是Active，我们可以在一定时候切换。之所以用2个M，是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡，可以结合LVS,从而将select操作适当的平衡到不同的slaves上。
以上架构可以抗衡到一定量的负载，但是随着用户进一步增加，你的用户表数据超过1千万，这时那个M变成了SPOF。你不能任意扩充Slaves，否则复制同步的开销将直线上升，怎么办？我的方法是表分区，从业务层面上进行分区。最简单的，以用户数据为例。根据一定的切分方式，比如id，切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询，会增加一次，比如你要查一个用户nightsailer,你首先要到全局数据库群找到nightsailer对应的cluster id，然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式，或者m-m-slaves方式。这是一个可以扩展的结构，随着负载的增加，你可以简单的增加新的mysql cluster进去。
需要注意的是：
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接（不要用pconnect）,相反，使用sqlrelay这种第三方的数据库链接池，或者干脆自己做，因为php4中mysql的链接池经常出问题。
二：高并发高负载网站的系统架构之HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化 http://wwwablanxuecom/shtml/201207/776shtml的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是 最有效的方法。但是对于大量内容并且频繁更新的网站，我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点 的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限 管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。
除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。
同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛 中论坛的公用设置信息，这些信息目前的主流论坛都可以进行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这 部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求高并发。
网站HTML静态化解决方案
当一个Servlet资源请求到达WEB服务器之后我们会填充指定的JSP页面来响应请求:
HTTP请求---Web服务器---Servlet--业务逻辑处理--访问数据--填充JSP--响应请求
HTML静态化之后:
HTTP请求---Web服务器---Servlet--HTML--响应请求
静态访求如下
Servlet:
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
if(requestgetParameter("chapterId") != null){
String chapterFileName = "bookChapterRead_"+requestgetParameter("chapterId")+"html";
String chapterFilePath = getServletContext()getRealPath("/") + chapterFileName;
File chapterFile = new File(chapterFilePath);
if(chapterFileexists()){responsesendRedirect(chapterFileName);return;}//如果有这个文件就告诉浏览器转向
INovelChapterBiz novelChapterBiz = new NovelChapterBizImpl();
NovelChapter novelChapter = novelChapterBizsearchNovelChapterById(IntegerparseInt(requestgetParameter("chapterId")));//章节信息
int lastPageId = novelChapterBizsearchLastCHapterId(novelChaptergetNovelId()getId(), novelChaptergetId());
int nextPageId = novelChapterBizsearchNextChapterId(novelChaptergetNovelId()getId(), novelChaptergetId());
requestsetAttribute("novelChapter", novelChapter);
requestsetAttribute("lastPageId", lastPageId);
requestsetAttribute("nextPageId", nextPageId);
new CreateStaticHTMLPage()createStaticHTMLPage(request, response, getServletContext(),
chapterFileName, chapterFilePath, "/bookReadjsp");
}
}
生成HTML静态页面的类:
package comjby2t034thefifthwebservlet;
import javaioByteArrayOutputStream;
import javaioFileOutputStream;
import javaioIOException;
import javaioOutputStreamWriter;
import javaioPrintWriter;
import javaxservletRequestDispatcher;
import javaxservletServletContext;
import javaxservletServletException;
import javaxservletServletOutputStream;
import javaxservlethttpHttpServletRequest;
import javaxservlethttpHttpServletResponse;
import javaxservlethttpHttpServletResponseWrapper;
/
创建HTML静态页面
功能：创建HTML静态页面
时间：2009年1011日
地点：home
@author mavk
/
public class CreateStaticHTMLPage {
/
生成静态HTML页面的方法
@param request 请求对象
@param response 响应对象
@param servletContext Servlet上下文
@param fileName 文件名称
@param fileFullPath 文件完整路径
@param jspPath 需要生成静态文件的JSP路径(相对即可)
@throws IOException
@throws ServletException
/
public void createStaticHTMLPage(HttpServletRequest request, HttpServletResponse response,ServletContext servletContext,String fileName,String fileFullPath,String jspPath) throws ServletException, IOException{
responsesetContentType("text/html;charset=gb2312");//设置HTML结果流编码(即HTML文件编码)
RequestDispatcher rd = servletContextgetRequestDispatcher(jspPath);//得到JSP资源
final ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();//用于从ServletOutputStream中接收资源
final ServletOutputStream servletOuputStream = new ServletOutputStream(){//用于从HttpServletResponse中接收资源
public void write(byte[] b, int off,int len){
byteArrayOutputStreamwrite(b, off, len);
}
public void write(int b){
byteArrayOutputStreamwrite(b);
}
};
final PrintWriter printWriter = new PrintWriter(new OutputStreamWriter(byteArrayOutputStream));//把转换字节流转换成字符流
HttpServletResponse httpServletResponse = new HttpServletResponseWrapper(response){//用于从response获取结果流资源(重写了两个方法)
public ServletOutputStream getOutputStream(){
return servletOuputStream;
}
public PrintWriter getWriter(){
return printWriter;
}
};
rdinclude(request, httpServletResponse);//发送结果流
printWriterflush();//刷新缓冲区，把缓冲区的数据输出
FileOutputStream fileOutputStream = new FileOutputStream(fileFullPath);
byteArrayOutputStreamwriteTo(fileOutputStream);//把byteArrayOuputStream中的资源全部写入到fileOuputStream中
fileOutputStreamclose();//关闭输出流，并释放相关资源
responsesendRedirect(fileName);//发送指定文件流到客户端
}
}
初始阶段的网站架构
大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如图。
应用程序，数据库，文件等所有的资源都在一台服务器上。通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySql，汇集各种开源软件及一台廉价服务器就可以开始网站的发展之路了。
应用服务和数据服务分离
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，这时就需要将应用和数据分离，应用和数据分离后整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器，如下图所示，这三台服务器对硬件资源的要求各不相同，应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU,数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存，文件服务器需要储存大量用户上传的文件，因此需要更大的硬盘。
应用和数据分离后，不同特性的服务器承担不同的服务角色，网站的并发处理能力和数据存储空间得到了很大改善，支持网站业务进一步发展，但是随着用户逐渐增多，网站又一次面临挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，用户体验受到影响，这时需要对网站架构进一步优化。
使用缓存改善网站性能
网站访问特点和现实世界的财富分配一样遵循二八定律：80%的业务访问集中在20%的数据上。淘宝买家浏览的商品集中在少部分成交数多、评价良好的商品上；百度搜索关键词集中在少部分热门词汇上；经常登录的用户才会发微博、看微博，而这部分用户也只占总用户数目的一小部分。
既然大部分的业务访问集中在，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力。网站使用的缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数量有限，而且会出现和应用程序争用内存的情况。远程分布式可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。
使用缓存后，数据访问压力得到有效缓解，但是单一应用服务器能够处理的请求连接有限，在网站的访问高峰期，应用服务器会成为整个网站的瓶颈。
使用应用服务器集群改善网站的并发处理能力
使用集群是网站解决高并发，海量问题的常用手段，当一台服务器的处理能力、储存空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求，这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。
对网站而言，只要能通过一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性，应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。如下图所示。
通过负载均衡调度服务器，可将来自用户浏览器的请求分发到应用服务器集群中的任何一台服务器上，如果有更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不在成为网站的瓶颈。
数据库读写分离
网站使用缓存后，大部分数据操作访问都可以不通过数据库就能完成，但是仍有一部分读操作，(缓存访问不命中、缓存过期)和全部的写操作，需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。网站利用数据库的这一功能，实现数据库读写分离，从而改善数据库负载压力。
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库或得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离时对应用透明。
使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，是用户在请求网站服务时，可以从距离自己最近的网路提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接给用户。
使用分布式文件系统和分布式数据库系统
分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用，不到万不得以时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。
使用NOSQL和搜索引擎
对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。
业务拆分
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现
分布式服务
这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择
0条评论