在网上看到这么一句话觉得总结的非常好：
从高内聚，低耦合到设计模式，从 Ioc 、 Spring 框架 到 SOA 我们一步一步的抽象着、分离着。很显然，我们需要一个灵活而不失严谨的架构，需要一个功能强进而不令人生畏的产品；
企业的应用软件发展还有着很大的空间和尺度，也大概明白为什么OSGI起源于1999年却近几年才进入软件行业，当时软件业确实还不发达，人们确实想不了这么多，做软件只为了能解决一些问题而做。而如今更多是要资源最大化共享，就想着怎么能把原来做过的软件集成起来，不用再做个新的，于是就有了SOA。随着Eclipse的成功，大家对它以OSGI为核心的插件体系无不赞叹，原来做软件可以像搭积木一样的拼装，多么美妙，人们也就认识到了OSGI的重要性和带来的好处，近两年OSGI正在飞速发展，相信以后会有更大的发展空间，网上有人预言说将来OSGI一定会装在60%的java虚拟机上，还有人说这么好的架构应该直接纳入JDK，这些都有点极端，但是可以看出它是多么的优秀。越来越多的软件开始支持OSGI。
OSGI的强项是它的动态加载和对Bundle之间的通信和管理及依赖关系，而更细粒度bundle内部则没有严格的管理体系，Spring可以对bundle内部进行更为细粒度的管理，Spring将在配置文件中增加直接支持OSGI的配置项。
他们的组合可以把底耦合的应用程序“模块化”。
运行期间多个版本的应用同时部署，动态选择，当然这是OSGI的特性，但是有Spring的配置将更好。
运行期间多模块(服务)的替换。
运行期间动态部署，更新或反部署模块。
应用Spring配置，装配模块。
用简单和熟悉的编程方式开发具有OSGI特征的程序。
Hibernate现在也可以集成到OSGI，为OSGI持久层又添了一笔，可以看出Spring+OSGI+hibernate前途无量。

对于OSGi，有人评论称OSGi是“Spring之后的下一个big thing”。不过该文的作者后来又觉得，OSGi也有不少的问题，其中之一就是它在把技术变得复杂化。作者是这样说的：
　　我对OSGi不怀疑并承认OSGi解决了许多问题，而且它支持一些出众的结构模型比如高模块化（high modularization）以及微服务（micro services）。然而从另外一个角度来说，在使用了OSGi几年之后，也体验了它在不同领域的表现（我是指开发领域）之后，我真的开始怀疑OSGi了。
　　这是我喜欢和讨厌的OSGi的一些方面：
　　它从几百个具有代表性的小bundle中创建出一个系统的概念非常棒。OSGi bundle很好的一点是它们定义了边界：不仅从依赖关系的意义上，而且从运行时间的意义上也是这样。每个bundle可以充当一个微应用，有自己的lifecycle和用户，每个bundle能够仔细地断定出哪个对象对外暴露。好好地使用它们，会带给系统以松耦合，并增加再使用的可能性。而与此同时，OSGi的lifecycle使life更加复杂。实际上，追踪服务和管理服务所引发的各个问题很讨厌（我曾看到过在它们的bundle activators使用大型的state machines来管理所有事情，这种样板化代码没有人愿意写）。幸运的是有Spring DM来帮我们管理这些。坦白说，如果没有Spring DM我绝不会动手开始OSGi项目。尽管Spring DM大大降低了bundle启动的复杂度，但仍然很麻烦。我仍然需要启动OSGi的运行时间、安装启动bundles，我还需要确保所有其他我所需要的bundles已经安装和启动。
　　我个人觉得，作为开发者，我们应当迫使自己执行系统的约束。我们不得不自动核对定义的限制，比如说，如果我们读取了一些我们并不想读取的类，构建程序就会失败。OSGi的版本概念，通过定义输入和输出包，将架构参数（architectural constraints）首次带入开发者的日常生活，并引入了一系列新的问题。OSGi是这样解决运行时间的版本问题的：它给每个bundle自己的class loader，并让class loader看起来像它所在的版本一样。这也带来一系列问题，因为它改变了你环境工作的方式。你的代码在所有你的单元测试中都可以通过，但一旦执行在OSGi的运行时间上，就会崩溃；Libraries崩溃因为这提升了运行时间中的类；Singletons被设计为静态对象不止一次地被创建，周而复始。当你在不断地调整你的模块构建说明时你会经常终止，而且绝对会在你的整个系统中传播反直观的依赖关系。Spring DM也是这个问题：通过在你的服务中添加一些指令并且不断地调整你的class loaders，你仍然需要调整和传送依赖关系。
　　尤其是类的导入更是带来很麻烦的问题。你很快会注意到，没有强大和自动集成的测试组件来配合OSGi，你无法继续下去。
　　现在说一下我的结论：
　　在考虑OSGi之前，我会切实核实是否在不关闭系统的情况下我能否在运行时间中转换bundles，即使在这种情况下，我也会再次查看这些需求，来看看是否我会把他们限制在一个角落里，在这里我可以使用其他技术在动态时间上来动态地加载模块。还有其他选择可以生成这种结构条例（比如使用一个IOC container，使用独立的container来执行模块依赖等等……）许多这些东西都很接近KISS原则，避免所有其他附件的样板化代码并构建配置，这因此让你更加敏捷。
　　回归到我的题目上，还有一种技术拥有这样的特点（我是指让技术更加复杂），那就是EJB。Spring是最流行的实例：技术更加复杂，开发周期更加困难。也许我们会在未来的几年内在OSGi中看到同样的境遇？我无法断定，时间将验证一切。

