最近一个同事要离职，而我刚到新公司没多久，需要从他手里接过原来的系统，经过这些天的交接，确实是难。找到三篇文章，应该帮助很大，
第一篇属于方法论(张逸老师)，为我们处理遗留系统制定大目标和策略：
http://www.cnblogs.com/wayfarer/archive/2011/10/09/2203651.html
第二篇属于工具类，介绍了处理java遗留系统有哪些工具：
http://tieba.baidu.com/p/1331700739
第三篇是从工程角度来分析该如何处理遗留系统：
http://www.infoq.com/cn/articles/Dealing-with-legacy-code
第四篇文章则是张逸老师碰到的一个案例：
http://www.cnblogs.com/wayfarer/archive/2011/02/18/1957530.html
下面的文章是摘自第一篇文章，加粗部分是我认为的重点:
处理遗留系统，几乎是每个程序员都不可能绕过的一件麻烦事儿。因为时间压力，技能不足以及功能复杂等诸多原因，常常使得遗留系统的代码变得糟糕混乱，可读性与维护性差，无法保证功能的可测试性，纠缠不清的代码让类、方法之间紧紧耦合在一起。如果遗留系统能够正常工作，那么我们还可以置之不理，即使代码接近腐烂的边缘，我们还可以得过且过。倘若我们需要维护遗留系统，或者需要为它添加新的功能，又或者需要将新的系统与遗留系统进行集成，就必须正视遗留系统带来的问题了。
处理遗留系统，首先需要分析和了解遗留系统，尤其这个遗留系统并非你开发时，更需如此。我们可以考虑双管齐下的办法。一是从业务逻辑方面去了解。相比新系统而言，遗留系统的唯一好处就是它往往是可以运行可以使用的。因此，最好的办法是直接运行遗留系统，通过实际操作了解系统的各个功能点、业务流程。这样的直观感受可以最快地帮助你了解该系统：它能够做什么？它能达成什么目标？它的范围是什么？它存在什么问题？其二则需要从系统架构出发，了解遗留系统的逻辑结构和物理分布。可以阅读架构文档和源代码，如果能够咨询遗留系统的设计者或开发人员，就更好。尽快地描绘出遗留系统的轮廓图，可以帮助你从技术的宏观角度剖析遗留系统的结构与组成。再结合你对该系统业务的理解，快速地掌握遗留系统。如果需要阅读源代码，最好能够从主程序入口开始，找到一些主要的模块，了解其大体的设计方式与编码习惯。由于之前对系统架构已有了解，阅读代码时，不应在一开始就去理解代码实现的细节，而应结合架构文档，比对代码实现是否与文档的描述一致，并充分利用自己的技术与经验，找到阅读代码的终南捷径。例如，如果我们知道该系统采用了MVC架构，就可以很容易地根据Url找到对应的Controller对象，并在该对象中寻找业务功能实现的脉络。又例如我们知道系统采用了SSH框架，而我们又非常熟悉SSH框架，就可以基本忽略系统基础设施的部分，直接了解系统的业务实现。如果是Swing系统，而且在界面中混杂了大量的业务逻辑和界面逻辑，则需要找到系统实现的特点，譬如系统的业务都是通过菜单项进行操作，就可以在界面中找到相关的菜单对象，然后根据这些对象的Action操作，一步一步跟踪。甚至可以利用调试的方法，设置断点，来摸清楚系统的运行机制与执行顺序。
分析遗留系统需要有的放矢，根据目标快速锁定范围。例如，如果我们是因为系统性能出现问题，而要去分析遗留系统，就无需过于关心业务逻辑，而应从性能分析入手。考虑数据库的访问，IO操作，缓存机制，资源的使用等诸多方面。这就需要借助一些经验和技术了，当然也可以考虑使用一些工具，用以诊断性能瓶颈。我们曾经在一个项目中，发现遗留系统的性能问题非常严重。根据分析，我们发现系统对字符串的处理存在问题，大量使用了String类型的对象完成字符的拼接。而在进行数据库查询时，很多代码是直接性地一次将相关表的数据“拉”到内存的集合对象中，然后利用过滤器在集合对象中进行筛选。而在对数据进行更改时，又没有很好地利用业务特性，完成一次提交，导致产生多次数据库访问。在系统的某些公共模块中，重复多次加载了Spring的配置文件。还有某些占用了较大资源的对象，对于系统用户而言应该是同一个对象，但却没有设计为单例。因为我们抱着改善遗留系统性能的目的，所以在分析遗留系统时，就应该事先确定可能导致性能损耗的地方，而不是全方位地去了解整个系统。
在维护遗留系统时，需要根据不同的场景做出不同的决策。简言之，我们需要排定优先级。如果时间紧迫，则解决问题是第一要务。尽快通过出错情况和记录日志辨别出错原因，定位出错代码，并解决之，而不是去考虑设计的优雅，代码的重用。我在一次解决报表显示的问题时，采用的就是这种做法。虽然与错误相关的代码相当丑陋，但由于时间紧迫，解决Bug才是最要紧的，所以我基本上没有去修改或改善既有代码的结构，仅仅解决了问题就结束了对遗留系统的处理。这个问题的处理过程在我的另一篇博客《精益求精，抑或得过且过》中详细论述。是的，我在此时选择了得过且过的做法，主要原因就在于优先级列表中，问题的解决才是最高优先级。在这次处理过程中，我部分地利用了copy & paste的做法，并通过引入新方法的方式来解决bug，而不是直接修改出现问题的方法。这是因为该方法的引用点存在多处，由于遗留系统并没有单元测试的保护，我不能草率地修改，否则可能导致一个bug的修复，结果引入更多无法预测的Bug。
这样的处理方式其实是我不甘心的选择。在时间允许的情况下，我会考虑对相关代码进行一些小的重构，例如提取方法或提取类等。虽然这些重构不能改变遗留系统的本质，但至少可以提高代码的可读性，并能在一定程度下去除代码重复。
这一实例实际引出了单元测试的必要性。如果我们的开发都能够在单元测试的呵护下进行，即使当它随着时间的推移，慢慢变成了丑陋的遗留代码，因为有单元测试的保护，在对它进行手术时，成功的几率却会变得更大。因此，认为编写单元测试是浪费时间的观点，事实上是一种短视的做法。缺乏单元测试，就是一种技术债(technical debt)。现在欠下的，将来总是要还的。我们不能忽略软件的维护成本。事实上，在软件成本中，维护成本所占的比例远远大于开发成本。Kent Beck在《实现模式(Implementation Patterns)》一书中认为：“维护的代价很大，这是因为理解现有代码需要花费时间，而且容易出错。知道了需要修改什么以后，做出改动就变得轻而易举了。掌握现在的代码做了哪些事情是最需要花费人力物力的部分，改动之后，还要进行测试和部署。”
当然，在处理遗留系统时，仍然可以进行单元测试。但它需要的技能更高，付出的精力更多。若要完成对遗留系统的单元测试，首要必须解决的就是依赖。解除依赖是面向对象系统开发中似乎亘古不变的话题。无论你翻阅哪一本面向对象著作，都会提到这个问题。依赖的起源其实在于对象的协作。根据单一职责原则，一个类显然不能承担太多的职责。如果一个系统的所有功能都是一个对象完成的，那么这个对象就成了邪恶的“上帝”对象。它的粒度太大，因此难以重用，不够灵活，细节纠缠，无法维护。这样的设计是我们必须避免的。既然一个类不能承担太多职责，系统要完成客户要求的所有功能，就必须让许多对象互相协作，就像人类社会的人际交往一般，于是，就产生了对象之间的依赖。凡事有利必有弊，这种细粒度的对象协作，虽然保证了对象的重用性、灵活性，却也因为协作带来的依赖，导致对象之间存在一定的耦合度，变得难以替换。由于一个对象依赖另一个对象，就使得我们在单元测试时，无法独立地测试我们的目标对象。
依赖虽然不可避免，但如果能够保证对象之间的良好协作，就能够最大程度保证系统的松耦合。对象协作一般可以分为类协作、接口协作与回调协作（回调协作通常可以看做是接口协作的一种特殊方式，关于这三种协作的特点与方式，我会在以后的文章中谈到）。依赖最弱的是接口协作，这也是我们努力达到的目标，它符合“面向接口设计”的基本原则。同时，也能够保证对象的封装性，通过将实现细节隐藏起来，从而降低对象之间的依赖程度。
知易行难，要对付遗留系统中的依赖问题，通常需要付出百倍的努力。Michael Feathers在其大作《修改代码的艺术(Working Effectively with Legacy Code)》中，给出了很多好的解除遗留代码依赖的实践。例如他提出的接缝类型，隐藏依赖，以及影响结构图。解除依赖需要合理地利用封装与抽象，包括对方法参数的封装与抽象。对于遗留系统而言，Feathers提出的影响结构图尤其有用。当你需要修改某个方法时，影响结构图可以帮助你分析该方法的依赖传播途径，避免因为修改对其他代码造成影响。具体做法可以参考该书。当然，现在有很多IDE工具事实上还支持生成依赖图，它可以在一定程度上帮助你寻找依赖的方向与结构。不过，手工方式的分析尤其是通过手绘影响结构图仍然不可缺少，它更能帮助你深入地理解遗留系统。为遗留系统绘制包图(Package Diagram)同样非常重要，它既能帮助你理解遗留系统的结构，又能为我们找到系统中可能存在的双向依赖和循环依赖，找到分解不合理的包，这就为我们的系统重构奠定了良好的基础。
如果遗留系统非常复杂，以至于无法重构，同时我们又需要在遗留系统的基础上增加新的特性和功能，好的做法就是做好新、旧功能之间的隔离。暂时可以不去考虑遗留系统的原有结构和代码（大多数情况，这些遗留系统其实是可以正常工作的），而只需要为新增的功能做好单元测试，并以好的设计原则与编码规范来要求新功能的实现。同时，我们还可以编写一些自动化的回归测试用例（例如使用Cucumber结合Watir为Web系统编写回归测试），保证新增的功能不会影响到原有系统。如果新增功能的实现需要调用原有系统中的某些类或方法，而这些类和方法却又难以分解，则可以考虑参照原有实现编写新的类或方法，新的类一定要做到合理的封装与抽象，保证它的高内聚与松耦合；也可以在新的类中不去真正实现，而是通过运用Adapter模式来重用旧有的类。
只要不是更改开发平台，通常情况下，我们不会考虑重写遗留系统。如果需要重构遗留系统，就必须采取“分而治之，小步前进”的策略。可以首先选择实现较为容易，或者独立性较好的模块进行重构。将遗留系统逐步提取为一些可重用的模块与类，就可以形成“星星之火，可以燎原”的态势。其中，对于原有类或模块的调用方，由于在重构时可能会更改接口，因此可以考虑引入Facade模式或Adapter模式，或者对接口进行另一层的包装，或者对接口进行适配，使系统慢慢被替换，最后演化为一个结构合理的良好系统。在重构时，甚至可以考虑将一些独立性很好的功能，提取为单独进程下的应用或服务，通过Web Service、Socket或Restful的方式进行调用，既保证了重用，又能够使遗留系统变得更简单，成功瘦身。
我们还需谨记的一点是，虽然模块乃至服务的重构对系统的改造更加重要，但我们却不能忽视代码的质量。小到方法的提取，以及变量的命名都非常重要。也许它不会给系统带来根本的改变，但它却能够改善代码的可阅读性，进而提高系统的可维护性。所谓”聚沙成塔“，无论是系统还是模块，其实都是这些类和方法以及变量组成的。
对遗留系统的处理不可能“一蹴而就”，必须遵循循序渐进的做法，逐步改善。处理遗留系统影响深远，成本也非常高，所以我们也不能因为脑袋一发热，就开始气势汹涌地“提枪上阵”，错将风车当做了魔鬼，结果撞得头破血流。必须对整个遗留系统进行审慎的分析，并结合具体情况考虑这项工程的复杂度、成本与预算，了解团队的重构与设计能力。处理遗留系统的前路漫漫，我们固然需要上下而求索的决心与勇气，却也不能在茫然失措中迷失了前进的方向。遗留系统的处理，必须慎之，慎之，再慎之！

