《大型网站架构设计与分析案例汇总》由会员分享，可在线阅读，更多相关《大型网站架构设计与分析案例汇总（43页珍藏版）》请在金锄头文库上搜索。
1、案例1,平台：NET，+NHibernate+SQL SERVER 2008。 开发模式：MVC模式三层都有A方开发，A方的查询业务基本上依赖于SP，SP由B方方面开发。 表现： B方对需求的理解不完善，导致SP经常改动。但是SP的每次改动了之后，A方开发应用程序的程序人员却不知道，除非A方程序员去调试以前已经开发好的程序，不然很难发现B方修改了存储过程。 存储过程的修改，带来的不仅是页面表现层的数据绑定的问题，在模型层的domain和dto很有可能都要随之改动。即使B方修改了SP第一时间通知A方，A方修改相应的模型层对象，重新构造层与层之间的访问参数以及返回类型也是相当费时的事情。,1问题,
2、问题： 该项目目前的开发方式和现状，效率相当低下。数据库与SP是基础，SP的修改直接影响上层建筑。而SP的控制权在B方，由B方完全控制业务。A方需要做领域业务，但只能按照B方的文档来开发，甚至都不用知道业务。,1分析、建议,分析： 主要是项目管理组织的问题。两个团队无法协调。B方变更带来A方的变更是必然，问题在于A根本不知道B方的变更。加之双方没有持续集成，很可能变更了很久才知道，修改的时候B对A也无法给支持，时间长了可能B自己也忘了。 技术上，业务的变动必然带来领域模型的变动。A方其实只是充当一系列存储过程的外观。这个系统的领域模型其实是用数据库表和存储过程表示的。实际上，谁控制了业务谁就控
3、制了领域模型。 建议： 两个团队组合成一个团队（虚拟的，相当于远程协同开发），要共享需求任务列表。每次变更需要双方在工作前进行协调，确认各自需要调整的地方和需要消耗的时间。,案例2,背景：在ATM和银行主机之间，通常有个前置机器，主要用来做一些预处理工作，传统的金融平台大多采用c来处理，现在想接入网银，想改用j2ee来架构，也为以后的sop（标准操作程序 ）做准备。 问题：在这种实时交易系统里应该用什么的架构。ATM是使用TCP/IP协议的，而网银是http协议的。如果web方面采用jsp+struts做页面层，Spring+hibenate做业务层，而ATM的接入采用application同
4、样接入到到Spring的业务层。由于交易量较大，必须1分钟处理1000笔交易（单ATM），这样的架构是否合适？,2分析,分析：关键看前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性比较高的系统，少用框架。 Spring+hibernate一般实时性都较差。Spring会产生大量垃圾，频繁启动垃圾回收机制，系统的响应就得暂停，Spring的动态代理Proxy对象是每个请求信号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象，还有其他附带对象，内存可能不能支持。 比较好的策略：分析系统在应付如此大访问量下的瓶颈所在。 如果确实需要业务组件，多台机器组成的分布式E
5、JB系统可能更适合这样的系统：ATM机需要很长的Session存活期，Spring对Session的管理是 默认一次调用会开启一个session，调用结束时关闭，如果保持一个Session一直不断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，对内存消耗太大。EJB的Stateful对Session可以在规定内存内进行管理。 如果系统没有数据库，只是一个broker，转接者，使用JMS比多线程强，不宜用多线程。,MySpace,第一代架构：添置更多的Web服务器 MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一
6、个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。,MySpace,第二代架构 ：增加数据库服务器 与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数据一致性的前提下让多个数据库分担压力。,MySpace,MySpace运行在三个SQL Server数据库服务器上：一个为主，所有的新数据都向它提 交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据
7、，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（存储区域网络）用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策
8、略也变得难以维持下去。,MySpace,第三代架构：转到分布式计算架构 几经折腾，最终，MySpace将目光移到分布式计算架构它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割
9、，然后将各组的全部数据分别存入独立的SQL Server实例。结果是，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。,MySpace,第四代架构：求助于微软方案 2005年早期，账户达到九百万，MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET。 账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I
10、/O容量即它从磁盘存储系统读写数据的极限速度。,MySpace,第五代架构 ：增加数据缓存层并转到支持64位处理器的SQL Server 2005 2005年春天，MySpace账户达到一千七百万，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。 2005年中期，服务账户数达到两千六百万时，MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和6
11、4位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。,MySpace,事实上，MySpace的Web服务器和数据库仍然经常发生超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨 MySpace正是在这样不断重构站点软件、数据库和存储系统中，才一步步走到今天。 事实上，MySpace已经成功解决了很多系统扩展性问题，其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。,
12、Amazon,亚马逊书店无疑是电子商务发展的里程碑。2000年到现在，世界网络业腥风血雨。 Amazon曾经成为网络泡沫的头号代表。如今，当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。 历览Amazon发展过程，其成功经验在于，它创造性地进行了电子商务中每一环节的探索，包括系统平台的建设，程序编写、网站设立、配送系统等等方面。用Amazon当家人贝索斯的话说就是，“在现实世界的商店最有力的武器就是地段，地段，地段，而对于我们来说最重要的三件事就是技术，技术，技术。”,大型网站开发时的几点建议,搭建科学的系统架构 构建大型的商业网站不可能像构建普通的小型网站一样一蹴而就，需要从
13、严格的软件工程管理的角度进行认真规划，有步骤有逻辑地进行开发。对于大型网站来说， 所采用的技术涉及面极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙 等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。以著名 的Yahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。,大型网站开发时的几点建议,页面静态化 不要小看纯静态化的HTML页面！其实在很多情况下，HTML往往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网站上的页面采用静态页面来实现。但是，对于大量内容并且频繁更新的网站，我们无法全部手动实现，因此可以开发相应的自动化更新工具，
14、例如我们常见的信息发布系统CMS。像我们经常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。,大型网站开发时的几点建议,存储问题 存储也是一个大问题，一种是小文件的存储，比如图片这类；另一种是大文件的存储，比如搜索引擎的索引。 大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源 的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有
15、独立的图片服务器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更高的系统消耗和执行效率。,大型网站开发时的几点建议,数据库技术集群和库表散列 对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访 问的时候，数据库的瓶颈仍然会显现出来，这时一台数据库将很快无法满足应用，于是我们需要借助于数据库集群或者库表散列技术。 在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQLServer等都有很好的方案，（MySQL提供了类似
16、的Master/Slave）。因此，使用了什么样的数据库，就参考相应的解决方案来实施即可。,大型网站开发时的几点建议,上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。 一个现成的例子是sohou。它的论坛采用了类似的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。,大型网站开发时的几点建议,缓存策略 不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服 务器、数据库服务器的各层级的缓冲策略，最后才是低级的缓冲技术的编程。不同的W