O/R Mapping 是 Object Relational Mapping（对象关系映射）的缩写。通俗点讲，就是将对象与关系数据库绑定，用对象来表示关系数据。在O/R Mapping的世界里，有两个基本的也是重要的东东需要了解，即VO，PO。
　　VO，值对象(Value Object)，PO，持久对象(Persisent Object)，它们是由一组属性和属性的get和set方法组成。从结构上看，它们并没有什么不同的地方。但从其意义和本质上来看是完全不同的。
１．VO是用new关键字创建，由GC回收的。
　　PO则是向数据库中添加新数据时创建，删除数据库中数据时削除的。并且它只能存活在一个数据库连接中，断开连接即被销毁。
２．VO是值对象，精确点讲它是业务对象，是存活在业务层的，是业务逻辑使用的，它存活的目的就是为数据提供一个生存的地方。
　　PO则是有状态的，每个属性代表其当前的状态。它是物理数据的对象表示。使用它，可以使我们的程序与物理数据解耦，并且可以简化对象数据与物理数据之间的转换。
３．VO的属性是根据当前业务的不同而不同的，也就是说，它的每一个属性都一一对应当前业务逻辑所需要的数据的名称。
　　PO的属性是跟数据库表的字段一一对应的。
PO对象需要实现序列化接口。
————————————————-
PO是持久化对象，它只是将物理数据实体的一种对象表示，为什么需要它？因为它可以简化我们对于物理实体的了解和耦合，简单地讲，可以简化对象的数据转换为物理数据的编程。VO是什么？它是值对象，准确地讲，它是业务对象，是生活在业务层的，是业务逻辑需要了解，需要使用的，再简单地讲，它是概念模型转换得到的。
首先说PO和VO吧，它们的关系应该是相互独立的，一个VO可以只是PO的部分，也可以是多个PO构成，同样也可以等同于一个PO（当然我是指他们的属性）。正因为这样，PO独立出来，数据持久层也就独立出来了，它不会受到任何业务的干涉。又正因为这样，业务逻辑层也独立开来，它不会受到数据持久层的影响，业务层关心的只是业务逻辑的处理，至于怎么存怎么读交给别人吧！不过，另外一点，如果我们没有使用数据持久层，或者说没有使用hibernate，那么PO和VO也可以是同一个东西，虽然这并不好。
—————————————————-
java的(PO,VO,TO,BO,DAO,POJO)解释
PO(persistant object) 持久对象
在o/r映射的时候出现的概念，如果没有o/r映射，没有这个概念存在了。通常对应数据模型(数据库),本身还有部分业务逻辑的处理。可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作。
VO(value object) 值对象
通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递。
TO(Transfer Object)，数据传输对象
在应用程序不同tie(关系)之间传输的对象
BO(business object) 业务对象
从业务模型的角度看,见UML元件领域模型中的领域对象。封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作。
POJO(plain ordinary java object) 简单无规则java对象
纯的传统意义的java对象。就是说在一些Object/Relation Mapping工具中，能够做到维护数据库表记录的persisent object完全是一个符合Java Bean规范的纯Java对象，没有增加别的属性和方法。我的理解就是最基本的Java Bean，只有属性字段及setter和getter方法！。
DAO(data access object) 数据访问对象
是一个sun的一个标准j2ee设计模式，这个模式中有个接口就是DAO，它负持久层的操作。为业务层提供接口。此对象用于访问数据库。通常和PO结合使用，DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作。夹在业务逻辑与数据库资源中间。配合VO, 提供数据库的CRUD操作…
O/R Mapper 对象/关系 映射
定义好所有的mapping之后，这个O/R Mapper可以帮我们做很多的工作。通过这些mappings,这个O/R Mapper可以生成所有的关于对象保存，删除，读取的SQL语句，我们不再需要写那么多行的DAL代码了。
实体Model(实体模式)
DAL(数据访问层)
IDAL(接口层)
DALFactory(类工厂)
BLL(业务逻辑层)
BOF Business Object Framework 业务对象框架
SOA Service Orient Architecture 面向服务的设计
EMF Eclipse Model Framework Eclipse建模框架
—————————————-
PO：全称是
persistant object持久对象
最形象的理解就是一个PO就是数据库中的一条记录。
好处是可以把一条记录作为一个对象处理，可以方便的转为其它对象。
BO：全称是
business object:业务对象
主要作用是把业务逻辑封装为一个对象。这个对象可以包括一个或多个其它的对象。
比如一个简历，有教育经历、工作经历、社会关系等等。
我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。
建立一个对应简历的BO对象处理简历，每个BO包含这些PO。
这样处理业务逻辑时，我们就可以针对BO去处理。
VO ：
value object值对象
ViewObject表现层对象
主要对应界面显示的数据对象。对于一个WEB页面，或者SWT、SWING的一个界面，用一个VO对象对应整个界面的值。
DTO ：
Data Transfer Object数据传输对象
主要用于远程调用等需要大量传输对象的地方。
比如我们一张表有100个字段，那么对应的PO就有100个属性。
但是我们界面上只要显示10个字段，
客户端用WEB service来获取数据，没有必要把整个PO对象传递到客户端，
这时我们就可以用只有这10个属性的DTO来传递结果到客户端，这样也不会暴露服务端表结构.到达客户端以后，如果用这个对象来对应界面显示，那此时它的身份就转为VO
POJO ：
plain ordinary java object 简单java对象
个人感觉POJO是最常见最多变的对象，是一个中间对象，也是我们最常打交道的对象。
一个POJO持久化以后就是PO
直接用它传递、传递过程中就是DTO
直接用来对应表示层就是VO
DAO：
data access object数据访问对象
这个大家最熟悉，和上面几个O区别最大，基本没有互相转化的可能性和必要.
主要用来封装对数据库的访问。通过它可以把POJO持久化为PO，用PO组装出来VO、DTO
—————————————————————–
PO:persistant object持久对象,可以看成是与数据库中的表相映射的java对象。最简单的PO就是对应数据库中某个表中的一条记录，多个记录可以用PO的集合。PO中应该不包含任何对数据库的操作.
VO:value object值对象。通常用于业务层之间的数据传递，和PO一样也是仅仅包含数据而已。但应是抽象出的业务对象,可以和表对应,也可以不,这根据业务的需要.个人觉得同DTO(数据传输对象),在web上传递.
DAO:data access object数据访问对象，此对象用于访问数据库。通常和PO结合使用，DAO中包含了各种数据库的操作方法。通过它的方法,结合PO对数据库进行相关的操作.
BO:business object业务对象,封装业务逻辑的java对象,通过调用DAO方法,结合PO,VO进行业务操作;
POJO:plain ordinary java object 简单无规则java对象,我个人觉得它和其他不是一个层面上的东西,VO和PO应该都属于它.
———————————————
VO：值对象、视图对象
PO：持久对象
QO：查询对象
DAO：数据访问对象
DTO：数据传输对象
—————————————-
struts 里的 ActionForm 就是个VO;
hibernate里的 实体bean就是个PO,也叫POJO;
hibernate里的Criteria 就相当于一个QO;
在使用hibernate的时候我们会定义一些查询的方法,这些方法写在接口里,可以有不同的实现类.而这个接口就可以说是个DAO.
个人认为QO和DTO差不多.
—————————————-
PO或叫BO，与数据库最接近的一层，是ORM中的O，基本上是数据库字段对应BO中的一个属性，为了同步与安全性考虑，最好只给DAO或者Service调用，而不要用packcode,backingBean,或者BO调。
DAO，数据访问层，把VO，backingBean中的对象可以放入。。。。
DTO，很少用，基本放入到DAO中，只是起到过渡的作用。
QO，是把一些与持久性查询操作与语句放入。。
VO，V层中用到的基本元素与方法等放其中。如果要其调用BO，则要做BO转换VO，VO转换BO操作。VO的好处是其页面的元素属性多于BO，可起到很好的作用。。。。
—————————————–
楼上的不对吧，PO是持久化对象。BO＝business object—业务对象。
PO可以严格对应数据库表，一张表对映一个PO。
BO则是业务逻辑处理对象，我的理解是它装满了业务逻辑的处理，在业务逻辑复杂的应用中有用。
VO：value object值对象、view object视图对象
PO：持久对象
QO：查询对象
DAO：数据访问对象——同时还有DAO模式
DTO：数据传输对象——同时还有DTO模式