什么是类加载器呢?
与普通程序不同的是，Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java class加载到JVM里头运行，负责加载Java class的这部分就叫做Class Loader。
JVM本身包含了一个ClassLoader称为Bootstrap ClassLoader，和JVM一样，BootstrapClassLoader是用本地代码实现的，它负责加载核心JavaClass（即所有java.*开头的类）。另外JVM还会提供两个ClassLoader，它们都是用Java语言编写的，由BootstrapClassLoader加载；其中Extension ClassLoader负责加载扩展的Javaclass（例如所有javax.*开头的类和存放在JRE的ext目录下的类），ApplicationClassLoader负责加载应用程序自身的类。
当运行一个程序的时候，JVM启动，运行bootstrapclassloader，该ClassLoader加载java核心API（ExtClassLoader和AppClassLoader也在此时被加载），然后调用ExtClassLoader加载扩展API，最后AppClassLoader加载CLASSPATH目录下定义的Class，这就是一个程序最基本的加载流程。

新华网北京1月29日电（记者张雪花） 不少人说，云计算产业的发展给城市插上了智慧的翅膀。2010年9月北京市经信委发布《北京“祥云工程”行动计划（2010-2015年）》，提出了北京市云计算产业发展的总体目标，如今两年多过去了，“北京云”发展得怎么样，给“智慧城市”建设及百姓生活带来哪些变化？本网记者就此专访了北京市经济和信息化委员会副主任姜贵平，副总工程师、软件与信息服务处处长姜广智。
谈到北京“祥云工程”的进展，姜贵平说，从2010年到2012年北京云计算产业三年迈了三大步，2010年是布局年，重点开展云基地建设；2011年是应用年，年底推出了祥云十大示范应用平台；2012年是创新年，在云计算产业链上推出了近100款新产品。目前北京云计算产业已形成南部亦庄北部中关村两大聚集区，参与云计算产业的企业已达150多家，很多应用已经落地，百姓可以实实在在感受到云计算带来的变化。2013年将是北京云产业的深耕年。
北京把云计算作为战略新兴产业的一个重要支撑，给予大力扶持。姜贵平说，这几年北京特别注重一些小企业的扶持发展，推动了50多个项目，投资了5个多亿，仅政府引导资金就有6亿多。据姜广智介绍，祥云工程实施以来，社会上的各类风险投资对北京云企业的投资已达86亿元左右。
谈到云应用，姜贵平说，云计算的发展和城市的智慧运行是相辅相成的，在政务应用上，北京率先建成了移动政务，只要有一部手机有网络，不管在当地还是出差都可以办公，此外还建立北京政府信息数据网，聚集了166类政务数据12万条，供相关方面挖掘利用。此外，北京政务云、交通云、安全云、教育云，社区云等模块的发展，也使得城市的运行、百姓的生活变得更加智慧。
“北京作为拥有2000多万人的大城市，有很多错综复杂的问题，这需要一些高端技术和大数据的挖掘，如果在北京用云计算解决这样的问题，它的示范引领作用是非常好的。”谈到北京云计算发展的特点，姜贵平如是说。
2012年3月北京市政府发布《智慧北京行动纲要》，提出到2015年，北京要实现从“数字北京”向“智慧北京”全面跃升。
针对公众关注的云数据中心的建设规模问题，姜广智作了回应，他认为，北京是国家数据中心比较密集的区域，其作为政治中心、经济中心、文化中心，本身就需要大量的数据中心。姜广智同时强调建设数据中心需要根据云计算发展的实际需要，也需要企业对市场的准确判断，反对片面追求数据中心的规模和数量。
《北京“祥云工程”行动计划》提出，2010到2015年通过“千人计划”及“海聚工程”引进30名云计算领军人才。对此，姜广智说，北京近两年通过国家“千人计划”和北京“海聚工程”已引进了22名领军人才，对突破一些发展瓶颈问题起到了非常重要的作用，但依然缺少对新的商业模式和最前沿的技术有研究的高端人才。
http://news.hexun.com/2013-01-29/150722949.html
附：
北京“祥云工程”行动计划
（2010—2015年）
一、前言
云计算是基于互联网、通过虚拟化方式共享资源的计算模式，使计算、存储、网络、软件等资源，按照用户的动态需要，以服务的方式提供。云计算是继个人电脑、互联网之后，信息技术的重大革新，为我市打造世界城市、落实《科技北京行动计划》、加快建设中关村国家自主创新示范区，促进软件和信息服务业的新发展，提供了重大的发展机遇。
为了加快推进北京云计算相关产业的发展，力争在新一轮信息技术的国际竞争中抢占先机，占领高端，形成新优势，市发展改革委、市经济信息化委和中关村科技园区管委会，组织北京云计算领域的骨干企业，制定本行动计划。
二、指导思想和总体目标
（一）指导思想
以科学发展观为指导，以培育新业态、发展新商业模式、构造新产业链为核心，形成应用带动，创新驱动、面向全球的发展模式，建立政府引导、企业主体、产学研联合的发展机制，积极参与国际间竞争合作，有效整合高端人才、风险投资、产业基地、创新性企业等产业发展要素，推动我市云计算产业早起步、快发展、上规模，成为北京战略性新兴产业的突破口。
（二）实施原则
服务引领。面向建设世界城市的信息化要求，以全面提升城市信息化基础设施能力为契机，在政务信息化、社会信息化和经济信息化领域，加快建设一批云应用示范工程，培育云服务市场，引导下游产业发展。
产业链联动。围绕芯片、硬件、网络、运营商、终端及各种云应用，构造完整的云计算产业链条，带动我市信息技术产业的整体提升。
国际同步。积极利用好国际开源社区资源，充分发挥海外华人云计算人才和企业家作用，加大引入和并购国外云计算企业力度，以国际化水准，高起点规划和实施祥云工程。
走自主道路。以技术创新和商业模式创新为动力，掌握关键核心技术，鼓励发展新型业态，支持研制自主的标准和规范，支持探索符合中国客户要求和习惯的服务模式和业务模式。
（三）总体目标
形成技术、产品和服务一体化发展的产业格局，发展一批高效能、高安全、低成本的云服务，聚集一批世界领先、全国领军的云计算企业，形成一批创新性的新技术、新产品、新标准。到2015年云计算的三类典型服务（IaaS、PaaS、SaaS）形成500亿元产业规模，带动产业链形成2000亿元产值，云应用水平居世界各主要城市前列，成为世界级的云计算产业基地。
三、主要任务
（一）重点发展领域
1.云计算适用芯片和软件平台
加快低功耗芯片、新型嵌入式软件系统、云计算软件平台的开发和产业化，为云计算的发展提供产业基础支撑，形成十余家掌握云计算的核心技术的骨干企业群体。
2.云服务产品
以云计算的基础设施服务（IaaS）、平台服务（PaaS）、软件服务（SaaS）等3个服务线为核心，整合我市信息服务业资源，促进现有的电信运营商、软件提供商、信息服务提供商、内容提供商等的转型。形成十余家规模级IaaS企业，发展百家有独特技术价值、良好商业模式的PaaS和SaaS企业。
3.云计算解决方案
充分利用本市系统集成企业在传统软件领域行业解决方案优势，根据云计算技术、产品和服务特点，研发适合各行业的云计算解决方案，继续保持北京在云计算服务时代企业后台软件系统主力供应商的地位。
4.云计算网络产品
以新架构服务器、新一代网络存储系统、下一代网络设备、新型计算单元为重点，积极扩大同国际企业的合作，特别利用好华人企业家的资源，构建我市云计算网络产品体系，创建十余个新的优势品牌。
5.云计算终端产品
积极发展下一代移动通信终端、移动互联网智能设备、平板电脑、电子书、感知终端等多种云计算终端产品，支持形成以新型终端为龙头的、集硬件、软件、服务、内容与一体的云计算产业生态圈，培育百亿元级别的产业链。
（二）重点发展技术方向
1.集中力量攻关云计算核心技术。配合国家科技重大专项的实施，在虚拟化技术、高性能存储技术、新一代搜索引擎、云计算安全技术、网络操作系统、云计算服务测试验证技术上争取有所突破。
2.积极发展云计算同其他新兴技术的融合。支持把云计算技术同物联网应用、下一代互联网应用、三网融合应用相结合，配合新兴技术的发展规划，发展支持智能电网、节能减排、移动互联、位置与导航服务、电子商务服务、大规模视频采集和播发等新兴业务所需要的云计算能力和软件云处理能力。
3.大力发展绿色IT技术。采用新一代低功耗技术，加大与服务器、存储设备及交换机等高耗能设备相关的绿色技术开发和运用；充分利用云计算的集中计算机制，大幅降低信息化应用和软件信息服务业的能耗，达到在云—-端两方面的节能减排目的。
（三）重点工程
1.云应用重大示范工程
以“祥云工程”的实施为抓手和推进平台，在电子政务、重点行业应用、互联网服务、电子商务等主要应用方向上实施一批不同层次和功能的云计算重大工程。推动电子政务全面向云时代转型，统一规划和抓紧建设“政务云”，带动全市云应用的起步。支持社会机构和企业，利用云计算创新的服务模式，建设和运营面向经济和社会发展的公有云，包括行业云和区域云，迅速形成面向市场的社会化应用。
2.云计算产业基地建设工程
在中关村核心区规划建设北京云计算产业基地，加强政府战略引导，聚集一批云计算科研机构和产业链各环节的核心企业；依托产业基地，建设云计算公共测试和验证平台，云计算产品和服务演示体验中心等重大公共服务平台，引导基地建设成为云服务产品创新中心、技术交流中心、应用示范中心和服务运营中心，成为全球有影响力的云计算产业基地。
3.云服务标准规范创制工程
积极参与国际云计算标准工作，组织参与“祥云工程”的骨干企业研究利用好国际上已有的成熟标准和规范，开放性地做好云计算标准体系的构建工作。积极开展自主标准和规范的创制工作。力争在云安全、服务能力与质量、开放接口、体系架构评估认证等环节形成具有自主知识产权的标准。
4.面向云计算的技术改造工程
充分利用存量资源，支持传统的IT企业围绕云计算技术开展新产品开发、新服务体系构建、新技术架构升级等技术改造工作。引导软件和信息系统集成企业通过技术改造，大力发展云平台的咨询设计能力、集成建设能力和云服务能力；运营商、互联网信息服务和内容服务企业，要通过技术创新和模式创新，加快向云服务方向转型。
四、保障措施
（一）成立“祥云工程”联合工作组，加强统筹协调。
市经济信息化委、市发展改革委、中关村管委会联合牵头，组织云计算产业链中的代表性企业成立联合工作组，制定北京云计算产业发展路线图，在政策制定、标准研究、产业联合、科研攻关等方面加强统筹推进力度。
组建“祥云工程”专家委员会，为祥云工程的实施提供决策支持。
举办北京云计算产业发展国际高层论坛，打造政府与国内外企业家互动的高端平台，成为引进国外智力和项目的重要渠道。
（二）建立“祥云工程”重点项目库，加大资金投入力度。
对“祥云工程”的重点项目实行政府全程跟踪服务，定期进行调度协调，择优给予重点支持。将支持祥云工程的资金列入政府统筹重大科技资金和产业资金的支持范围，采取资本金注入、贷款贴息、投资补助等方式，支持云计算的技术改造项目、成果产业化项目、产业基地建设项目等。积极争取祥云工程的重点项目得到国家各种专项资金的支持。充分发挥政府投入对社会投资的引导带动作用，引导风险投资支持北京云计算相关产业。
（三）完善政策体系，创造良好云计算产业发展环境。
将云计算作为我市新时期电子政务的重要模式加以推广，在市区县各级政府部门积极开展云计算应用。
将云服务模式纳入政府采购。在政府部门和公用事业的信息化应用中采购云服务，以政府采购引导云计算的发展。
政府支持建设一批服务中小企业两化融合、产业结构调整的云平台。对于提供北京工业企业、中小企业和高新技术急需的云计算应用服务，如小型企业的信息化平台、工程计算平台、信息情报平台、音视频开发制作平台等，可以根据北京企业使用云服务数量和品质，给以相应的支持。
（四）对接国家资源，积极争取相关项目在北京率先试点应用。
积极争取国家发展改革委、科技部、工信部等国家部委的支持，组织协调本市企业承接云计算相关的国家重大科技攻关和产业化工程，推动国家重大专项在北京落地，对承接国家项目的企事业单位优先给予地方政府的配套支持。整合资源，创造条件争取国家重大工程在北京率先应用试点。
（五）加强高端人才培养和引进力度。
协助企业引进云计算领域国际优秀人才，充分利用好中央“千人计划”和本市“海聚工程”的平台，引进一批掌握前沿技术的创新创业人才，2010年到2015年通过“千人计划”和“海聚工程”引进30名云计算领军人才。
加强对国内云计算人才的引进和奖励政策，将云计算领域纳入人才引进目录，并将重点云计算企业纳入高级人才奖励范围。
（六）发挥中介组织作用，鼓励发展机制创新。
支持云计算企业发起组建云计算产业联盟等中介组织。鼓励中介组织制定行业公约规范，加强行业自律。引导产业链内部各种形式的资源整合和横向联合，创新产业发展机制，形成集团化、组织化的推进模式，培育产业高端创新集群。
五、结语
云计算是新一代信息技术变革的核心，是战略性新兴产业的发展引擎。云计算的发展将改变CPU、存储、服务器、终端、操作系统及应用软件的整条信息产业链，并深远地影响从生产到生活的信息化应用。“祥云工程”作为北京市发展战略性新兴产业的重要工程，将以云计算技术的兴起为新契机，抢占新的战略制高点，全面优化和提升北京信息技术产业，使北京成为中国乃至全球的云计算中心。

