大型网站架构设计与分析案例汇总PPT(共44页)
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
– 存储过程的修改，带来的不仅是页面表现层的数据绑定的问 题，在模型层的domain和dto很有可能都要随之改动。即使 B方修改了SP第一时间通知A方，A方修改相应的模型层对 象，重新构造层与层之间的访问参数以及返回类型也是相当 费时的事情。
1问题
• 问题： – 该项目目前的开发方式和现状，效率相当低下。数据库与 SP是基础，SP的修改直接影响上层建筑。而SP的控制权在 B方，由B方完全控制业务。A方需要做领域业务，但只能按 照B方的文档来开发，甚至都不用知道业务。
MySpace
• 第一代架构：添置更多的Web服务器
• MySpace最初的系统很小，只有两台Web服务器（分担处理用户 请求的工作量）和一个数据库服务器（所有数据都存储在这一 个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶 段，MySpace基本是通过添置更多Web服务器来对付用户暴增问 题的。但到在2004年早期，在MySpace用户数增长到五十万后， 其数据库服务器已经开始疲于奔命了。
MySpace
• 第二代架构 ：增加数据库服务器 与增加Web服务器不同，增加数据库并没那么简单。如果一个 站点由多个数据库支持，设计者必须考虑的是，如何在保证数 据一致性的前提下让多个数据库分担压力。
MySpace
• MySpace运行在三个SQL Server数据库服务器上：一个为主， 所有的新数据都向它提 交，然后由它复制到其它两个；另两个 数据库服务器全力向用户供给数据，用以在博客和个人资料栏 显示。这种方式在一段时间内效果很好——只要增加数据库服 务器，加大硬盘，就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服 务于站点的不同功能，如登录、用户资料和博客。垂直分割策 略利于多个数据库分担访问压力，当用户要求增加新功能时， MySpace只需要投入新的数据库加以支持。在账户到达二百万 后，MySpace还从存储设备与数据库服务器直接交互的方式切 换到SAN（存储区域网络）—用高带宽、专门设计的网络将大 量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施 极大提升了系统性能、正常运行时间和可靠性。然而，当用户 继续增加到三百万后，垂直分割策略也变得难以维持下去。
• 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须 找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库 服务器是无能为力的。这次，不再按站点功能和应用分割数据库， MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据 分别存入独立的SQL Server实例。结果是，MySpace的每台数据库 服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约 二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以 更小粒度划分架构，从而优化负荷分担。
MySpace
• 第三代架构：转到分布式计算架构 • 几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理
上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来 说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而 必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表， 支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
Biblioteka Baidu
2分析
• 分析：关键看前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性 比较高的系统，少用框架。
• Spring+hibernate一般实时性都较差。Spring会产生大量垃圾，频繁启动垃圾 回收机制，系统的响应就得暂停，Spring的动态代理Proxy对象是每个请求信 号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象， 还有其他附带对象，内存可能不能支持。
案例1
• 平台：NET，spring.net+NHibernate+SQL SERVER 2008。 • 开发模式：MVC模式三层都有A方开发，A方的查询业务基本上
依赖于SP，SP由B方方面开发。 • 表现：
– B方对需求的理解不完善，导致SP经常改动。但是SP的每 次改动了之后，A方开发应用程序的程序人员却不知道，除 非A方程序员去调试以前已经开发好的程序，不然很难发现 B方修改了存储过程。
1分析、建议
• 分析： – 主要是项目管理组织的问题。两个团队无法协调。B方变更 带来A方的变更是必然，问题在于A根本不知道B方的变更。 加之双方没有持续集成，很可能变更了很久才知道，修改的 时候B对A也无法给支持，时间长了可能B自己也忘了。 – 技术上，业务的变动必然带来领域模型的变动。A方其实只 是充当一系列存储过程的外观。这个系统的领域模型其实是 用数据库表和存储过程表示的。实际上，谁控制了业务谁就 控制了领域模型。
• 比较好的策略：分析系统在应付如此大访问量下的瓶颈所在。 • 如果确实需要业务组件，多台机器组成的分布式EJB系统可能更适合这样的
系统：ATM机需要很长的Session存活期，Spring对Session的管理是 默认一 次调用会开启一个session，调用结束时关闭，如果保持一个Session一直不 断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，对内存消 耗太大。EJB的Stateful对Session可以在规定内存内进行管理。 • 如果系统没有数据库，只是一个broker，转接者，使用JMS比多线程强，不 宜用多线程。
• 建议： – 两个团队组合成一个团队（虚拟的，相当于远程协同开发）， 要共享需求任务列表。每次变更需要双方在工作前进行协调， 确认各自需要调整的地方和需要消耗的时间。
案例2
• 背景：在ATM和银行主机之间，通常有个前置机器，主要用来 做一些预处理工作，传统的金融平台大多采用c来处理，现在想 接入网银，想改用j2ee来架构，也为以后的sop（标准操作程 序 ）做准备。
• 问题：在这种实时交易系统里应该用什么的架构。ATM是使用 TCP/IP协议的，而网银是http协议的。如果web方面采用 jsp+struts做页面层，Spring+hibenate做业务层，而ATM的接 入采用application同样接入到到Spring的业务层。由于交易量 较大，必须1分钟处理1000笔交易（单ATM），这样的架构是 否合适？
1问题
• 问题： – 该项目目前的开发方式和现状，效率相当低下。数据库与 SP是基础，SP的修改直接影响上层建筑。而SP的控制权在 B方，由B方完全控制业务。A方需要做领域业务，但只能按 照B方的文档来开发，甚至都不用知道业务。
MySpace
• 第一代架构：添置更多的Web服务器
• MySpace最初的系统很小，只有两台Web服务器（分担处理用户 请求的工作量）和一个数据库服务器（所有数据都存储在这一 个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶 段，MySpace基本是通过添置更多Web服务器来对付用户暴增问 题的。但到在2004年早期，在MySpace用户数增长到五十万后， 其数据库服务器已经开始疲于奔命了。
MySpace
• 第二代架构 ：增加数据库服务器 与增加Web服务器不同，增加数据库并没那么简单。如果一个 站点由多个数据库支持，设计者必须考虑的是，如何在保证数 据一致性的前提下让多个数据库分担压力。
MySpace
• MySpace运行在三个SQL Server数据库服务器上：一个为主， 所有的新数据都向它提 交，然后由它复制到其它两个；另两个 数据库服务器全力向用户供给数据，用以在博客和个人资料栏 显示。这种方式在一段时间内效果很好——只要增加数据库服 务器，加大硬盘，就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服 务于站点的不同功能，如登录、用户资料和博客。垂直分割策 略利于多个数据库分担访问压力，当用户要求增加新功能时， MySpace只需要投入新的数据库加以支持。在账户到达二百万 后，MySpace还从存储设备与数据库服务器直接交互的方式切 换到SAN（存储区域网络）—用高带宽、专门设计的网络将大 量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施 极大提升了系统性能、正常运行时间和可靠性。然而，当用户 继续增加到三百万后，垂直分割策略也变得难以维持下去。
• 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须 找到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库 服务器是无能为力的。这次，不再按站点功能和应用分割数据库， MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据 分别存入独立的SQL Server实例。结果是，MySpace的每台数据库 服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约 二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以 更小粒度划分架构，从而优化负荷分担。
MySpace
• 第三代架构：转到分布式计算架构 • 几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理
上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来 说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而 必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表， 支持博客、个人资料和其他核心功能的数据都存储在相同数据库。
Biblioteka Baidu
2分析
• 分析：关键看前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性 比较高的系统，少用框架。
• Spring+hibernate一般实时性都较差。Spring会产生大量垃圾，频繁启动垃圾 回收机制，系统的响应就得暂停，Spring的动态代理Proxy对象是每个请求信 号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象， 还有其他附带对象，内存可能不能支持。
案例1
• 平台：NET，spring.net+NHibernate+SQL SERVER 2008。 • 开发模式：MVC模式三层都有A方开发，A方的查询业务基本上
依赖于SP，SP由B方方面开发。 • 表现：
– B方对需求的理解不完善，导致SP经常改动。但是SP的每 次改动了之后，A方开发应用程序的程序人员却不知道，除 非A方程序员去调试以前已经开发好的程序，不然很难发现 B方修改了存储过程。
1分析、建议
• 分析： – 主要是项目管理组织的问题。两个团队无法协调。B方变更 带来A方的变更是必然，问题在于A根本不知道B方的变更。 加之双方没有持续集成，很可能变更了很久才知道，修改的 时候B对A也无法给支持，时间长了可能B自己也忘了。 – 技术上，业务的变动必然带来领域模型的变动。A方其实只 是充当一系列存储过程的外观。这个系统的领域模型其实是 用数据库表和存储过程表示的。实际上，谁控制了业务谁就 控制了领域模型。
• 比较好的策略：分析系统在应付如此大访问量下的瓶颈所在。 • 如果确实需要业务组件，多台机器组成的分布式EJB系统可能更适合这样的
系统：ATM机需要很长的Session存活期，Spring对Session的管理是 默认一 次调用会开启一个session，调用结束时关闭，如果保持一个Session一直不 断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，对内存消 耗太大。EJB的Stateful对Session可以在规定内存内进行管理。 • 如果系统没有数据库，只是一个broker，转接者，使用JMS比多线程强，不 宜用多线程。
• 建议： – 两个团队组合成一个团队（虚拟的，相当于远程协同开发）， 要共享需求任务列表。每次变更需要双方在工作前进行协调， 确认各自需要调整的地方和需要消耗的时间。
案例2
• 背景：在ATM和银行主机之间，通常有个前置机器，主要用来 做一些预处理工作，传统的金融平台大多采用c来处理，现在想 接入网银，想改用j2ee来架构，也为以后的sop（标准操作程 序 ）做准备。
• 问题：在这种实时交易系统里应该用什么的架构。ATM是使用 TCP/IP协议的，而网银是http协议的。如果web方面采用 jsp+struts做页面层，Spring+hibenate做业务层，而ATM的接 入采用application同样接入到到Spring的业务层。由于交易量 较大，必须1分钟处理1000笔交易（单ATM），这样的架构是 否合适？