我始终认为，对一个初学者来说，IT界的技术风潮是不可追赶。我时常看见自己的DDMM们把课本扔了，去卖些价格不菲的诸如C#, VB.Net 这样的大部头，这让我感到非常痛心。而许多搞不清指针是咋回事的BBS站友眉飞色舞的讨论C#里面可以不用指针等等则让我觉得好笑。C#就象当年的ASP一样，“忽如一夜春风来，千树万树梨花开”，结果许多学校的信息学院成了“Web 学院”。96,97级的不少大学生都去做Web 了。当然我没有任何歧视某一行业的意识。我只是觉得如果他们把追赶这些时髦技术的时间多花一点在基础的课程上应该是可以走得更远的。
几个误区
初学者对C#风潮的追赶其实也只是学习过程中经常遇到的几个误区之一。我将用一些实际的例子来说明这些现象，你可以按部就班的看看自己是不是属于其中的一种或者几种：
认为计算机技术等于编程技术:
有些人即使没有这个想法，在潜意识中也有这样的冲动。让我奇怪的是，许多信息学院的学生也有这样的念头。认为计算机专业就是编程专业，与编程无关的，或者不太相关的课程他统统都不管，极端的学生只要书上没带“编程”两个字他就不看。其实编程只是计算机技术应用过程中一种复杂性最低的劳动，这就是为什么IT业最底层的人是程序员（CODER）。计算机技术包括了多媒体，计算机网络，人工智能，模式识别，管理信息系统等等这些方面。编程工作只是在这些具体技术在理论研究或者工程实践
的过程中表达算法的过程。编程的人不一定对计算机技术的了解就一定很高。而一个有趣的现象是，不少大师级的计算机技术研究者是不懂编程的。网上的炒作和现实中良好的工作待遇把编程这种劳动神秘化了。其实每一个程序员心里都明白，自己这些东西，学的时候并不比其它专业难，所以自然也不会高档到哪里去。
咬文嚼字的孔已己作风:
我见过一本女生的《计算机网络原理》教材，这个女生像小学生一样在书上划满了横杠杠，笔记做得满满的，打印出来一定比教材还厚。我不明白的是，像计算机网络原理这样的课程有必要做笔记？我们的应试教育的确害了不少学生，在上《原理》这一类课程的时候许多学生像学《马列原理》一样逐字背诵记忆。这乃是我见过的最愚蠢的行为。所谓《原理》，即是需要掌握它为什么这样做，学习why，而不是how（怎样做）。极端认真的学生背下以太网的网线最大长度，数据帧的长度，每个字段的意义，IP报头的格式等等，但是忘了路由的原则，忘了TCP/IP协议设计的宗旨。总之许多人花了大量的时间把书背得滚瓜烂熟却等于什么也没学。
在学习编程的时候这些学生也是这样，他们确切的记得C++语法的各个细节。看完了C++教程后看《Thinking in C++》（确实是好书），《Inside C++》，《C++ reference》，this C++, that C++……，然后是网上各种各样的关于C++语法的奇闻逸事，然后发现自己又忘了C++的一些语法，最后回头继续恶补…。有个师弟就跟我说：“C++ 太难了，学了这里忘了那里，学了继承忘了模板。”我的回答道：“你不去学就容易了”。我并没有教坏他，只是告诉他，死抠C++的语法就和孔已己炫耀茴香豆的茴字有几种写法一样毫无意义。你根本不需要对的C++语法太关心，动手编程就是了，有不记得的地方一查MSDN就立马搞定。我有个结论就是，实际的开发过程中对程序语法的了解是最微不足道的知识。这是为什么我在为同学用Basic（我以前从没有学过它）写一个小程序的时候，只花了半个小时看了看语法，然后再用半个小时完成了程序，而一个小时后我又完全忘记了Basic 的所有关键字。
不顾基础，盲目追赶时髦技术：终于点到题目上来了。大多数的人都希望自己的东西能够马上跑起来，变成钱。这种想法对一个已经进入职业领域的程序员或者项目经理来说是合理的，而且IT技术进步是如此的快，不跟进就是失业。但是对于初学者来说（尤其是时间充裕的大中专在校生），这种想法是另人费解的。一个并未进入到行业竞争中来的初学者最大的资本便是他有足够的时间沉下心来学习基础性的东西，学习why 而不是how。时髦的技术往往容易掌握，而且越来越容易掌握，这是商业利益的驱使，为了最大化的降低软件开发的成本。但在IT领域内的现实就是这样，越容易掌握的东西，学习的人越多，而且淘汰得越快。每一次新的技术出来，都有许多初学者跟进，这些初学者由于缺乏必要的基础而使得自己在跟进的过程中花费大量的时间，而等他学会了，这种技术也快淘汰了。基础的课程，比方数据结构，操作系统原理等等虽然不能让你立马就实现一个linux（这是许多人嘲笑理论课程无用的原因），但它们能够显著的减少你在学习新技术时学习曲线的坡度。而且对于许多关键的技术（比方Win32 SDK 程序的设计，DDK的编程）来说甚至是不可或缺的。
一个活生生的例子是我和我的一个同学，在大一时我还找不到开机按纽，他已经会写些简单的汇编程序了。我把大二的所有时间花在了汇编，计算机体系结构，数据结构，操作系统原理等等这些课程的学习上，而他则开始学习HTML和VB，并追赶ASP的潮流。大三的时候我开始学习Windows 操作系统原理，学习SDK编程，时间是漫长的，这时我才能够用VC开发出象模象样的应用程序。我曾一度因为同学的程序已经能够运行而自己还在学习如何创建对话框而懊恼不已，但临到毕业才发现自己的选择是何等的正确。和我谈判的公司开出的薪水是他的两倍还多。下面有一个不很恰当的比方：假设学习VB编程需要4个月，学习基础课程和VC的程序设计需要1年。那么如果你先学VB，再来学习后者，时间不会减少，还是1年，而反过来，如果先学习后者，再来学VB，也许你只需要1个星期就能学得非常熟练。
几个重要的基础课程
如果你是学生，或者如果你有充足的时间。我建议你仔细的掌握下面的知识。我的建议是针对那些希望在IT技术上有所成就的初学者。同时我还列出了一些书目，这些书应该都还可以在书店买到。说实在的，我在读其他人的文章时最大的心愿就是希望作者列出一个书单。
大学英语－不要觉得好笑。我极力推荐这门课程是因为没有专业文档的阅读能力是不可想象的。中文的翻译往往在猴年马月才会出来，而现在的许多出版社干脆就直接把E文印刷上去。学习的方法是强迫自己看原版的教材，开始会看不懂，用多了自然熟练。吃得苦下得狠心绝对是任何行业都需要的品质。计算机体系结构和汇编语言－关于体系结构的书遍地都是，而且也大同小异，倒是汇编有一本非常好的书《80×86汇编语言程序设计教程》（清华大学出版社，黑色封面，杨季文著）。你需要着重学习386后保护模式的程序设计。否则你在学习现代操作系统底层的一些东西的时候会觉得是在看天书。
计算机操作系统原理－我们的开发总是在特定的操作系统上进行，如果不是，只有一种可能：你在自己实现一个操作系统。无论如何，操作系统原理是必读的。这就象我们为一个芯片制作外围设备时，芯片基本的工作时序是必需了解的。这一类书也很多，我没有发现哪一本书非常出众。只是觉得在看完了这些书后如果有空就应该看看《Inside Windows 2000》(微软出版社，我看的是E文版的，中文的书名想必是Windows 2000 技术内幕之类吧)。
数据结构和算法－这门课程能够决定一个人程序设计水平的高低，是一门核心课程。我首选的是清华版的（朱战立，刘天时）。很多人喜欢买C++版的，但我觉得没有必要。C++的语法让算法实现过程变得复杂多了，而且许多老师喜欢用模块这一东西让算法变得更复杂。倒是在学完了C版的书以后再来浏览一下C++的版的书是最好的。
软件工程－这门课程是越到后来就越发现它的重要，虽然刚开始看时就象看马哲一样不知所云。我的建议是看《实用软件工程》（黄色，清华）。不要花太多的时间去记条条框框，看不懂就跳过去。在每次自己完成了一个软件设计任务（不管是练习还是工作）以后再来回顾回顾，每次都会有收获。
Windows 程序设计－《北京大学出版社，Petzold著》我建议任何企图设计Windows 程序的人在学习VC以前仔细的学完它。而且前面的那本《Inside Windows 2000》也最好放到这本书的后面读。在这本书中，没有C++，没有GUI，没有控件。有的就是如何用原始的C语言来完成Windows 程序设计。在学完了它以后，你才会发现VC其实是很容易学的。千万不要在没有看完这本书以前提前学习VC，你最好碰都不要碰。我知道的许多名校甚至都已经用它作为教材进行授课。可见其重要。上面的几门课程我认为是必学的重要课程（如果你想做Windows 程序员）。
对于其它的课程有这样简单的选择方法：如果你是计算机系的，请学好你所有的专业基础课。如果不是，请参照计算机系的课程表。如果你发现自己看一本书时无法看下去了，请翻到书的最后，看看它的参考文献，找到它们并学习它们，再回头看这本书。如果一本书的书名中带有“原理”两个字，你一定不要去记忆它其中的细节，你应该以一天至少50页的速度掌握其要领。尽可能多的在计算机上实践一种理论或者算法。
你还可以在CSDN上阅读到许多书评。这些书评能够帮助你决定读什么样的书。
日三省乎己　　　　
每天读的书太多，容易让人迷失方向。一定要在每天晚上想想自己学了些什么，还有些什么相关的东西需要掌握，自己对什么最感兴趣，在一本书上花的时间太长还是不够等等。同时也应该多想想未来最有可能出现的应用，这样能够让你不是追赶技术潮流而是引领技术潮流。同时，努力使用现在已经掌握的技术和理论去制作具有一定新意的东西。坚持这样做能够让你真正成为一个软件“研发者”而不仅仅是一个CODER。
把最多的时间花在学习上
这是对初学者最后的忠告。把每个星期玩CS或者CS的时间压缩到最少，不玩它们是最好的。同时，如果你的ASP技术已经能够来钱，甚至有公司请你兼职的话，这就证明你的天分能够保证你在努力的学习之后取得更好的收益，你应该去做更复杂的东西。眼光放长远一些，这无论是对谁都是适用的。

