❖ 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找 到新的办法以分担负荷——显然，运行在普通硬件上的单个数据库服务 器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace 开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独 立的SQL Server实例。结果是，MySpace的每台数据库服务器实际运行 两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据 MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构， 从而优化负荷分担。
MySpace
❖ 第五代架构 ：增加数据缓存层并转到支持64 位处理器的SQL Server 2005
❖ 2005年春天，MySpace账户达到一千七百万， MySpace又启用了新的策略以减轻存储系统 压力，即增加数据缓存层——位于Web服务 器和数据库服务器之间，其唯一职能是在内 存中建立被频繁请求数据对象的副本，如此 一来，不访问数据库也可以向Web应用供给 数据。
系统：ATM机需要很长的Session存活期，Spring对Session的管理是 默认一 次调用会开启一个session，调用结束时关闭，如果保持一个Session一直不 断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，对内存消 耗太大。EJB的Stateful对Session可以在规定内存内进行管理。 ❖ 如果系统没有数据库，只是一个broker，转接者，使用JMS比多线程强，不 宜用多线程。
❖ Spring+hibernate一般实时性都较差。Spring会产生大量垃圾，频繁启动垃圾 回收机制，系统的响应就得暂停，Spring的动态代理Proxy对象是每个请求信 号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象， 还有其他附带对象，内存可能不能支持。
❖ 比较好的策略：分析系统在应付如此大访问量下的瓶颈所在。 ❖ 如果确实需要业务组件，多台机器组成的分布式EJB系统可能更适合这样的
1问题
❖ 问题：
该项目目前的开发方式和现状，效率相当低下。 数据库与SP是基础，SP的修改直接影响上层建 筑。而SP的控制权在B方，由B方完全控制业务。 A方需要做领域业务，但只能按照B方的文档来开 发，甚至都不用知道业务。
1分析、建议
❖ 分析：
主要是项目管理组织的问题。两个团队无法协调。 B方变更带来A方的变更是必然，问题在于A根本 不知道B方的变更。加之双方没有持续集成，很 可能变更了很久才知道，修改的时候B对A也无法 给支持，时间长了可能B自己也忘了。
MySpace
❖ 事实上，MySpace的Web服务器和数据库仍 然经常发生超负荷，其用户频繁遭遇“意外 错误”和“站点离线维护”等告示，他们不 得不在论坛抱怨…
❖ MySpace正是在这样不断重构站点软件、数 据库和存储系统中，才一步步走到今天。
❖ 事实上，MySpace已经成功解决了很多系统 扩展性问题，其中存在相当的经验值得我们 借鉴。MySpace系统架构到目前为止保持了
技术上，业务的变动必然带来领域模型的变动。 A方其实只是充当一系列存储过程的外观。这个 系统的领域模型其实是用数据库表和存储过程表 示的。实际上，谁控制了业务谁就控制了领域模 型。
案例2
❖ 背景：在ATM和银行主机之间，通常有个前 置机器，主要用来做一些预处理工作，传统 的金融平台大多采用c来处理，现在想接入网 银，想改用j2ee来架构，也为以后的sop（标 准操作程序 ）做准备。
MySpace
❖ 第四代架构：求助于微软方案 2005年早期，账户达到九百万，MySpace开始 用微软的C#编写程序。在收到一定成 效后，MySpace开始大规模迁移到。
❖ 账户达到一千万时，MySpace再次遭遇存储瓶 颈问题。SAN的引入解决了早期一些性能问题， 但站点目前的要求已经开始周期性超越SAN的 I/O容量——即它从磁盘存储系统读写数据的 极限速度。
MySpace
❖ 第一代架构：添置更多的Web服务器
❖ MySpace最初的系统很小，只有两台Web服务 器（分担处理用户请求的工作量）和一个数 据库服务器（所有数据都存储在这一个地 方）。那时使用的是Dell双CPU、4G内存的系 统。在早期阶段，MySpace基本是通过添置更 多Web服务器来对付用户暴增问题的。但到在 2004年早期，在MySpace用户数增长到五十万
❖ 问题：在这种实时交易系统里应该用什么的 架构。ATM是使用TCP/IP协议的，而网银是 http协议的。如果web方面采用jsp+struts做 页面层，Spring+hibenate做业务层，而ATM
2分析
❖ 分析：关键看前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性 比较高的系统，少用框架。
MySpaபைடு நூலகம்e
❖ 第二代架构 ：增加数据库服务器 与增加Web服务器不同，增加数据库并没那 么简单。如果一个站点由多个数据库支持， 设计者必须考虑的是，如何在保证数据一致 性的前提下让多个数据库分担压力。
MySpace
❖ MySpace运行在三个SQL Server数据库服务 器上：一个为主，所有的新数据都向它提 交， 然后由它复制到其它两个；另两个数据库服 务器全力向用户供给数据，用以在博客和个 人资料栏显示。这种方式在一段时间内效果 很好——只要增加数据库服务器，加大硬盘， 就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计， 不同的数据库服务于站点的不同功能，如登 录、用户资料和博客。垂直分割策略利于多 个数据库分担访问压力，当用户要求增加新
MySpace
❖ 第三代架构：转到分布式计算架构
❖ 几经折腾，最终，MySpace将目光移到分布式计算架构——它在物理上 分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说， 就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将 整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博 客、个人资料和其他核心功能的数据都存储在相同数据库。