1、大型网站架构模式有哪些
1.分布式
对于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。分布式意味着可以使用更多的计算机完成同样的功能，计算机越多，CPU、内存、存储资源也就越多，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
2.分层
分层是企业应用系统中最常见的一种架构模式，将系统在横向维度上切分成几个部分，每个部分负责一部分相对比较单一的职责，然后通过上层对下层的依赖和调用组成一个完整的系统。
分层结构在计算机世界中无处不在，网络的7层通信协议是一种分层结构；计算机硬件、操作系统、应用软件也可以看作是一种分层结构。在大型网站架构中也采用分层结构，将网站软件系统分为应用层、服务层、数据层。
3.分割
如果说分层是将软件在横向方面进行切分，那么分割就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分割开来，包装成高内聚低耦合的模块单元，一方面有助于软件的开发和维护；另一方面，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
4.集群
使用分布式虽然已经将分层和分割后的模块独立部署，但是对于用户访问集中的模块（比如网站的首页），还需要将独立部署的服务器集群化，即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。
5.缓存
缓存就是将数据存放在距离计算最近的位置以加快处理速度。缓存是改善软件性能的第一手段，现代CPU越来越快的一个重要因素就是使用了更多的缓存，在复杂的软件设计中，缓存几乎无处不在。大型网站架构设计在很多方面都使用了缓存设计。
6.异步
计算机软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，就越少被彼此影响，越可以独立发展。大型网站架构中，系统解耦合的手段除了前面提到的分层、分割、分布等，还有一个重要手段是异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方式异步执行进行协作。
2、大型网站架构该怎么优化设计
你得把你的网站拿出来看了才知道怎么优化改进。并不是说每个网站的优化思路都一样。比如，你优化结构之前你得考虑你的长尾关键词要怎么扩展，长尾词是不是有规律可循。如果有规律，你可以直接利用程序生成标题，生成内容。要根据你的设计思路去设计网站结构。要是每个网站优化思路都一样，那为什么不直接程式化，还拿优化运营来做什么？自动化多好。但是，这是不现实的。所以，你的提问没人能帮得到你。
3、电子商务网站一般架构有哪些
大型电子商务网站架构，摘抄 7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?===客户是自己公司，使用标准方法即可
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?===采购成熟的规则引擎
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
==电子商务一般要使用MQ，推荐IBM MQ；使用MSMQ也可
第一点是数据库要设计好，要达到什么级别，你可能需要考虑哪些表需要拆分，哪些表的核心数据需要冗余，如果是mysql，还要考虑其他的问题，比如存储引擎。
新闻肯定是要生成纯静态页，对数据库压力就小很多，不过静态页也有管理上的不方便，更新删除添加都要对磁盘文件进行操作
做一个自定义缓存层，对缓存逻辑进行控制，可以采用第三方缓存模块，如果使用.net来做，可以层层缓存，页面缓存，数据缓存（memcache，不过在win下效率不高）
电子商务网站特点就是对事务的严格，需要数据库设计的时候要求高性能，也需要合适的索引，支持高并发，经常对产品表用户表等进行索引检查，是否有很多索引扫描和表扫描（即使是局部的，也要将逗局部地控制到最小范围）
mssql语句对不需要事务的查询要附带上with(nolock),以利于并发更新。
有些功能模块不能按照想当然的方式开发，比如产品访问次数，切不可将这些更新非常频繁的字段置于核心表内，明确的做法是将其剥离开来 还有就是切不可经常性将字段设计成bool类型，这样会给以后的扩展留出路，即使是男女这种字段，也建议采用tiny类型
其他还有就是在产品设计的时候充分考虑seo，网站目录结构清晰可读，而不是带着一串串的查询参数。
对安全要有整体的把握，最好全都是用存储过程，在项目上线前将数据库存储过程全部导出再查找貌似exec的语句，查找是否需要替换成sp_executesql。
另外，如果采用mssql，全文搜索直接用mssql fte就可以，速度和精确度都还是可以的，最重要的是维护和管理开发很简单。
打折的处理可以按照电信的一次，二次批价功能，如果你做过电信方面的系统。
当然也可以设计得更简单的一些。 静态的页面建议使用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的地方很少,如果用的话jquery 1，一个电子商务网站用户99.5%的行为时Find
2、对于商品检索部分，能不用数据库就不用数据库（网上切词等相关的开源平台很多）
3、分布式缓存（Memcached 、Volecity），个人测试volecity 3还是不错的
4、系统设计时必须要考虑可运营。从这个角度去设计系统
5、对于电子商务网站改动很频繁，必须考虑架构设计如何适应频繁的版本更新
6、必须设计一个好的单点登录系统。
7、建议能不用sqlserver就不用它。
8、对于大型电子商务网站来说，系统的I/O是起决定因素而不是CPU和内存。1.项目划分是否会有问题,图中分别是 实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
项目划分其实不重要，重要的的是你在写代码的时候是否能把代码合理的分到对应的项目里。
2.数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)?是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层?
开发效率优先，访问量大了以后，我相信是有钱投到硬件上的，在你程序写的不是很烂的情况下，升级硬件远比优化程序节省成本。
3.网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢?
那就做成自定义控件啦。
4.ms的mvc 1.0也出来不少时间了,是否已经够成熟运用到项目中?或者是网站后台使用webform的,前台使用mvc?
推荐使用使用webform的,前台使用mvc，对于前台来说使用mvc能更好的提升性能，更方便的更换页面表现形式。后台界面相对稳定，用webform可以提高开发效率。
5.网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached ?
初期建议用hashtable，因为简单，将来升级到Memcached 。
6.缩略图的处理,我看有的网站是在上传图片的时候直接生成,有的是在httpmodle里处理,访问的时候生成.
直接生成缩略图的好处是节约性能。httpmodle相反，每次浏览图片的时候都会生成新的图片，服务器压力大，建议直接生成。
7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?
多语言建议使用asp.net自带的资源文件的方式实现，当前语言保存在cookie里面。
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?
规则引擎
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
使用MQ队列
10.日志方面,log4net?
log4net只能记录程序运行日志，主要目的是用来调试程序的，系统业务操作日志还你是得自己建一个表来保存。
11.电子商务的全文检索,这也是个头疼的问题
lucene，微软索引服务，sqlserver全文检索，方案很多的。
12.负载均衡方面,有什么好的文章推荐码?
可以看windows 2003 集群方面的文章 1.项目划分是否会有问题,图中分别是 实体层,数据访问接口层,数据访问层,业务逻辑接口层,业务逻辑,网站A,B,C
目前我也是这样分的,不过当数据表结构有修改时,会带动其它层的联级修改,非常不方便，所以开发之前最好将数据库设计地完善一点。另外，当网站分成多个以后，其它项目生成的DLL文件要部署到每个网站的bin文件夹里，更新一次都要重新部署，这也是个挺烦人的事，当然可以将DLL部署到GAC里来解决这个问题，不过这样的话本地调试起来就不太方便了，因为项目一有改动，就要将生成的DLL重新拷贝到GAC里才能看到效果。
2.数据访问层是要开发效率(NBear,Linq,Nh等),还是访问效率(直接使用sql等)?是否可以先使用开发效率高的,等日后访问量大了,再重写并替换数据访问层?
这个我也在考虑。目前我还没有采用ORM框架，都是在DAL里直接访问DB的。
3.网站被切割成了多个子网站,有一些控件(如header,footer)是要共享的,如何跨网站项目共享这些控件呢?
自定义控件。
4.ms的mvc 1.0也出来不少时间了,是否已经够成熟运用到项目中?或者是网站后台使用webform的,前台使用mvc?
正在学习这一块。
5.网站数据的缓存是自己开发一个hashtable什么的来维护呢,还是使用Memcached ?
现在我用的比较多的是.net自带的数据缓存。
6.缩略图的处理,我看有的网站是在上传图片的时候直接生成,有的是在httpmodle里处理,访问的时候生成.
直接生成好，快一点。
7.同一个网站的多语言该如何处理是好,使用配置文件然后cookie或url来判别?
我没涉及到这一块，不过我觉得资源文件应该就是用来处理这个问题的。
8.电子商务网站最多的就是 商品的打折方式和积分的赠送了,这里要怎么设计才好(工厂模式)?
这些都放在逻辑层好了。
9.如果同一时间并发大量订单的话,如果确保一个订单的有效提交呢?
MSMQ
10.日志方面,log4net?
目前我是自已写代码存在库里的。
11.电子商务的全文检索,这也是个头疼的问题
用lucene.net分词建索引，再直接从索引库里搜索，又快又准。
12.负载均衡方面,有什么好的文章推荐码?
不清楚了。 这样的设计要达到新蛋的效果肯定不可能的，新蛋少说几百台服务器，不同数据库之间的发布订阅链路都有几千条。有复杂的缓存，负载均衡机制。新蛋所有的通讯都是基于WCF的。另外对于这么大型的网站来说，数据库一刻都不停止，所以读写分离也很重要，因为你也不可能让数据库停下来进行备份。总归要做到新蛋这样的大型电子商务网站，靠你上面画的这点好像远远不够。
不过关于公共的header,footer,我不建议做成自定义控件，这个维护起来不方便，稍有变动就要发布dll，麻烦的。
如果你的header和footer不是很大的话，建议采用js+css的方式。然后加上压缩和cdn缓存，应该效率上能接受。
4、从0开始逐步边开发边运作一个大型网站，该采用怎样的技术架构（或者技术路线）？
这样的跨度肯定会经历推倒重来的过程，否则一开始就设计一个能扩展到很大规模的网站架构会在初期造成很大的资金和人力负担。让开发的负责人给你计算了开发成本，维护成本和开发出来的效果以后你再决定当前阶段采用哪一种。显然一分钱一分货。
越简单的时候PHP越有优势，越复杂JAVA越有优势，JSP只是JAVA WEB开发中的一项技术，到最后都不一定需要使用。为了不浪费人手，如果你确定将来要往大网站发展一开始就该采用JAVA或.NET，这样在重新开发时至少能充分利用之前的人员经验。
该采用怎样的技术架构不是三两句话能说清楚的，具体问题具体分析。
再简单也不建议使用JSP+SERVLET+JAVABEAN
SSH之类的架构本来就是为了简化开发工作量，提高代码质量和可维护性而生的。除非追求极致变态的性能的人才会去用servlet，而且实际体验可能根本几乎没差别，只要不把SSH用得太烂。架构复杂了，也不过是在这些主流技术上改改，封装封装，自然是使用同一语言比PHP转JAVA容易太多了。
5、大型网站技术架构 核心原理与案例分析 有用么
编辑推荐
编辑
本书作者是阿里巴巴网站构建的亲历者，拥有核心技术部门的一线工作经验，直接体验了大型网站构建与发展过程中的种种生与死，蜕与变，见证了一个网站架构从幼稚走向成熟稳定的历程。
没有晦涩难懂的术语，没有诘屈聱牙的文句，没有故弄玄虚的观点……
明明白白的语句，清清楚楚的文法，干净利落的建议——让读者直接体会网站架构的紧要处，不容马虎的关键点——这恰好是一个优秀的网站架构所必备的要素。
如果说“水不在深，有龙则灵”，那么对于想了解网站架构的读者而言，这本书恰好是“书不在多，有它则行！”
还犹豫什么呢？
内容简介
编辑
本书通过梳理大型网站技术发展历程，剖析大型网站技术架构模式，深入讲述大型互联网架构设计的核心原理，并通过一组典型网站技术架构设计案例，为读者呈现一幅包括技术选型、架构设计、性能优化、Web 安全、系统发布、运维监控等在内的大型网站开发全景视图。
本书不仅适用于指导网站工程师、架构师进行网站技术架构设计，也可用于指导产品经理、项目经理、测试运维人员等了解网站技术架构的基础概念；还可供包括企业系统开发人员在内的各类软件开发从业人员借鉴，了解大型网站的解决方案和开发理念。
6、如何评价一个大型网站系统架构设计的好坏?
说说我的看法，对不对的供参考吧！
首先，网站也好、其它信息化系统也好，其系统架构设计都不是拍脑袋来的，都是依据一个出发点设计而来，究其所以，就是需求。而这个需求又是从最初的建设初衷来的，也就是说，按说最后做出来的东西应该满足建设初衷。
所以，简言之，有什么样的需求就有什么样的架构设计。因此，要评价架构设计的好坏，就拿需求来衡量。能满足需求的架构设计，就是对的。不能满足，或者不能全面满足的，如果没有项目建设上的延期认可或者同意搁置的决定，就是不应该的。
注意：我说的需求，并不仅是针对功能范畴的；也包括性能、可用性、安全等方面。所以说需求是全面的内容。
7、电子商务系统总体结构设计的主要内容与方法是什么
电子商务系统的总体结构设计是在系统体系结构的基础上，针对企业电子商务的目标，界定系统的外部边界和接口，刻画系统的内部成及其相互关系，明确目标系统的各个组成部分、各个组成部分的作用及其相互关系。
系统总体结构设计包括如下内容：
1．确定系统的外部接口
通过分析，将电子商务系统与其外部环境区分开来，从而使总体设计有一个明确的范围。系统与其外部环境的接口包括以下方面：
（1）与企业合作伙伴之间的接口；
（2）与企业内部既有信息系统的接口；
（3）与交易相关的公共信息基础设施之间的接口；
（4）其他接口，如企业与政府或其他机构之间的接口。
2．确定系统的组成结构
系统组成结构主要说明目标系统内部的组成部分，以及系统内部与外部环境的相互关系。
方法：
随着Internet技术的发展，人们的日常生活已经离不开网络。未来社会人们的生活和工作将越来越依赖于数字技术的发展，越来越数字化、网络化、电子化、虚拟化。电子商务也随着网络的发展日益和人们的生活贴近。本设计尝试用ASP在网络上架构一个动态的电子商务网站，以使每一位顾客不用出门在家里就能够通过上网来轻松购物。在本设计中，我主要完成了后台功能的实现，实现了登录功能，图书管理，图书分类管理，订单管理，用户管理等功能。
本文中所做的主要工作如下：
(1)简单介绍了电子商务，分析了电子商务的现状；
(2)介绍了IIS+ASP系统的一般原理；
(3)阐述整个系统的系统结构及工作原理；分析了系统实现中的特殊性、难点和重点；
(4)分析并解决实现中的若干技术问题；
附：
方案设计主要依靠设计者的经验，作出技术和结构的选择，并以有组织的文档反映，作为与客户交流论证方案，交付系统开发人员实施的依据，方案设计的基础是业务环境说明书。业务环境说明书重新组织系统需求，给出解决方案的业务运作方式。在系统需求相对简单时不一定需要，如果系统需求较为复杂时，以文字和图表的方式系统地说明业务环境可以使系统需求更加清楚，业务环境说明书可以采用三种文档结构。
* 业务流程图：业务流程图描述企业的业务在新系统中如何运作，说明新系统的业务运作模式如何解决客户的要求，指出客户的业务流程因为新系统的应用而作出那些更改。业务流程图是一种直观的工具，向客户解释新系统的作用，征求使用者的配合与支持，能提高新系统的实际效能。
* 操作规程说明：相对于业务流程图这种较高层概括的文档，普通用户可能更需要一份详细的操作规程说明，以便更好地理解系统的功能与使用。操作规程说明以易被最终用户理解的词语描述，避免使用过分专业的词语。操作规程说明仍属于高层设计文档，不是最终的操作步骤说明。操作规程说明规定了系统活动的框架，
* 处理流程图 ： 细化操作规程中描述的活动，由事件和处理流组成。事件是活动开始的条件，处理是活动中的具体工作。处理流程图的描述层次接近详细设计。以客户在网上购货为例，最后一步是确认付款，操作规程说明只需简单地说明：“客户检查付款额后确认”，处理流程图的说明比较详细，激发活动的事件是客户按下“付额”按钮，处理是付款总额从数据库中统计出来，显示在浏览器上，最后由客户按“确认”按钮确认。
当前普遍采用对象技术描述复杂的应用结构，电子商务系统一般用Java,EJB,CORBA等对象技术实现，在系统设计阶段，编制业务环境书时采用面向对象分析和设计方法可以提高实施阶段的效率。业务环境说明书中的设计文档完成后，召开第二次项目会议，在会上以图表的形式向客户和项目开发人员介绍系统设计的概貌。着重与客户讨论两个问题，检查系统设计是否满足客户需求：
系统设计在多大程度上解决了用户的需求？是否准确地实现了客户的期望，既没有过分简单化，也没有过分复杂化。
系统设计的功能范围是否包含了用户提出的所有需求？
应用开发人员参加项目会议，可以更好地了解客户的业务环境与方案设计的总体结构，与客户和系统设计者直接交谈，减少沟通的误差，提高效率。
IBM为电子商务系统定义了一套完整的电子商务应用框架，基于三层次体系结构集成企业核心系统与互联网服务，多层次结构使企业内部应用系统无需作重大更改，通过与互联网服务器的连结就可以在互联网上提供服务，实现电子商务系统的目标。
基于电子商务应用框架的电子商务系统体系结构共有八个主要部分。直接支持应用程序运行的模块有六个：客户端、网络连接、互联网服务器、应用逻辑、中间连接件、核心数据与应用，其余两个模块安全性和系统管理与这六个模块都有关联，系统设计者可相对独立地设计安全性体系和系统管理体系，在应用程序运行支持模块的实现中加入相应的技术与处理。安全性和系统管理的效率是系统的整体性效果，应用系统运行的每一个环节都能影响系统总体的安全性和可管理性。