OSGi(Open Service Gateway Initiative)技术是面向Java的动态模型系统。OSGi服务平台向Java提供服务，这些服务使Java成为软件集成和软件开发的首选环境。Java提供在多个平台支持产品的可移植性。OSGi技术提供允许应用程序使用精炼、可重用和可协作的组件构建的标准化原语。这些组件能够组装进一个应用和部署中。
OSGi亦称做Java语言的动态模块系统，它为模块化应用的开发定义了一个基础架构。OSGi容器已有多家开源实现，比如Knoflerfish、Equinox和Apache的Felix。您可以通过这些容器，把您的应用程序劈分为多个模块单元，这样，您就可以更容易地管理这些模块单元之间的交叉依赖关系。
OSGi规范和Servlet规范及EJB规范类似，该规范定义了两种对象，一是容器对外提供的服务对象，另一个是容器和您的应用程序之间必须遵守的契约，其中，服务对象是容器要实现的。您如果想要在OSGi平台上进行开发，首先，您必须要使用OSGi API来创建您的应用，然后将之部署到OSGi容器中。从开发者的角度看，OSGi具有以下优点：
a) 您可以在不重启容器的情况下，动态地安装、卸载、启动和停止您的应用程序中的不同模块；
b) 对于您应用程序中的某一特定模块，容器可以同时运行该模块的多个版本；
c) OSGi为开发嵌入式应用、移动应用、富互联网应用(RIA)提供了非常优秀的基础架构
如果说您使用Servlet容器开发您的网络应用，使用EJB容器开发交易式应用，您可能会问，为什么我们还需要另外的容器呢？对这个问题的简短回答是，OSIG容器是专门为开发复杂的Java应用准备的，在这些应用的开发过程中，您非常需要将这些应用分割为一个个的模块。在本系列以后的文章中，我将针对这个问题进行展开并深入回答。
1. OSGi在企业开发中的应用
OSGi联盟(OSGiAlliance)于1999年3月开始着手制定OSGi规范，其主要目的就是要制定一套开放式标准，以便向局域网及其中的设备提供可管理的服务；其基本思路是，一旦您在网络设备（如服务器和嵌入式设备）上使用了OSGi服务平台，您就可以在网络上的任何地方管理这些设备上运行的软件组件的生命周期，可以在后台对这些组件进行安装、升级或卸载，但不需要打断该设备的正常运行。
近年来，OSGi技术在嵌入式系统及网络设备市场得到广泛应用。现在，由于Eclipse的成功，OSGi在企业开发中逐渐成为切实可行的、较有价值的一种技术。
1.1. 业界对OSGi的支持逐渐上升
2003年，Eclipse开发团队开始想办法提高Eclipse工具集的模块化，以便让它成为更加动态的富客户端平台。Eclipse团队最终选中OSGi框架作为其组件的运行时模型，2004年6月发布的Eclipse3.0就是第一个基于OSGi平台的版本。现在几乎所有的企业应用服务器都支持OSGi，Spring也通过一个叫“OSGi服务平台上的Spring动态模型(亦称之为OSGiSpring)”的项目来支持OSGi。该项目提供OSGi基础架构，以便我们在Spring的企业开发中更容易使用OSGi。
2. 开放源码的OSGi容器
从企业开发者的角度看，OSGi容器的要求很低，您可以很容易地把它嵌入到企业应用中，比如我们在开发Web应用时，我们可以把这个Web应用分为多个模块，一个模块负责视图层，另一个模块负责DAO层，第三个模块负责数据访问层，如果我们使用OSGi容器来管理这些模块之间的交叉依赖，我们就可以在不用重启该Web应用的前提下，将DAO层从速度较慢的升级到速度较快的DAO。
只要您的应用和OSGi规范兼容，您的应用就应该可以运行在任何OSGi容器中，现在比较流行的开放源码的OSGi容器有以下三种:
a) Equinox容器是参照OSGi规范第4版实现的，它构成了Eclipse IDE的核心—模块化的Java运行时；它实现了OSGi规范4中规定的必须强制实现的功能，同时，它也实现了OSGi规范中大部分的可选功能；
b) Knoflerfish是OSGi规范第3版和第4版的开源实现，它实现了OSGi规范规定的必须实现的功能及部分可选功能；
c) Apache的Felix是Apache软件基金会实现的OSGi开源容器，至本文截稿时为止，该容器还没有和OSGi规范完全兼容。