welcome-file-list是一个配置在web.xml中的一个欢迎页，用于当用户在url中输入工程名称或者输入web容器url（如http://localhost:8080/）时直接跳转的页面。碰到一个问题是访问报404找不到的错误，welcome-file-list没有起作用。
welcome-file-list的工作原理是，按照welcome-file的.list一个一个去检查是否web目录下面存在这个文件，如果存在，继续下面的工作（或者跳转到index.html页面，或者配置有struts的，会直接struts的过滤工作）。先去webcontent(这里是Eclipse的工程目录根目录)下是否真的存在index.html这个文件，如果不存在去找是否存在index.jsp这个文件，依次类推。

<welcome-file-list>
	<welcome-file>VideoRankAction!goVideoRank10.action</welcome-file>
</welcome-file-list>

welcome-file不一定是html或者jsp等文件，也可以是直接访问一个action。但要注意的是，一定要在webcontent下面建立一个index.action的空文件，然后使用struts配置去跳转，不然web找不到index.action这个文件，会报404错误。
如何不让地址栏显示后缀，只展示域名：
1、在没进行这样设置之前，当在地址栏中输入域名地址：http://www.xxxxx.com，浏览器解析后，地址栏会出
现http://www.xxxxx.com/xxx/xxx.do。
2、经过如上设置之后，输入http://www.xxxxx.com后，不再会出现后面的后缀。
做法：
1、在web.xml中，定义welcome-file为一个jsp页面：

