大型网站架构设计与分析案例汇总.pptx
案例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问题问题： 该项目目前的开发方式和现状，效率相当低下。数据库与SP是基础，SP的修改直接影响上层建筑。而SP的控制权在B方，由B方完全控制业务。A方需要做领域业务，但只能按照B方的文档来开发，甚至都不用知道业务。1分析、建议分析： 主要是项目管理组织的问题。两个团队无法协调。B方变更带来A方的变更是必然，问题在于A根本不知道B方的变更。加之双方没有持续集成，很可能变更了很久才知道，修改的时候B对A也无法给支持，时间长了可能B自己也忘了。 技术上，业务的变动必然带来领域模型的变动。A方其实只是充当一系列存储过程的外观。这个系统的领域模型其实是用数据库表和存储过程表示的。实际上，谁控制了业务谁就控制了领域模型。 建议： 两个团队组合成一个团队（虚拟的，相当于远程协同开发），要共享需求任务列表。每次变更需要双方在工作前进行协调，确认各自需要调整的地方和需要消耗的时间。 案例2背景：在ATM和银行主机之间，通常有个前置机器，主要用来做一些预处理工作，传统的金融平台大多采用c来处理，现在想接入网银，想改用j2ee来架构，也为以后的sop（标准操作程序 ）做准备。问题：在这种实时交易系统里应该用什么的架构。ATM是使用TCP/IP协议的，而网银是http协议的。如果web方面采用jsp+struts做页面层，Spring+hibenate做业务层，而ATM的接入采用application同样接入到到Spring的业务层。由于交易量较大，必须1分钟处理1000笔交易（单ATM），这样的架构是否合适？2分析分析：关键看前置要做哪些工作，是否有复杂的业务逻辑，对于这样实时性对于这样实时性比较高的系统，少用框架比较高的系统，少用框架。Spring+hibernate一般实时性都较差。Spring会产生大量垃圾，频繁启动垃圾回收机制，系统的响应就得暂停，Spring的动态代理Proxy对象是每个请求信号都会产生的，1分钟处理1000笔交易，那么一分钟内至少1000个Proxy对象，还有其他附带对象，内存可能不能支持。比较好的策略：分析系统在应付如此大访问量下的瓶颈所在。如果确实需要业务组件，多台机器组成的分布式EJB系统可能更适合这样的系统：ATM机需要很长的Session存活期，Spring对Session的管理是 默认一次调用会开启一个session，调用结束时关闭，如果保持一个Session一直不断Open，又占用内存，一分钟内如果非常多的ATM客户端接过来，对内存消耗太大。EJB的Stateful对Session可以在规定内存内进行管理。如果系统没有数据库，只是一个broker，转接者，使用JMS比多线程强，不宜用多线程。 MySpace 第一代架构：添置更多的Web服务器 MySpace最初的系统很小，只有两台Web服务器（分担处理用户请求的工作量）和一个数据库服务器（所有数据都存储在这一个地方）。那时使用的是Dell双CPU、4G内存的系统。在早期阶段，MySpace基本是通过添置更多Web服务器来对付用户暴增问题的。但到在2004年早期，在MySpace用户数增长到五十万后，其数据库服务器已经开始疲于奔命了。 MySpace第二代架构 ：增加数据库服务器 与增加Web服务器不同，增加数据库并没那么简单。如果一个站点由多个数据库支持，设计者必须考虑的是，如何在保证数保证数据一致性据一致性的前提下让多个数据库分担压力。MySpaceMySpace运行在三个SQL Server数据库服务器上：一个为主，所有的新数据都向它提 交，然后由它复制到其它两个；另两个数据库服务器全力向用户供给数据，用以在博客和个人资料栏显示。这种方式在一段时间内效果很好只要增加数据库服务器，加大硬盘，就可以应对用户数和访问量的增加。 这一次的数据库架构按照垂直分割模式设计，不同的数据库服务于站点的不同功能，如登录、用户资料和博客。垂直分割策略利于多个数据库分担访问压力，当用户要求增加新功能时，MySpace只需要投入新的数据库加以支持。在账户到达二百万后，MySpace还从存储设备与数据库服务器直接交互的方式切换到SAN（存储区域网络）（存储区域网络）用高带宽、专门设计的网络将大量磁盘存储设备连接在一起，而数据库连接到SAN。这项措施极大提升了系统性能、正常运行时间和可靠性。然而，当用户继续增加到三百万后，垂直分割策略也变得难以维持下去。 MySpace第三代架构：转到分布式计算架构 几经折腾，最终，MySpace将目光移到分布式计算架构它在物理上分布的众多服务器，整体必须逻辑上等同于单台机器。拿数据库来说，就不能再像过去那样将应用拆分，再以不同数据库分别支持，而必须将整个站点看作一个应用。现在，数据库模型里只有一个用户表，支持博客、个人资料和其他核心功能的数据都存储在相同数据库。 既然所有的核心数据逻辑上都组织到一个数据库，那么MySpace必须找到新的办法以分担负荷显然，运行在普通硬件上的单个数据库服务器是无能为力的。这次，不再按站点功能和应用分割数据库，MySpace开始将它的用户按每百万一组分割，然后将各组的全部数据分别存入独立的SQL Server实例。结果是，MySpace的每台数据库服务器实际运行两个SQL Server实例，也就是说每台服务器服务大约二百万用户。据MySpace的技术人员说，以后还可以按照这种模式以更小粒度划分架构，从而优化负荷分担。 MySpace 第四代架构：求助于微软方案 2005年早期，账户达到九百万，MySpace开始用微软的C#编写ASP.NET程序。在收到一定成效后，MySpace开始大规模迁移到ASP.NET。 账户达到一千万时，MySpace再次遭遇存储瓶颈问题。SAN的引入解决了早期一些性能问题，但站点目前的要求已经开始周期性超越SAN的I/O容量即它从磁盘存储系统读写数据的极限速度。MySpace第五代架构 ：增加数据缓存层并转到支持64位处理器的SQL Server 20052005年春天，MySpace账户达到一千七百万，MySpace又启用了新的策略以减轻存储系统压力，即增加数据缓存层位于Web服务器和数据库服务器之间，其唯一职能是在内存中建立被频繁请求数据对象的副本，如此一来，不访问数据库也可以向Web应用供给数据。 2005年中期，服务账户数达到两千六百万时，MySpace因为我们对内存的渴求而切换到了还处于beta测试的支持64位处理器的SQL Server 2005。升级到SQL Server 2005和64位Windows Server 2003后，MySpace每台服务器配备了32G内存，后于2006年再次将配置标准提升到64G。MySpace事实上，MySpace的Web服务器和数据库仍然经常发生超负荷，其用户频繁遭遇“意外错误”和“站点离线维护”等告示，他们不得不在论坛抱怨MySpace正是在这样不断重构站点软件、数据库和存储系统中，才一步步走到今天。 事实上，MySpace已经成功解决了很多系统扩展性问题，其中存在相当的经验值得我们借鉴。MySpace系统架构到目前为止保持了相对稳定，但其技术人员仍然在为SQL Server支持的同时连接数等方面继续攻坚，尽可能把事情做到最好。Amazon亚马逊书店无疑是电子商务发展的里程碑。2000年到现在，世界网络业腥风血雨。 Amazon曾经成为网络泡沫的头号代表。如今，当这个“最大的泡沫”用几经易改的数字把自己变成了坚实的IT巨人。 历览Amazon发展过程，其成功经验在于，它创造性地进行了电子商务中每一环节的探索，包括系统平台的建设，程序编写、网站设立、配送系统等等方面。用Amazon当家人贝索斯的话说就是，“在现实世界的商店最有力的武器就是地段，地段，地段，而对于我们来说最重要的三件事就是技术，技术，技术。” 大型网站开发时的几点建议 搭建科学的系统架构 构建大型的商业网站不可能像构建普通的小型网站一样一蹴而就，需要从严格的软件工程管理的角度进行认真规划，有步骤有逻辑地进行开发。对于大型网站来说， 所采用的技术涉及面极其广泛，从硬件到软件、编程语言、数据库、Web服务器、防火墙 等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。以著名 的Yahoo!为例，他们的每一个大型网站工程都需要大量相应专业人员的参与。大型网站开发时的几点建议 页面静态化 不要小看纯静态化的HTML页面！其实在很多情况下，HTML往往意味着“效率最高、消耗最小”，所以我们尽可能使我们的网站上的页面采用静态页面来实现。但是，对于大量内容并且频繁更新的网站，我们无法全部手动实现，因此可以开发相应的自动化更新工具，例如我们常见的信息发布系统CMS。像我们经常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的。信息发布系统可以实现最简单的信息录入自动生成静态页面自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。大型网站开发时的几点建议 存储问题 存储也是一个大问题，一种是小文件的存储，比如图片这类；另一种是大文件的存储，比如搜索引擎的索引。 大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片图片是最消耗资源是最消耗资源 的的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务图片服务器器，甚至很多台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃，在应用服务器和图片服务器上，可以进行不同的配置优化以保证更高的系统消耗和执行效率。大型网站开发时的几点建议 数据库技术集群和库表散列 对于大型网站而言，使用大型的数据库服务器是必须的事情。但是，在面对大量访 问的时候，数据库的瓶颈仍然会显现出来，这时一台数据库将很快无法满足应用，于是我们需要借助于数据库集群或者库表散列技术。在数据库集群方面，很多数据库厂商都有自己的解决方案，Oracle、Sybase、SQLServer等都有很好的方案，（MySQL提供了类似的Master/Slave）。因此，使用了什么样的数据库，就参考相应的解决方案来实施即可。 大型网站开发时的几点建议 上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用数据库类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，其中，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能并且有很好的扩展性。一个现成的例子是sohou。它的论坛采用了类似的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系统随时增加一台低成本的数据库进来补充系统性能。大型网站开发时的几点建议 缓存策略 不单指低级的缓存技术相关的编程，应从整个架构角度着眼，深入研究Web服 务器、数据库服务器的各层级的缓冲策略，最后才是低级的缓冲技术的编程。不同的Web服务器、数据库服务器及Web编程语言都有自己不同的缓冲策略。例如数据库存储方面，SQL Serve 2005中的主动式缓存机制，Oracle数据的cache group技术，Hibernate的缓存包括Session的缓存和SessionFactory的缓存；Web服务器方面，Apache提供了自己的缓存模块，也可以使用外加的Squid模块进行缓存，这两种方式均可以有效的提高Apache的访问响应能力，IIS缓冲器技术；至于web开发语言，所用缓存技术更存在很大不同，例如ASP.NET 2.0中提出了两种缓存应用程序数据和缓存服务页输出的策略，这两种缓存技术相互独立但不相互排斥，PHP有Pear的Cache模块，等等。大型网站开发时的几点建议 镜像 镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异。大型网站开发时的几点建议 负载均衡负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。负载均衡技术发展了多年，有很多专业的服务提供商和产品可以选择：硬件四层交换：第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器使用了三四台Alteon就搞定了。网站问题当投资和流量都不是问题的时候，技术上需要关注什么。例如：SNS网站，当一笔笔投资砸进去的时候，当流量上去的时候，困惑在什么地方？除了页面静态化，缓存和代码安全等问题，讨论一下发展之后的问题。A公司A公司做的是SNS网站，程序是两个毛头小伙子做的，目标直指51，程序开发是一帆风顺，功能也比51牛多了，推广也是一帆风顺（A公司有自己独到的推广方式。但是当ALEXA到2W的时候问题出来了，每天下午4点左右，网站速度慢的惊人，基本上打不开，公司三台服务器CPU100%，让人郁闷的是公司的网络配置方式，居然是双WEB的集群，而单独一台DB数据库。整个瓶颈在数据库，于是咨询公司建议做DB的集群，分析了一下数据结构：是典型的WEB程序员的作品，没有一点数据库设计规范，功能实现是可以，如果要扩展，不可能，集群基本上是不可能的，怎么办？解决方案：一个月的时间修改程序，数据结构基本上换了一遍 前期砸进去的几十万打了水飘，用户走光了。结论：WEB2.0前期设计的时候不应该只考虑功能，应该认真考虑一下底层和数据结构。B公司B公司也是做的SNS网站，程序是3个人开发的，CEO是某名牌大学的经济学硕士，有点知己网的味道，又有一些特色出来，说实话，公司的潜力不错，CEO 有很强的运作能力，感觉前景不错。系统架构还行，但是-但是系统崩溃了，为什么？系统没有考虑到用户有个海量的说法，文件也有个海量的说法，用户的相册，图片全部存贮在WEB服务器的一个分区上，每个用户一个目录，而打开性能监视器，磁盘的IO高的惊人，基本上无暇响应。众所周知，文件系统也是一个数据库，单独大文件无所谓，关键是整个是300多个G的零碎文件，大量的读写操作，系统崩溃，数据丢失，文件系统的一个链断了，用户数据全部丢失！这是一个非常沉重的问题，系统整整停了一个月来做数据恢复（单独文件很容易，但是海量文件目前还没有一个软件能组织起来软件架构）。解决方案：修改程序架构，做分布式文件存贮（程序修改用了8天，但是文件转移却又用去了将近一个月），20万用户损失殆尽。结论：WEB2.0前期的设计应该有应付海量存贮的考虑，整个涉及了程序架构的修改，前期规划不好的话基本上死路一条。C公司C公司是一个值得尊敬的公司，CEO技术出身，和比尔盖茨一样，大学未毕业出来做网络，01到03年做短信狠赚了一笔，后来做的小项目也小有所成。公司做的是校友方面，但是更偏重myspace风格，注重个人主页，推广方面也下了大手笔。系统崩溃的原因其实很简单，由于采用的是微软的 SqlServer，而微软直接就告诉了我们，SQLSERVER不支持集群（2000），他们的数据库超负载，100%就没有下去过，只能横向增加配置，采用了4路 4核CPU系统，但是系统还是崩溃了. 高互动注定了高负载。解决方案：现从基本入手，解决掉几个程序耗能大户，对数据库采用横向切割，将用户每10万进行分组，同时对数据库系统进行散列，将多个表垂直分割，同时进行文件分组，解决问题. 因为修改了数据结构，程序也基本上大动了一下。 好在系统没有出大错，损失不算很大，不过对用户体验造成了很坏的影响。结论：WEB2.0前期设计应该有良好的散列考虑，程序应该能有配合的扩充性，符合数据库的扩充。D公司D公司是一个各个方面做的比较好的公司，做了CDN加速；图片也独立分出了N个服务器；数据库不错(CTO是数据库专家），系统崩溃的原因在于 WEB，按道理说WEB很容易做集群的，但是发现集群并解决不掉问题，他们的集群只允许做4台的WEB集群，但是4台都当掉了。仔细分析，原因估计也是大部分CTO容易犯的一个错误，或者说他们没有想到的问题，就是WEB上传的问题，上传的时候由于时间的原因，线程是保持链接的，300 个线程就可以把一个WEB Server当掉了。解决方案：这个最简单，把上传和其他耗能大户分离出独立出来。程序改动不是很大，但是之前半个月速度满对用户体验的损失也不可小视。(有海量访问经验的CTO不多)。网站问题总结：模仿是容易的，随便找几个WEB程序员就能做到，并且很简单，速度可能还很高效，因为WEB2.0无非就是跟数据库打交道，会操作数据库就会做。但是真正做大并不容易，因为能应付海量访问的程序并不简单。几个建议一.找DBMS的专家设计好数据库，很多程序员只知道Sql，不知道分区视图，数据散列的概念。二.设计好程序架构，找个高人指导一下，保持良好的扩展性，考虑节约成本的话可以找兼职的系统架构设计师做好系统架构，确定将来的发展瓶颈。三.考虑好文件存贮的问题。文件存贮的技术含量看起来很低，其实是很高的，可以考虑反向代理的方案。文件存贮出问题了，站点基本上就垮了，RAID的问题和存贮服务器的问题。几个建议四.中国国情考虑，这个最致命，需要考虑电信和网通的问题，CDN并不能解决所有问题。互动性的东西CDN并不是很有效。最关键的是，现有的双线机房遇到DDOS攻击基本上都会当掉，原因很简单，双线机房都是私人机房，本身就不会有太高的带宽，随便攻击一下就可以D掉。五.网络延迟的问题，分布式系统必须要考虑网络延迟问题，程序要能容忍0到100秒的数据延迟的功能，也就是同步的问题。不要小看这几十秒，问题很大的，如果站点有交互式功能，比如IM，可以想象一下是个什么结果。此外，如果系统为了健壮做了缓存和静态化的时候，网络延迟是灾难性危害。对于IM，可以用反向代理来解决（成本较高）。对于留言和评论，延迟的问题影响不大。几个建议六.分散你的程序，如果你没有太多的资金构筑动辄百万的服务器，建议把功能分散开来，比如相册一台服务器，留言一台服务器七.看好你的程序员，如果没有很好的激励措施的话你的程序员很容易写出敷衍性的代码，而这个可能就是将来的大患，程序架构定下来后要修改可能就要费牛劲了。最好你的CTO能对你100%的忠心，100%的负责。八.文件同步的问题，这个问题可能觉得没有必要，但看一下网通和电信的TTL就明白了，同步要支持续传，并且不能是持续的，否则成本会高出N倍，不要期望能通过你的软件实现，交给你的程序员吧，把上面的话告诉他他就知道怎么做了。九. 吃亏最大的问题，不管您跟网警的关系多好，看好你的用户，审核好你的东西，一被停机可能就致命。绿坝在Vista下经常被用户账户控制杀掉。网站过滤功能，只能在IE下生效，同属IE内核的遨游等不起作用。火狐，谷歌这类非IE内核浏览器不起作用。四个进程除了以两个为一组，有交互保护（当其中一个被结束，另一个将会重新运行它）之外，其他无任何防护。管理密码，通过类似于MD5的加密之后，储存在 WINDOWSsystem32kwpwf.dll文件中，该文件并没有受到任何程序的保护，可用记事本就改其中内容。例如，把知道密码的绿坝的WINDOWSsystem32kwpwf.dll文件中的内容复制到不知道密码的那个绿坝的 WINDOWSsystem32kwpwf.dll下，就相当于改变其密码了。可把WINDOWSsystem32kwpwf.dll的内容改为“D0970714757783E6CF17B26FB8E2298F”，则绿坝的管理密码就变回了默认的112233。成本高。电影资讯/社区网站X网站是大型的电影资讯,电影社区,向外提供电影相关信息服务,以及用户社区,其中信息服务部分, 其中大部分页面属于信息呈现页,读取量比较大,百万级别pv,信息主要由编辑在后台发布,更新较少,但其页面上有大量的交互性的内容,比如评论,收藏列表,同时许多内容允许用户创造,比如上传图片,添加注释.交互内容的数量和交互的频繁程度,都超过了普通的咨询页面,这次调整,准备将其中访问量最大的几块:电影资料页,影人资料页,进行静态化,如果成功,还将运用到更多的频道,基本实现全站静态化。优化调整时的问题页面生成的触发条件复杂 一般论坛中的帖子或者blog,更新方式比较单一:主要是由回复进行触发还有少数的修改动作,然而该网站一个页面上需要根据不同触发条件就有20多个, 比如光二级菜单:用户发布图片,删除图片,发布或者删除影片信息,发布或者修改视频,后台修改电影信息,都有可能触发 一个动作触发生成的页面可能很多而且相互交叠 每一个动作都会触发一系列的生成,并且不同动作可能都会涉及同一个页面或者区域的生成. 比如:用户给一步电影评分,需要生成评分更多页,评分统计更多页,首页右侧谁还关注此影片小区域,等等.用户收藏一个影片,也需要更新首页右侧谁还关注此影片小区域触发频繁: 虽然不及某些更大规模的网站,但是由于涉及众多用户参与的内容,评论,收藏等等,触发点多,发生频度相当频繁优化调整时的问题页面多,结构复杂,空间占用大: 通常,需要生成的页面规模是这样粗略估算的,Rn*P,Rn为资源数,P为每个资源的页面数,所谓资源,可以看做一个生成单位,其页面数可以简单看做发布一个资源,就需要生成其所有相关页面数量,比如:发布一个blog,就需要生成一个Blog页,同时还需要生成或者更新个人主页的blog列表,算上个人主页右侧的分类文章数的小块,也就是最多10来个页面或者区域,但是发布一个电影,其相关的页面至少有50个以上,而且有的页面还带有分页,一个信息比较丰富的电影,其页面竟可以达到千个以上,空间1020M,而且资源总数也不少,电影80000左右,电影人虽然P值较少,但是总量确有几十万之巨,估计静态页面磁盘占用量几百个G向下兼容 这是一个已有系统,旧系统的框框需要突破,但又没有时间,或者不能完全突破,比如Url,已经被收录到搜索引擎,就不能随便调整,还有一些地方,原本没有为静态生成考虑,另一些地方又需要兼容旧的设计。优化调整时的问题多台前端Web 这种结构要求生成的文件可能需要分布到多个服务器(另一个方案是放在几台专用的机器上,等前端来取)任务紧迫 架构讨论结束后, 所有底层框架实现,页面模板开发,调试测试,动作的整理,必须接着完成。架构必须要有的特点综合考虑上述因素,架构必须要有以下几个方面的特点 动作可以灵活扩展配置,某个动作对应哪些生成,应该可以配置,并且可以分组 文件必须有分发机制 分发和生成必须独立出来,并且支持分布式 各种的动作,必须转化为消息,发送到生成和分发服务器进行处理 针对同一资源频繁动作,在变量相同的情况下能够具有合并的能力 动作必须有记录 尽量考虑使用已有成熟技术,节省开发时间第一个架构 第二个架构第三个架构管理软件第一点：一个管理软件，是为某软件公司开发的软件。第二点：这是一个需要插件体系的B/S软件，需要通过一些简单配置去实现新功能（包括工作流，但不仅是工作流）第三点：为了追求易用性，因此需要在B/S中实现单机程序的风格页面，因此可能会包含大量组件，大量复杂页面展示逻辑。第四点：需要分布式部署第五点：在特殊需求下，需要在网页内调用一个富客户端完成工作，而客户可以接受的唯一安装的东西是JVM，因此这个软件不需要其他的客户端第六点：客户的办公室分布在多个城市，需要高速响应用户的需求，抛开网络问题，需要在客户每个城市放上一台或多台服务器。第七点：在线人数会非常大，因此需要可以横向扩服务器。同时需要较快的访问速度。第八点：系统大部分地方对数据的查询与写入是二比一的比例，或者说：有很频繁的更新操作第九点：系统对事务要求较高，因为有财务，还有成本估算等模块，因此不允许垃圾数据的存在，并且事务要求是全局的。典型的模块下面分别描述几个典型的模块：1.消息系统。需要一个完善的消息系统，支持从Email到RSS，站内消息的模块，同时也需要支持手机短信，以及未来可能需要的一些通知方式。2.工作流系统需要自定义的工作流，并且工作流需要实现的流程是跨地区的，比如有的流程在一个城市，另一个流程在另一个城市，流程之间可以轮转。3.在线的绘图、会议这种地方需要实现在页面内绘图，如果需要，允许使用客户端（但不需要安装，现在考虑的是JavaWebStart）4.IM，（要求也是在线的）可以集成MSN和YAHOO，同时自己还需要维护内部的账户（就是自己开发IM，用户如果需要，可以同时聊MSN，就像Gaim那样）典型的模块5.WebService支持需要公开一部分WebService供客户的客户去调用，这里有大量只读的，部分需要进行数据信息交流的6.SSO把过去的一些系统也集成起来，一起登录（现在还不清楚是谁集成谁）7.分布式部署（这是我们经验最不足的地方）为了访问速度可以快一些，虽然有核心的服务器，但希望客户的不同办公区域都各放上一台服务器对某个地区提供服务。而客户的不同办公区域在不同的城市。而各地方的业务逻辑基本上是相同的。在这方面，还有一些细节需求：中心服务器是PostgreSQL或者Oracle，而为了速度，也许可以在客户端的服务器上跑一个简单的MySQL对某些数据进行缓存。典型的模块8.关于业务复杂度的确是相当复杂，涉及财务、时间管理、项目管理、成本、风险等各种东西，因此业务相当复杂。项目会跑在Solaris上，不排斥Java EE 5的技术，可以使用新的应用中间件。 上面是一些典型的模型，对于这种项目，有什么好的技术建议？