“如果说淘宝以前是一家便利店，那么现在就是沃尔玛。”淘宝网系统架构师林昊常用“超市”来解释自己的工作，“如果把服务器类比成超市员工，那么淘宝网网站就是由1万多‘员工’组成的。”
　　林昊在淘宝网的花名叫毕玄。“这个名字出自黄易的武侠小说《大唐双龙传》中天下三大武学宗师之一的‘武尊’毕玄。取这个名字就是要像毕玄一样把自己掌握的高深技术展现给武林，让更多的人士了解我，了解淘宝。”林昊说。
　　相关资料显示，淘宝网已经成为一个“庞然大物”：2009年交易额达到2000亿元，占据当年国内社会零售总额近2%。权威机构Alexa发布的世界网站排名显示，淘宝网全球排名第20位，高于eBay、亚马逊等国际零售巨头；在中国则仅次于百度、腾讯、新浪与谷歌中国，位居第五。
　　淘宝网系统架构的发展趋势
　　和大多数工程师一样，林昊几乎不修边幅，以至于初次见面时记者无法将他本人与网上流传的照片对应起来。不过看上去他倒并不木讷，自始至终给人的印象都是阳光、开朗。
　　林昊说，2007年他到淘宝时正是淘宝网系统架构最艰难的时候，淘宝面临怎样把单系统向分布式系统转型的挑战。“如果系统不改造，按照当时的发展速度，淘宝网会在2008年完全死掉。”林昊解释说，业务量的增加迫使淘宝不断地增加服务器，但系统仍旧是一个，结果是系统越来越庞大，越来越不能满足业务量增长的需求，遭遇业务发展瓶颈。
　　此后，林昊开始了重新架构淘宝网系统的征程。“淘宝网采用分布式服务平台，将原有系统区隔成200个左右的小系统，通过分布式服务承担淘宝几乎所有Java远程调用的支撑及管理，并且将这一亚洲最大的Java系统调理顺当，逐步提高淘宝网的系统可用性、运行效率。”目前，淘宝网的系统架构已经走向正轨。
　　工程师对技术是敏感的，在谈及淘宝网系统架构水平在同行中的位置时，林昊想都没想就说在国内没有同行。但记者提及亚马逊与eBay时，他仔细想了一下说：“我们与亚马逊有较大的差距，但与eBay已经相当接近了。”
　　事实上，淘宝网从创立至今一直没有停止对领先者的追赶，从商业模式的颠覆到规模的赶超，技术跟进也越来越紧密。林昊表示，“分布式系统—自动化系统—智能化系统是互联网技术发展的常见模式，这其中涉及到非常多的技术，eBay的PPT确实让我们分享了很多这方面的技术。我觉得除了智能化以外，虚拟化或者云计算、节能技术也将成为互联网技术的重点。”
　　此外，在赶超领先者的同时，林昊也不忘学习领先者的做法。“淘宝已经把诸如eBay的优雅降级、Facebook的自愈系统等功能相继从概念转化为淘宝的特色功能，只要能让淘宝网系统架构更稳更快，就可以用于淘宝。”林昊说。
　　谈到工作中曾遇到哪些挑战时，林昊直言是“秒杀”。在他看来，这一网友热衷的抢拍游戏对于网站后台来说就是一个灾难，“瞬间增加的访问需求不亚于一次黑客攻击”。淘宝网在遭遇第一次“秒杀”时，其系统已到了崩溃的边缘。“不过，随着类似情况的频繁出现，我们已经制定了相应的策略，目前已经完全可以解决此类问题。”林昊表示。
　　工程师应该追求“巅峰体验”
　　正如毕玄所代表的武学宗师一样，技术高手对于技术的追求是无止境的，或者说是狂热的。林昊认为，工程师应该有追求“巅峰体验”的情结。
　　“很多人对技术的了解停留在理论上，因为平台是个更稀缺的资源。”林昊说，淘宝网最吸引他的就是能在这里处理业界最复杂的难题。
　　正如之前提到的，淘宝网已不仅仅是一个在线交易系统，而是融合交易、门户、社交网站等于一体的生活圈。
　　“很多架构师不知道如何应对大型、数据瞬间高发的场景，主要原因是没有这方面的实践机会，毕竟目前只有知名网站的后台系统才能获得这类难得的实践机会，通常在没有实践机会的情况下是很难完全理解这些技术的。互联网中的技术方案都是在多次血泪宕机下成长起来的。”林昊表示。
　　出于应对数据瞬间高发的压力与成本控制，淘宝网的中间件系统、文件储存系统、搜索、分布式框架、缓存系统都是自主开发的，这也给工程师带来许多机会，可以看到软件的源码，研究了解软件内部的工作过程和原理，对应用设计、开发、查错、优化都是非常有帮助的。
　　由于淘宝网系统架构的庞大与复杂，对于很多工程师来说，“看一看淘宝网的系统架构一直是我们的心愿”。
　　“我经历了淘宝网点击量从3亿猛增到10亿的过程，这段时间的技术挑战对我来说是最宝贵的，使我获得很多宝贵经验。”林昊说，能给你这种经历的公司在全球也是屈指可数，在中国就更少了。
　　无论如何，随着淘宝网发展的加速，其赶超eBay的趋势更加明显，对于工程师来说，这意味着再也不能简单地亦步亦趋。“淘宝网正在长大，更多的时候我们必须独立面对问题。”林昊语气里更多的是兴奋，“我们希望更多的同道能来到淘宝网，体验这种巅峰感觉。”