<welcome-file-list>
        <welcome-file>/index.jsp</welcome-file>
</welcome-file-list>

2、然后在该jsp页面中引入需要显示的action，如：

<c:import url="/xxx.do"/>

注：在表头需要导入jstl包

<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

JavaZone2011惊悚大片-Java阴魂不散

URL静态化-UrlRewriteFilter-urlrewrite.xml
UrlRewriteFilter是一个用于改写URL的Web过滤器，类似于Apache的mod_rewrite，最典型应用就把动态URL静态化，便于搜索引擎爬虫抓取你的动态网页，并且适用于任何Web应用服务器（如 Resin，Orion，Tomcat等）。
URL静态化的好处很多：
1、对搜索的友好，因为有些搜索不能抓取动态页面或者对动态抓取的页面没有静态页面效率高。
2、屏蔽内部的url或文件路径结构。
3、美化url，看起来更像html页面。
UrlRewriteFilter使用：
1、下载http://tuckey.org/urlrewrite/#download。解压后将文件放到相应的web-inf/lib和web-inf下。
2、配置web.xml

<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
 </filter>
<filter-mapping>
   <filter-name>UrlRewriteFilter</filter-name>
   <url-pattern>/*</url-pattern>
 </filter-mapping>

根据自己的需要，将相应目录下的url转给UrlRewriteFilter来处理。
3、配置urlwrite规则文件WEB-INF/urlrewrite.xml

<rule>
     <from>/vr_show/showid_z([^.]*).*</from>
     <to type="forward">ProAction!vrShow.action?showId=$1</to>
</rule>

注意：
1、urlrewrite.xml是utf-8，所以如果你要在rule上加note标签为中文的话，也一定是要utf-8
2、UrlRewriteFilter最好是配置在web.xml的前面filter上，不然有可能对有些url转换失去作用。
3、在写rule的时,如果有多个参数时，中间的连接符号&应该是&amp。
urlrewrite.xml标签的一些说明：
urlrewrite属性：有仅只有一个。
rule属性：至少一个。
name属性：可选。
note属性：可选。
condition属性：可选。
type属性：最主要就是 forward (default)：在客户端URL是不转向的 redirect 在客户端URL是转向的，所以一般采用 forward。
set属性：这个有点像apache中的rewrite了，除了下面的设置client，还可以设置cookie，content-  type，charset，header，request。

《我的程序里》！没有一点点防备/也没有一丝顾虑/突然错误出现/在我的日志里/带给我惊奇/身不由己/可是你偏又这样/在我不知不觉中悄悄地消失/从我的堆栈里没有音讯/剩下了报警短信

百度作为全球最大的中文搜索引擎公司，提供基于搜索引擎的各种产品，几乎覆盖了中文网络世界中所有的搜索需求,因此，百度对海量数据处理的要求是比较高的，要在线下对数据进行分析，还要在规定的时间内处理完并反馈到平台上。百度在互联网领域的平台需求要通过性能较好的云平台进行处理了，Hadoop就是很好的选择。在百度，Hadoop主要应用于以下几个方面：
日志的存储和统计;
网页数据的分析和挖掘;
商业分析，如用户的行为和广告关注度等;
在线数据的反馈，及时得到在线广告的点击情况;
用户网页的聚类，分析用户的推荐度及用户之间的关联度。
MapReduce主要是一种思想，不能解决所有领域内与计算有关的问题，百度的研究人员认为比较好的模型应该如图3-4所示，HDFS实现共享存储，一些计算使用MapReduce解决，一些计算使用MPI解决，而还有一些计算需要通过两者来共同处理。因为MapReduce适合处理数据很大且适合划分的数据，所以在处理这类数据时就可以用MapReduce做一些过滤，得到基本的向量矩阵，然后通过MPI进一步处理后返回结果，只有整合技术才能更好地解决问题。
百度现在拥有3个Hadoop集群，总规模在700台机器左右，其中有100多台新机器和600多台要淘汰的机器(它们的计算能力相当于200多台新机器)，不过其规模还在不断的增加中。现在每天运行的MapReduce任务在3000个左右，处理数据约120TB/天。
百度为了更好地用Hadoop进行数据处理，在以下几个方面做了改进和调整：
(1)调整MapReduce策略
限制作业处于运行状态的任务数;
调整预测执行策略，控制预测执行量，一些任务不需要预测执行;
根据节点内存状况进行调度;
平衡中间结果输出，通过压缩处理减少I/O负担。
（2）改进HDFS的效率和功能
权限控制，在PB级数据量的集群上数据应该是共享的，这样分析起来比较容易，但是需要对权限进行限制;
让分区与节点独立，这样，一个分区坏掉后节点上的其他分区还可以正常使用;
修改DFSClient选取块副本位置的策略，增加功能使DFSClient选取块时跳过出错的DataNode;
解决VFS(Virtual File System)的POSIX(Portable Operating System Interface of Unix)兼容性问题。
（3）修改Speculative的执行策略
采用速率倒数替代速率，防止数据分布不均时经常不能启动预测执行情况的发生;
增加任务时必须达到某个百分比后才能启动预测执行的限制，解决reduce运行等待map数据的时间问题;
只有一个map或reduce时，可以直接启动预测执行。
（4）对资源使用进行控制
对应用物理内存进行控制。如果内存使用过多会导致操作系统跳过一些任务，百度通过修改Linux内核对进程使用的物理内存进行独立的限制，超过阈值可以终止进程。
分组调度计算资源，实现存储共享、计算独立，在Hadoop中运行的进程是不可抢占的。
在大块文件系统中，X86平台下一个页的大小是4KB。如果页较小，管理的数据就会很多，会增加数据操作的代价并影响计算效率，因此需要增加页的大小。
百度在使用Hadoop时也遇到了一些问题，主要有：
MapReduce的效率问题：比如，如何在shuffle效率方面减少I/O次数以提高并行效率;如何在排序效率方面设置排序为可配置的，因为排序过程会浪费很多的计算资源，而一些情况下是不需要排序的。
HDFS的效率和可靠性问题：如何提高随机访问效率，以及数据写入的实时性问题，如果Hadoop每写一条日志就在HDFS上存储一次，效率会很低。
内存使用的问题：reducer端的shuffle会频繁地使用内存，这里采用类似Linux的buddy system来解决，保证Hadoop用最小的开销达到最高的利用率;当Java 进程内容使用内存较多时，可以调整垃圾回收(GC)策略;有时存在大量的内存复制现象，这会消耗大量CPU资源，同时还会导致内存使用峰值极高，这时需要减少内存的复制。
作业调度的问题：如何限制任务的map和reduce计算单元的数量，以确保重要计算可以有足够的计算单元;如何对TaskTracker进行分组控制，以限制作业执行的机器，同时还可以在用户提交任务时确定执行的分组并对分组进行认证。
性能提升的问题：UserLogs cleanup在每次task结束的时候都要查看一下日志，以决定是否清除，这会占用一定的任务资源，可以通过将清理线程从子Java进程移到TaskTracker来解决;子Java进程会对文本行进行切割而map和reduce进程则会重新切割，这将造成重复处理，这时需要关掉Java进程的切割功能;在排序的时候也可以实现并行排序来提升性能;实现对数据的异步读写也可以提升性能。
健壮性的问题：需要对mapper和reducer程序的内存消耗进行限制，这就要修改Linux内核，增加其限制进程的物理内存的功能;也可以通过多个map程序共享一块内存，以一定的代价减少对物理内存的使用;还可以将DataNode和TaskTracker的UGI配置为普通用户并设置账号密码;或者让DataNode和TaskTracker分账号启动，确保HDFS数据的安全性，防止Tracker操作DataNode中的内容;在不能保证用户的每个程序都很健壮的情况下，有时需要将进程终止掉，但要保证父进程终止后子进程也被终止。
Streaming局限性的问题：比如，只能处理文本数据，mapper和reducer按照文本行的协议通信，无法对二进制的数据进行简单处理。为了解决这个问题，百度人员新写了一个类Bistreaming(Binary Streaming)，这里的子Java进程mapper和reducer按照(KeyLen，Key，ValLen，Value)的方式通信，用户可以按照这个协议编写程序。
用户认证的问题：这个问题的解决办法是让用户名、密码、所属组都在NameNode和Job Tracker上集中维护，用户连接时需要提供用户名和密码，从而保证数据的安全性。
百度下一步的工作重点可能主要会涉及以下内容：
内存方面，降低NameNode的内存使用并研究JVM的内存管理;
调度方面，改进任务可以被抢占的情况，同时开发出自己的基于Capacity的作业调度器，让等待作业队列具有优先级且队列中的作业可以设置Capacity，并可以支持TaskTracker分组;
压缩算法，选择较好的方法提高压缩比、减少存储容量，同时选取高效率的算法以进行shuffle数据的压缩和解压;
对mapper程序和reducer程序使用的资源进行控制，防止过度消耗资源导致机器死机。以前是通过修改Linux内核来进行控制的，现在考虑通过在Linux中引入cgroup来对mapper和reducer使用的资源进行控制;
将DataNode的并发数据读写方式由多线程改为select方式，以支持大规模并发读写和Hypertable的应用。
百度同时也在使用Hypertable，它是以Google发布的BigTable为基础的开源分布式数据存储系统，百度将它作为分析用户行为的平台，同时在元数据集中化、内存占用优化、集群安全停机、故障自动恢复等方面做了一些改进。
下面这几篇文章也是介绍百度hadoop应用的情况：
http://blog.csdn.net/zbf8441372/article/details/8169969
http://www.csdn.net/article/2011-04-28/296869
http://www.cnblogs.com/chinacloud/archive/2010/11/08/1871592.html

Lady Java视频

Google的三大核心技术MapReduce、GFS和BigTable论文（中文翻译版）
MapReduce：
http://blog.csdn.net/active1001/archive/2007/07/02/1675920.aspx
GFS:
http://blog.csdn.net/xuleicsu/archive/2005/11/10/526386.aspx
BigTale:
http://blog.csdn.net/accesine960/archive/2006/02/09/595628.aspx