在经历了长达25年的统治地位后，关系型数据库正面临越来越火的“NoSQL”挑战，而挑战者是以Hadoop为代表的分布式计算开源架构。可以看到，越来越多的消息表明，不管NoSQL是被解释为“No SQL”还是“Not Only SQL”，如果你面临海量数据的挑战，那么你最应该选的海量数据架构是Hadoop。
但是Hadoop就能代表一切吗？答案显然是否定的，Hadoop的MapReduce在性能上的确是有局限性的：比如MapReduce没有索引，只有靠强大的运算能力来处理；此外，MapReduce本身存在一些lower-level实现的问题, 特别是skew和数据交换等等。
因此有些人开始回到关系型数据库上，因为相比较Hadoop的处理能力，一些SQL架构依然呈现数量级的优势。
也许，我们现在正处于一个新的“NoHadoop”时代，因为越来越多的企业开始认识到，海量数据处理仅有Hadoop是不够的。在他们看来，简单的批处理工具比如MapReduce和Hadoop恐怕并不足以应付将来更大的数据结构。诚然，大多数的比较复杂的海量数据处理我们也许能够用Hadoop就足以对付——也许更多的是一个无奈选择。它们可能涉及更复杂的连接，比如ACID需求、实时要求、超级计算的算法、图形计算、互动分析或者连续增量的需求等等。
事实上，Hadoop之所以受到越来越多的人欢迎，原因在于它对于海量数据的处理方式，而且，最重要的是，它是免费的。
但是随着对海量数据处理的应用程序性能需求不断增加，我们会发现，在很多领域，我们需要除了Hadoop以外的更多的海量数据处理方式。
那么，我们应该怎样看待下一代分布式计算架构呢？或者说，“NoHadoop”的架构应该是怎样的呢？从性能上而言，下一代的架构需要在MapReduce/Hadoop的基础上有10——10000倍的性能提高。
在每一种应用下，都有新一代的数据架构，可以提供所需的规模和效能。在未来的几年内，这些架构中的某些也许会成为主流。
1、SQL：数据库已经有了25年的发展历史。大量的创新正在围绕数据库技术，比如VoltDB、Clustrix等等（也许下一代产品不应该再称为数据库），但当你需要处理复杂的连接，或需要ACID需求时，数据库依然是你最好的选择。
应用场景：复杂的业务查询、在线交易处理。
2、Cloudscale：在海量数据上的实时分析，它打破了自由批量处理的限制。比如，当你打算分析一台百万次的服务器中发生的事件流，你需要一个真正的实时数据流体系结构。而Cloudscale架构提供的这种实时数据分析能力，比Hadoop的批处理系统快了近10000倍。
应用场景：商业算法，欺诈检测，手机广告、位置服务、市场情报。
3、MPI和BSP：相当多的超级计算机应用中，需要在海量数据上建立复杂的算法，为了实现规模效应，需要对处理器的直接访问调用以提高计算的速度。在并行计算中，MPI和BSP这些工具是进行高性能计算的必要。
应用场景：建模与仿真系统，流体动力学。
4、Pregel：当你需要分析一个复杂的社交网，或者是要分析网络的时候，面对的不是数据的问题，而是一个很大的图形。我们面临的现状是，大规模的动态图形正成为一些应用的关键。Google的Pregel结构采用了BSP模型，以便能够进行规模化、高效的图形计算。
应用场景：算法，算法的结构图，地理位置图，网络优化等
5、Dremel：这是一个需要与网络进行大规模交互的数据集。Google的Dremel的设计原理在于支持几秒内万亿行命令的执行，并提供即时查询。而它的查询执行并没有采用MapReduce 的功能。自从2006年以来Dremel诞生以来，已经有了成千上万的用户。
应用场景：数据搜索、客户支持、数据中心监控。
6、Percolator (Caffeine) ：如果需要对庞大的数据增量进行不断更新，你会发现，Percolator是一种很好的实现方式，这也是Google在新的索引系统上采用的架构，Google的即时搜索引擎Instant不能没有它。“由于索引内容可以逐步增加，采用以Percolator的Google Caffeine系统检索速度将百倍于之前采用Hadoop的分布式数据处理方式。”
应用场景：实时搜索
原文链接：http://www.sys-con.com/node/1573226
作者简介：Bill McColl：Cloudscale创始人和首席执行官，牛津大学计算科学系主任，负责并行计算研究中心。

Hadoop分布式文件系统：架构和设计要点
原文：http://hadoop.apache.org/core/docs/current/hdfs_design.html
一、前提和设计目标
1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。
2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。
3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。
4、 HDFS应用对文件要求的是write-one-read-many访问模型。一个文件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问 题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。
5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。
6、在异构的软硬件平台间的可移植性。
二、Namenode和Datanode
HDFS采用master/slave架构。一个HDFS集群是有一个Namenode和一定数目的Datanode组成。Namenode是一个中心服 务器，负责管理文件系统的namespace和客户端对文件的访问。Datanode在集群中一般是一个节点一个，负责管理节点上它们附带的存储。在内 部，一个文件其实分成一个或多个block，这些block存储在Datanode集合里。Namenode执行文件系统的namespace操作，例如 打开、关闭、重命名文件和目录，同时决定block到具体Datanode节点的映射。Datanode在Namenode的指挥下进行block的创 建、删除和复制。Namenode和Datanode都是设计成可以跑在普通的廉价的运行linux的机器上。HDFS采用java语言开发，因此可以部 署在很大范围的机器上。一个典型的部署场景是一台机器跑一个单独的Namenode节点，集群中的其他机器各跑一个Datanode实例。这个架构并不排 除一台机器上跑多个Datanode，不过这比较少见。

单一节点的Namenode大大简化了系统的架构。Namenode负责保管和管理所有的HDFS元数据，因而用户数据就不需要通过Namenode（也就是说文件数据的读写是直接在Datanode上）。
三、文件系统的namespace
HDFS支持传统的层次型文件组织，与大多数其他文件系统类似，用户可以创建目录，并在其间创建、删除、移动和重命名文件。HDFS不支持user quotas和访问权限，也不支持链接（link)，不过当前的架构并不排除实现这些特性。Namenode维护文件系统的namespace，任何对文 件系统namespace和文件属性的修改都将被Namenode记录下来。应用可以设置HDFS保存的文件的副本数目，文件副本的数目称为文件的 replication因子，这个信息也是由Namenode保存。
四、数据复制
HDFS被设计成在一个大集群中可以跨机器地可靠地存储海量的文件。它将每个文件存储成block序列，除了最后一个block，所有的block都是同 样的大小。文件的所有block为了容错都会被复制。每个文件的block大小和replication因子都是可配置的。Replication因子可 以在文件创建的时候配置，以后也可以改变。HDFS中的文件是write-one，并且严格要求在任何时候只有一个writer。Namenode全权管 理block的复制，它周期性地从集群中的每个Datanode接收心跳包和一个Blockreport。心跳包的接收表示该Datanode节点正常工 作，而Blockreport包括了该Datanode上所有的block组成的列表。

1、副本的存放，副本的存放是HDFS可靠性和性能的关键。HDFS采用一种称为rack-aware的策略来改进数据的可靠性、有效性和网络带宽的利 用。这个策略实现的短期目标是验证在生产环境下的表现，观察它的行为，构建测试和研究的基础，以便实现更先进的策略。庞大的HDFS实例一般运行在多个机 架的计算机形成的集群上，不同机架间的两台机器的通讯需要通过交换机，显然通常情况下，同一个机架内的两个节点间的带宽会比不同机架间的两台机器的带宽 大。
通过一个称为Rack Awareness的过程，Namenode决定了每个Datanode所属的rack id。一个简单但没有优化的策略就是将副本存放在单独的机架上。这样可以防止整个机架（非副本存放）失效的情况，并且允许读数据的时候可以从多个机架读 取。这个简单策略设置可以将副本分布在集群中，有利于组件失败情况下的负载均衡。但是，这个简单策略加大了写的代价，因为一个写操作需要传输block到 多个机架。
在大多数情况下，replication因子是3，HDFS的存放策略是将一个副本存放在本地机架上的节点，一个副本放在同一机架上的另一个节点，最后一 个副本放在不同机架上的一个节点。机架的错误远远比节点的错误少，这个策略不会影响到数据的可靠性和有效性。三分之一的副本在一个节点上，三分之二在一个 机架上，其他保存在剩下的机架中，这一策略改进了写的性能。
2、副本的选择，为了降低整体的带宽消耗和读延时，HDFS会尽量让reader读最近的副本。如果在reader的同一个机架上有一个副本，那么就读该副本。如果一个HDFS集群跨越多个数据中心，那么reader也将首先尝试读本地数据中心的副本。
3、SafeMode
Namenode启动后会进入一个称为SafeMode的特殊状态，处在这个状态的Namenode是不会进行数据块的复制的。Namenode从所有的 Datanode接收心跳包和Blockreport。Blockreport包括了某个Datanode所有的数据块列表。每个block都有指定的最 小数目的副本。当Namenode检测确认某个Datanode的数据块副本的最小数目，那么该Datanode就会被认为是安全的；如果一定百分比（这 个参数可配置）的数据块检测确认是安全的，那么Namenode将退出SafeMode状态，接下来它会确定还有哪些数据块的副本没有达到指定数目，并将 这些block复制到其他Datanode。
五、文件系统元数据的持久化
Namenode存储HDFS的元数据。对于任何对文件元数据产生修改的操作，Namenode都使用一个称为Editlog的事务日志记录下来。例如， 在HDFS中创建一个文件，Namenode就会在Editlog中插入一条记录来表示；同样，修改文件的replication因子也将往 Editlog插入一条记录。Namenode在本地OS的文件系统中存储这个Editlog。整个文件系统的namespace，包括block到文件 的映射、文件的属性，都存储在称为FsImage的文件中，这个文件也是放在Namenode所在系统的文件系统上。
Namenode在内存中保存着整个文件系统namespace和文件Blockmap的映像。这个关键的元数据设计得很紧凑，因而一个带有4G内存的 Namenode足够支撑海量的文件和目录。当Namenode启动时，它从硬盘中读取Editlog和FsImage，将所有Editlog中的事务作 用（apply)在内存中的FsImage ，并将这个新版本的FsImage从内存中flush到硬盘上,然后再truncate这个旧的Editlog，因为这个旧的Editlog的事务都已经 作用在FsImage上了。这个过程称为checkpoint。在当前实现中，checkpoint只发生在Namenode启动时，在不久的将来我们将 实现支持周期性的checkpoint。
Datanode并不知道关于文件的任何东西，除了将文件中的数据保存在本地的文件系统上。它把每个HDFS数据块存储在本地文件系统上隔离的文件中。 Datanode并不在同一个目录创建所有的文件，相反，它用启发式地方法来确定每个目录的最佳文件数目，并且在适当的时候创建子目录。在同一个目录创建 所有的文件不是最优的选择，因为本地文件系统可能无法高效地在单一目录中支持大量的文件。当一个Datanode启动时，它扫描本地文件系统，对这些本地 文件产生相应的一个所有HDFS数据块的列表，然后发送报告到Namenode，这个报告就是Blockreport。
六、通讯协议
所有的HDFS通讯协议都是构建在TCP/IP协议上。客户端通过一个可配置的端口连接到Namenode，通过ClientProtocol与 Namenode交互。而Datanode是使用DatanodeProtocol与Namenode交互。从ClientProtocol和 Datanodeprotocol抽象出一个远程调用(RPC），在设计上，Namenode不会主动发起RPC，而是是响应来自客户端和 Datanode 的RPC请求。
七、健壮性
HDFS的主要目标就是实现在失败情况下的数据存储可靠性。常见的三种失败：Namenode failures, Datanode failures和网络分割（network partitions)。
1、硬盘数据错误、心跳检测和重新复制
每个Datanode节点都向Namenode周期性地发送心跳包。网络切割可能导致一部分Datanode跟Namenode失去联系。 Namenode通过心跳包的缺失检测到这一情况，并将这些Datanode标记为dead，不会将新的IO请求发给它们。寄存在dead Datanode上的任何数据将不再有效。Datanode的死亡可能引起一些block的副本数目低于指定值，Namenode不断地跟踪需要复制的 block，在任何需要的情况下启动复制。在下列情况可能需要重新复制：某个Datanode节点失效，某个副本遭到损坏，Datanode上的硬盘错 误，或者文件的replication因子增大。
2、集群均衡
HDFS支持数据的均衡计划，如果某个Datanode节点上的空闲空间低于特定的临界点，那么就会启动一个计划自动地将数据从一个Datanode搬移 到空闲的Datanode。当对某个文件的请求突然增加，那么也可能启动一个计划创建该文件新的副本，并分布到集群中以满足应用的要求。这些均衡计划目前 还没有实现。
3、数据完整性
从某个Datanode获取的数据块有可能是损坏的，这个损坏可能是由于Datanode的存储设备错误、网络错误或者软件bug造成的。HDFS客户端 软件实现了HDFS文件内容的校验和。当某个客户端创建一个新的HDFS文件，会计算这个文件每个block的校验和，并作为一个单独的隐藏文件保存这些 校验和在同一个HDFS namespace下。当客户端检索文件内容，它会确认从Datanode获取的数据跟相应的校验和文件中的校验和是否匹配，如果不匹配，客户端可以选择 从其他Datanode获取该block的副本。
4、元数据磁盘错误
FsImage和Editlog是HDFS的核心数据结构。这些文件如果损坏了，整个HDFS实例都将失效。因而，Namenode可以配置成支持维护多 个FsImage和Editlog的拷贝。任何对FsImage或者Editlog的修改，都将同步到它们的副本上。这个同步操作可能会降低 Namenode每秒能支持处理的namespace事务。这个代价是可以接受的，因为HDFS是数据密集的，而非元数据密集。当Namenode重启的 时候，它总是选取最近的一致的FsImage和Editlog使用。
Namenode在HDFS是单点存在，如果Namenode所在的机器错误，手工的干预是必须的。目前，在另一台机器上重启因故障而停止服务的Namenode这个功能还没实现。
5、快照
快照支持某个时间的数据拷贝，当HDFS数据损坏的时候，可以恢复到过去一个已知正确的时间点。HDFS目前还不支持快照功能。
八、数据组织
1、数据块
兼容HDFS的应用都是处理大数据集合的。这些应用都是写数据一次，读却是一次到多次，并且读的速度要满足流式读。HDFS支持文件的write- once-read-many语义。一个典型的block大小是64MB，因而，文件总是按照64M切分成chunk，每个chunk存储于不同的 Datanode
2、步骤
某个客户端创建文件的请求其实并没有立即发给Namenode，事实上，HDFS客户端会将文件数据缓存到本地的一个临时文件。应用的写被透明地重定向到 这个临时文件。当这个临时文件累积的数据超过一个block的大小（默认64M)，客户端才会联系Namenode。Namenode将文件名插入文件系 统的层次结构中，并且分配一个数据块给它，然后返回Datanode的标识符和目标数据块给客户端。客户端将本地临时文件flush到指定的 Datanode上。当文件关闭时，在临时文件中剩余的没有flush的数据也会传输到指定的Datanode，然后客户端告诉Namenode文件已经 关闭。此时Namenode才将文件创建操作提交到持久存储。如果Namenode在文件关闭前挂了，该文件将丢失。
上述方法是对通过对HDFS上运行的目标应用认真考虑的结果。如果不采用客户端缓存，由于网络速度和网络堵塞会对吞估量造成比较大的影响。
3、流水线复制
当某个客户端向HDFS文件写数据的时候，一开始是写入本地临时文件，假设该文件的replication因子设置为3，那么客户端会从Namenode 获取一张Datanode列表来存放副本。然后客户端开始向第一个Datanode传输数据，第一个Datanode一小部分一小部分（4kb)地接收数 据，将每个部分写入本地仓库，并且同时传输该部分到第二个Datanode节点。第二个Datanode也是这样，边收边传，一小部分一小部分地收，存储 在本地仓库，同时传给第三个Datanode，第三个Datanode就仅仅是接收并存储了。这就是流水线式的复制。
九、可访问性
HDFS给应用提供了多种访问方式，可以通过DFSShell通过命令行与HDFS数据进行交互，可以通过java API调用，也可以通过C语言的封装API访问，并且提供了浏览器访问的方式。正在开发通过WebDav协议访问的方式。具体使用参考文档。
十、空间的回收
1、文件的删除和恢复
用户或者应用删除某个文件，这个文件并没有立刻从HDFS中删除。相反，HDFS将这个文件重命名，并转移到/trash目录。当文件还在/trash目 录时，该文件可以被迅速地恢复。文件在/trash中保存的时间是可配置的，当超过这个时间，Namenode就会将该文件从namespace中删除。 文件的删除，也将释放关联该文件的数据块。注意到，在文件被用户删除和HDFS空闲空间的增加之间会有一个等待时间延迟。
当被删除的文件还保留在/trash目录中的时候，如果用户想恢复这个文件，可以检索浏览/trash目录并检索该文件。/trash目录仅仅保存被删除 文件的最近一次拷贝。/trash目录与其他文件目录没有什么不同，除了一点：HDFS在该目录上应用了一个特殊的策略来自动删除文件，目前的默认策略是 删除保留超过6小时的文件，这个策略以后会定义成可配置的接口。
2、Replication因子的减小
当某个文件的replication因子减小，Namenode会选择要删除的过剩的副本。下次心跳检测就将该信息传递给Datanode， Datanode就会移除相应的block并释放空间，同样，在调用setReplication方法和集群中的空闲空间增加之间会有一个时间延迟。
参考资料：
HDFS Java API: http://hadoop.apache.org/core/docs/current/api/
HDFS source code: http://hadoop.apache.org/core/version_control.html

目的

先决条件

下载

运行Hadoop集群的准备工作

单机模式的操作方法

伪分布式模式的操作方法

完全分布式模式的操作方法

Hadoop集群搭建–Hadoop安装

目的

先决条件

安装

配置

Hadoop的机架感知

启动Hadoop

停止Hadoop