（计算机科学与技术专业论文）基于rest的服务器框架研究与实现.pdf

舢 0 凡。j 独创性( 或创新性) 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得的研究 成果。尽我所知，除了文中特别加以标注和致谢中所罗列的内容以外，论文中不 包含其他人已经发表或撰写过的研究成果，也不包含为获得北京邮电大学或其他 教育机构的学位或证书而使用过的材料。与我一同工作的同志对本研究所做的任 何贡献均已在论文中作了明确的说明并表示了谢意。 申请学位论文与资料若有不实之处， 本人签名：兰# l 童一 本人承担一切相关责任。 日期：垒监驾一一一 关于论文使用授权的说明 学位论文作者完全了解北京邮电大学有关保留和使用学位论文的规定，即： 研究生在校攻读学位期间论文工作的知识产权单位属北京邮电大学。学校有权保 留并向国家有关部门或机构送交论文的复印件和磁盘，允许学位论文被查阅和借 阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它 复制手段保存、汇编学位论文。( 保密的学位论文在解密后遵守此规定) 保密论文注释：本学位论文属于保密在一年解密后适用本授权书。非保密论 文注释：本学位论文不属于保密范围，适用本授权书。 本人签名： 导师签名：日期： ， o 厶 。“ 、 基于r e s t 的服务器框架研究与实现 摘要 服务器框架技术在现代计算机技术发展中起到了巨大的推动作 用。同时也先后出现了一系列优秀的服务器框架。但是目前流行的服 务器框架技术，或者庞大而复杂、学习成本高、不易扩展，或者功能 相对单一、功能扩展不足、不能满足敏捷开发的需要。 本文所研究和实现的服务器框架系统，主要是针对j a v a 服务器应 用系统的开发，采用组件技术和依赖注入模式，将轻量级容器、线程 池技术、声明式服务技术、异步通信技术等多种技术集成在一个基于 组件架构的服务器框架中。同时，本文在分析了r e s t 规范之后，提 出和实现了一套将r e s t 引擎技术与本文所研究和实现的服务器框架 相结合的开发技术。在文章的最后利用中国移动手机支付系统若干典 型业务来对r e s t 服务器框架进行功能性和非功能性的评测。 基于本文所提出的r e s t 服务器框架，业务开发人员可以迅速搭 建一套企业级应用服务，并可以十分方便地扩展新的应用场景，从而 极大地提高了系统的开发和维护效率。由于采用该服务器框架可以轻 松发布r e s t 式的w e b 服务，所以可以进一步将系统向s o a 架构的方 向进行深一步的拓展。 关键词：服务器框架r e s t 服务资源轻量级 血 少 ， c t h er e s e a r c ha n di m p l e m e n t a t i o no fs e r v e r f r a m e w o r kf o rr e s t a b s t r a c t s e r v e rf r a m e w o r kt e c h n o l o g yh a s p l a y e d a s i g n i f i c a n t r o l e i n p r o m o t i n gt h ed e v e l o p m e n to fm o d e mc o m p u t e rt e c h n o l o g y a tt h es a m e t i m e ，t h e r ea l s oh a v eb e e n as e r i e so fe x c e l l e n ts e r v e rf r a m e w o r k h o w e v e r , t h ep o p u l a rs e r v e rf r a m e w o r kt e c h n o l o g ya tp r e s e n ti se t h i e r l a r g e ，c o m p l e x ，h i g hl e a r n i n gc o s t s ，d i f f i c u l tt oe x p a n do rf u n c t i o ns i m p l e ， i n s u f f i c i e n te x t e n s i o n s ，d i s t a n c et om e e tt h en e e d so fa g i l ed e v e l o p m e n t t h i ss e r v e rf r a m e w o r k , w h i c hi sr e s e a r c h e da n di m p l e m e n t e di nt h i s t h e s i s ，i sa i m e da tt h ed e v e l o p m e n ttf o rj a v as e r v e ra p p l i c a t i o n s iu s e d e p e n d e n c yi n j e c t i o np a t t e r n ，l i g h t w e i g h tc o n t a i n e r s ，t h r e a dp o o l t e c h n o l o g y , t h e s t a t e m e n t - s e r v i c e t e c h n o l o g y a n d a s y n c h r o n o u s c o m m u n i c a t i o nt e c h n o l o g i e s t h e nim a k ea v a r i e t yo ft e c h n o l o g y i n t e g r a t i o ni n t oac o m p o n e n t b a s e da r c h i t e c t u r eo ft h es e r v e rf r a m e w o r k 三： a tt h es a m et i m e ，a f t e ra n a l y z i n gt h er e s ts p e c i f i c a t i o n ，t h i st h e s i sp u t s f o r w a r dad e v e l o p m e n tm o d e lt h a tc o m b i n e sr e s te n g i n ea n dt h i sn e w s e r v e rf r a m e w o r k a tt h ee n do ft h et h e s i s ，iu s es e v e r a lt y p i c a lc a s e s ， w h i c ha r ei nt h em o b i l ep a y m e n ts y s t e mo fc h i n am o b i l e ，f o rt h e e v a l u a t i o no ff u n c t i o n a la n dn o n f u n c t i o n a lo ft h en e wi 冱s ts e r v e r f r a m e w o r k b a s e do nt h er e s ts e r v e rf r a m e w o r k ，b u s i n e s s d e v e l o p e r s c a n q u i c k l yb u i l da ne n t e r p r i s ea p p l i c a t i o ns e r v i c e ，a n dt h e yc a ne x t e n dt h e a p p l i c a t i o no fn e ws c e n a r i o sc o n v e n i e n t l y s oi tc a ng r e a t l yi m p r o v et h e e f f i c i e n c yo ft h es y s t e md e v e l o p m e n ta n dm a i n t e n a n c e i ti sv e r ye a s yt o p u b l i s hr e s t f u lw e bs e r v i c e si ft h ed e v e l o p m e n tm o d e li su s e d t h e r e f o r e ， t h es y s t e mc a na l s oe x p a n df u r t h e ri nt h ed i r e c t i o no fs o a a r c h i t e c t u r e k e y w o r d s ：s e r v e r , f r a m e w o r k ，r e s t , s e r v i c e ，r e s o u r c e ，l i g h t w e i g h t o 1 1 服务器框架技术背景l 1 1 1 服务器框架的发展1 1 1 2 服务器框架的研究现状1 1 2r e s t 技术背景3 1 2 1r e s t 技术起源3 1 2 2r e s t 技术研究现状3 1 2 2 1r a i l s 3 1 2 2 2a x i s 2 4 1 2 2 3 其它r e s t f u l 框架5 1 3 论文主要工作5 第二章相关理论及规范6 2 1 服务器框架6 2 1 1 服务器框架定位6 2 1 2 服务器框架设计6 2 2r e s t 技术7 2 2 1r e s t 技术特点7 2 2 1 - l 资源定位8 2 2 1 2 基于现有标准8 2 2 1 3 资源多重表示9 2 2 1 4 无状态通信9 2 2 2r e s t 技术相关规范1 0 2 2 3r e s t 设计准则1 1 第三章r e s t 服务器框架设计1 3 3 1 框架架构基本思想1 3 3 1 1 基于组件的服务器框架1 3 3 1 2 基于m i n a 的网络开发模型1 4 3 1 3r e s t 引擎1 5 3 1 4r e s t 引擎与框架的结合1 5 3 2r e s t 服务器框架总体设计1 5 3 3 1 设计目标和原则1 5 3 3 2 依赖注入模式1 8 3 3 3 容器选择1 9 3 3 5 网络通信模型2 0 3 3 6 事件驱动模型2 3 3 3 7 网络通信协议实现2 5 3 3 8r e s t 资源动态性和抽象性2 8 3 3 9r e s t 资源分发3 1 3 3 1 0 数据访问层读写分离3 3 3 3 1 l 框架总体逻辑架构3 4 第四章r e s t 服务器框架组件设计和实现3 6 i v 4 1 基础服务组件3 6 4 1 1 基础组件定义及接口3 6 4 1 2 主服务器组件3 7 4 1 3 任务队列组件3 8 4 1 4 线程池组件4 1 4 1 5 线程组组件4 4 4 1 6 服务器组件包装器4 5 4 1 7 服务器组件创建器4 6 4 2 网络通信组件4 9 4 2 1m i n a 框架基本原理4 9 4 2 2 网络通信服务组件定义及接口5 0 4 2 3 网络事件处理服务组件5 2 4 2 4 网络通信协议服务组件5 4 4 2 5 网络通信报文处理服务组件5 5 4 3r e s t 服务组件5 5 4 3 1r e s t 资源配置文件5 5 4 3 2r e s t 请求分发组件5 7 4 3 3r e s t 资源处理抽象组件5 8 4 4 上下文组件5 9 4 5 其它公共组件6 0 第五章r e s t 服务器框架应用和评测6 1 5 1 背景和需求6 l 5 2 测试部署环境6 2 5 3 评测6 3 5 3 1 非功能性评测6 3 5 3 2 功能性评测6 4 5 3 3 总结6 5 第六章总结及展望6 6 6 1 定性分析6 6 6 2 比较和讨论6 6 6 3 问题和不足6 7 6 4 展望6 7 参考文献6 9 致谢”7 l 作者攻读学位期间发表的学术论文目录7 2 附录7 3 v 北京邮电人学顾 ：研究生学位论文 1 1 服务器框架技术背景 1 1 1 服务器框架的发展 第一章绪论 网络计算模式经历了从主机批处理方式、哑终端主机模式、网络文件服务器 方式和客户服务器模式，进入9 0 年代，技术、面向对象技术和分布式计算技术相 互融合，使浏览器服务器( b s ) 模式和分布式对象计算模式相继出现1 1 】。随着技术 的迅猛发展，计算机支持的工作正在转移到一个复杂的分布式异构环境中，这就 要求以高性能和可靠的方式获得一个或多个企业信息系统的安全和事务性接入。 此外，在这种环境中，异构系统的集成也成为技术发展和市场需求的必然结果， 系统的集成需要以高性能、安全和可靠的方式在所有涉及到的异构系统之间建立 桥梁。 为了解决上述问题，出现了一种新的技术服务器框架。服务器框架是传统 的客户服务器计算模式之后所出现的一种新的计算模式。它位于多层模式中的中 问层，支持多平台，提供业务逻辑的运行时环境，不同的服务器框架采用不同的 技术，其中，采用分布式服务对象和组件技术是一个发展趋势。本论文所作的研 究工作就是在这样的前提背景下，对目前服务器组件技术和分布式服务对象接 入技术的研究动态进行了分析，在此基础上设计和实现了一个基于分布式服务 对象技术和组件技术服务器框架。 1 1 2 服务器框架的研究现状 框架是构成一类特定软件可复用设计的一组相互协作的类1 2 】换言之，框架是 特定领域软件的半成品，是通过综合特定领域应用系统的结构以及需求的共性而 形成的。框架技术已经被证明是一种降低软件开发费用和提高软件开发质量的有 效手段之一，它的优势在于方法本身的模块化、复用性、可扩展性和反向控制。 一个好的框架可以被许多类似的应用系统所重用。服务器框架，旨在作为一个服 务器的实现模板，使得在开发具体系统时，程序员所做的工作只是在框架中填入 和系统相关的部分，从而降低开发成本，提高系统的可靠性。 虽然服务器框架应用系统和j 2 e e 应用系统【3 】有一定的重叠，但由于它们面向 不同的应用领域，两者在系统需求上很大的不同。 第1 页 北京邮电大学顾f ：研究生学位论文 服务器框架应用系统j 2 e e 应用系统 调用方式支持同步或异步调用，支持长连接或主要采用同步调用方式， 短连接，这是由具体业务需求来决定。例如r p c ，r m i ，数据库访 但从网络通信效率上来考虑，一般采问等等。 有异步通信的方式，例如短信服务器， s p id e r 服务器等等。 组件模型轻量级和细粒度的对象，例如p o j 0 或重量级和粗粒度的对象； j a v a b e a n l 4 1 。这些对象都只具有短暂的具有长期的和持续的生 生命周期，可以迅速的创建和销毁。命周期，而且一般需要保 存在数据库中。 事件细粒度和高频率的事件粗粒度和低频率的事件 事件源外部事件源，包括t c p 连接，t c p 报文，数据库服务器，后台系统 u d p 报文，j m s t 5 1 消息等。等其它系统。 内部事件源，包括定时触发器，任务 队列等。 事务轻量级事务数据库事务 计算模型主要涉及大量1 0 和内存操作，主要的主要涉及大量的数据库 输入和输出为资源调用，消息和事件操作 等 在服务器框架应用领域，比较成熟的应用框架是a p a c h e 下的a v a l o n 框架， a v a l o n 是面向组件的j a v a 服务器通用框架。有很多服务器软件就是基于此框架 开发出来的，例如t o m c a t 等。a v a l o n 框架的优势在于采用了很多先进的设计模 式，继承了软件框架技术的优点。但是a v a l o n 框架也存在一些不足哺1 ，最主要 的问题是框架复杂度过高，所提供的接口过于复杂，很难被用来研究和复用，因 为复杂性而导致学习成本过高等原因，致使很多企业放弃了对此框架的采用。其 次开源组织对此框架支持力度不够，限制了软件的灵活性。此外a v a l o n 框架对 流行的j a v a 技术所提供的支持不足，例如l o g g e r 接口，它是利用a v a l o nl o g k i t 框架进行日志实现的，而对现在比较流行的l 0 9 4 j 等日志机制的支持存在不足。 在组件框架方面，作为j 2 e e 的核心而设计的e j b 口1 是一个重量级组件模型。 虽然e j b 普及了很多有价值的思想，但由于其本身的复杂性和对业务组件的侵入 性，因为对于大多数新的应用来说，它不是最佳选择陋。1 们。 在性能方面，e j b 模型存在很多问题。一般远程接口应采用粗粒度接口，而 本地接口应采用细粒度接口1 。而e j b 模糊了这两者之间的差异，很容易被 滥用，从而导致很严重的性能问题。其重量级的“命名服务 ，也进一步加 剧了这个问题。 在声明式服务方面，e j b 以“a l l o r n o t h i n g ”的方式来提供服务。这使得 只有e j b 组件才能使用这种服务，而无法为所有轻量级对象提供同样的服务。 在侵入性方面，e j b 容器对于e j b 组件具有很强的侵入性。它采用服务查找 第2 页 北京邮电人学硕。l ：研究生学位论文 模式，而不是依赖注入模式，组件工作必须依赖于容器的查找服务器n 刳，而 组件的最终运行情况还依赖于是部署过程。 针对目前e j b 遇到的困境，一些j 2 e e 领域的实践都丌始反思，并提出一些 以轻量级架构为核心的“后e j b ”解决方案，考虑如何在享受e j b 好处的同时， 避免其缺陷，提高丌发效率。这些解决方案一些共同的特点：以轻量级容器为核 心，并提供a o p 机制用于容器的扩展，以代替大而全的重量级容器。目前，这些 解决方案大都应用在j 2 e e 领域，例如实现特定e j b 容器的j b o s s ，避免使用e j b 组件的s p r i n g 。 1 2r e s t 技术背景 1 2 1r e s t 技术起源 r e s t 是英文全称r e p r e s e n t a t i o n a ls t a t et r a n s f e r 的缩写，中文翻译为 “表述性状态转移”，这个术语是由r o yt h o m a sf i e l d i n g 博士在他的论文 a r c h i t e c t u r a ls t y l e sa n dt h ed e s i g no fn e t w o r k b a s e ds o f t w a r e a r c h i t e c t u r e s 中提出的n 引。r e s t 本身只是为分布式超媒体系统设计的一种架 构风格，而不是标准。现在基于w e b 的技术架构，实际上就是各种规范的集合， 这些规范共同组成了w e b 架构技术。例如广泛使用的h t t p 协议，客户端服务器 模式，这些都是规范。而每当我们在原有规范的基础上增加新的规范，就会形成 新的架构。而r e s t 正是这样一种架构，它结合了一系列的规范，从而形成了一 种新的基于w e b 的架构风格。r e s t 通过u r l 来进行w e b 服务的调用，最大限度 的减少了开发人员在学习众多规范和配置服务的工作量。 1 2 2r e s t 技术研究现状 r e s t 为我们构建下一代高性能、高可伸缩性、简单性、可移植性、可靠性 的w e b 程序提供了一个架构风格上的准则。w e b 是简单的，w e b 更是可编程的， r e s t 利用简单的h t t p 、u r i 标准和x m l 语言构建起轻量级的w e b 服务，从而大 幅度地提升了开发效率和程序性能。由于r e s t 设计哲学变得越来越流行，许多 r e s t f u l 框架如雨后春笋般涌现出来。 r u b yo nr a i l s n 钔是新兴的敏捷w e b 开发框架，在动态语言r u b y 的支持下， 第3 页 北京邮电人学硕 j 研究生学位论文 r a i l s 以新鲜的视角告诉我们w e b 开发是简单而快乐的。r a i l s 对r e s t f u lw e b s e r v i c e 的开发作了极大的封装和简化，这对开发人员来说是一个强大的工具。 r a i i s 将a c t i v e r e c o r dm o d e l n 朝抽象为资源，比如h t t p ：h o s t b o o k s 就是一 个b o o k s 资源抽象，而u r i 就是该资源的地址和唯一标识符。对该资源的c r u d 是利 用标准h t t p 协议中的g e t 、p o s t 、p u t 和d e l e t e 方法。h t t p 动词中的g e t 和p o s t 是 我们常用的，但是p u t 和d e l e t e 方法却很少见。由于目前流行的w e b 浏览器大多不 支持p u t 和d e l e t e 方法，所以r a i l s 采用一个虚拟的：m e t h o d 参数来模拟h t t p 中的 g e t 、p o s t 、p u t 、d e l e t e 方法n 射。 r a i l s 对r e s t 开发做出了最大的简化，r a i l s 即将发布的2 o 版本将全面基于 r e s t n6 1 。作为一个敏捷的w e b 开发框架，r a i l s 一直在不断突破传统的w e b 开发模 式、寻找w e b 开发领域的杀手级架构和框架，并在不断进步和发展中得到了大家 的认可。 a p a c h ea x i s 2u 7 。是传统的j a v aw e bs e r v i c e 框架a x i s 的下一代版本。从最初 的a p a c h ea x i s 并1 a p a c h es o a p 到目前的a x i s 2 ，经历了大量变革和发展。相对以 前的版本，a x i s 2 更灵活、更高效、更简单。作为j a v a 端官方和传统w e bs e r v i c e 框架，在r e s t 与s o a p 的硝烟弥漫、战火纷飞的状况下，a x i s 2 尝试同时支持s o a p 和r e s t ，采用了w s d l 2 o 中将r e s t 与w e b 服务结合的工作成果。 同样的商业逻辑，a x i s 2 同时提供w s - * 风格的接口和r e s t 风格的接口。除了 支持w s 一木规范外，a x i s 2 已经可以配置作为r e s t 容器来发送和接收r e s t f u lw e b s e r v i c e 请求和应答：这让a x i s 2 的灵活性、易用性、安全性和可靠性等都得到大 幅度地提升。在a x i s 2 里启用r e s t 风格的w e b 服务十分简单，首先修改服务器端的 a x i s 2 x m l 配置文件，将e n a b l e r e s t 参数的值设置为t r u e 。然后在a x i s 2 的客户端 的使用中，初始化一个o p t i o n s 对象，填入我们要访问的服务u r l 、设置传输协议 为h t t p 、设置打开对r e s t 支持等，然后将o p t i o n s 对象传递给一个c a l l 对象，最 后调用c a l l i n v o d e b l o c k i n g 方法，并在该访问的参数里指定调用的服务方法即 可。 a x i s 2 会同时作为s o a p 端点和r e s t 端点，在服务端可以同时发布这两种风格 的w e b n 臣务。在客户端，如果接收到的消息的c o n t e n t t y p e 为t e x t x m l ，并且没有 s o a p 相关的h e a d e r 的话，这个消息就会当作r e s t f u l 消息来处理，否则当作s o a p 消息来处理。 第4 页 北京邮电人学硕1 ：研究生学位论文 1 2 2 3 其它r e s t f u i 框架 除了r u b yo nr a i i s 和a x i s 2 ，还有一些框架也纷纷提供了对r e s t 的支持。 d j a n g o n 砌是基于p y t h o n 语言的敏捷w e b 和w e b 服务开发框架，它的设计与r a ii s 十 分类似，只不过简化和封装稍少一些。d j a n g o r e s t i n t e r f a c e 是g o o g l e c o d e 上 的一个开源项目，它给d j a n g o 的r e s t 开发接口提供了简便的封装。最重要的是 c o l l e c t i o n 类和x m l r e s p o n d e r 类，在u r l s p y 文件里使用c o l l e c t i o n 定义资源集 合以及使用x m l r e s p o n d e r 定义r e s p o n d e r ，并在u r l p a t t e r n s 中将该资源集合映射 到某一u r l ，则该资源就以r e s t 方式发布了w e b 服务，对该w e b 服务的实现细节如 h t t p 动词等都隐藏在c o ll e c t i o n 里。r e s t l e t n 钉是基于j a v a 的另一个轻量但健全 的r e s t f u l 框架，它的发展十分稳定，有一定的潜力。r e s t l e t 支持所有r e s t 概念 ( 资源、展示、连接器、组件等) ，支持阻塞和非阻塞( n i o ) 模式，支持l o g g i n g 、 a u t h e n t i c a t i o n 和c o o lu r i s 重写等。 r e s t 对于简化w e b 服务开发和消费的意义是重大的，许多大型网站已经开始 提供r e s t 服务，如a m a z o n 、e b a y 、y a h o o 和f 1 i c k r 。在关注c r u d 场景的、面向数 据的应用以及简单的、没有复杂安全要求的w e b n 艮务方面，使用r e s t 是明智的， 但是在需要事务、严密的安全性等高级应用方面，可能基于w s 一木的方案会更胜任。 1 3 论文主要工作 通过对服务器框架技术和r e s t 技术的研究，我设计和实现了一套高性能服 务器框架，并在这个服务器框架之上实现了对r e s t 的支持。该工作主要分为三 个部分，分别是服务器框架的研究与实现，r e s t 引擎的研究与实现和服务器框 架与r e s t 引擎的结合。 在基于r e s t 的服务器框架开发完成之后，我利用中国移动手机支付系统支 付管理子系统的若干典型业务来验证服务器框架的可用性和高性能，并在最后给 出了测试结果分析和结论。 第5 页 北京邮电人学硕1 ：研究生学位论义 2 1 服务器框架 2 1 1 服务器框架定位 第二章相关理论及规范 现在计算机分布式信息系统已经很少由开发人员从底层开始进行原始开发， 他们大都会采用一种或几种服务器框架作为底层支撑，在框架之上快速搭建系统 业务功能。确实，现在软件开发技术里流行的极限编程之类的新概念确实在很大 程度上依赖于服务器框架的实现。 服务器框架在软件系统分层模型中处理操作系统与业务系统之间，但它的作 用实际上会影响到整个软件系统，因为上层的业务系统从始至终都依赖于框架的 功能支持。一个软件系统如果只有服务器框架肯定是不能解决软件需求中的所有 问题。如果把一个软件系统分为通信，调度，业务和持久四个层次的话，那么服 务器框架就是用来解决通信和调度的问题，同时也可以为业务提供一些重要的支 2 1 2 服务器框架设计 图2 - 1 服务器框架定位 服务器框架有三个主要特点，分别是跨平台，高性能和多项服务整合嘲1 。框 第6 页 ， 北京邮l 乜人学硕i ：研究生学位论文 架必须能够运行在w i n d o w s 和l i n u x 平台上；网络通信模块需要使用各个操作系 统所提供的最高效的网络1 0 模型；此外，使用框架实现的服务器能够同时提供 多项整合的服务功能，比如同时提供h t t p 服务和f t p 服务。 跨平台的设计是服务器框架首先必须具备的功能。因为众所周知，很少有大 型服务会部署在w i n d o w s 平台上，而在开发阶段则大多数是在w i n d o w s 平台上进 行。所以如何做好服务器框架的可移植性是首先要考虑的问题。 网络通信模块的设计，最重要的一个原则是逻辑应用层与网络传输层分离。 这可以带来两个好处：首先，便于编程。逻辑应用层代码只用负责逻辑部分的问 题，不用考虑数据传输层的实现。同样，网络传输层的代码只用于负责具体网络 传输，不受上层任何功能的约束。许多事实证明当设计者专注于某一有限的领域 时，可以编出更加高效的代码。其次，便于模块的替换。因为层与层之间相对独 立，任何一层有所改动甚至被替换都不会影响到另一层的功能。一个比较典型的 例子就是：网络通信模块在w i n d o w s 平台下面使用的是i o c p 的机制，在l i n u x 下面使用的是e p o l l 机制，在平台迁移的过程中，可以用另一种机制被完全地替 换而不会影响到逻辑应用层一丝一毫的代码口卜捌。 整合服务的提供就像是o s i 七层模型幽3 中的应用层的作用，它能够利用下层 的功能向上提供多种服务。在这些服务的设计中，需要考虑到三个重要问题：首 先是服务种类的灵活变化。开发人员可以在不改变原有服务器框架的前提下，可 以通过简单的配置把新开发的服务加载到服务器框架上：其次是服务的高性能。 这个要求比像抽象，但是极其重要，试想一下一个只能处理l o 个请求的服务器 框架是没有谁会使用的。这个要求可以采用多项技术实现，例如c a c h e 技术，线 程池，队列调度算法等等；最后是服务的易用性。这个要求包括两方面的含义， 首先是业务开发人员在使用服务器框架时能够通过简单的声明式操作或是简单 的几行调用就可以使用服务，还有就是服务可以有多种发布方式，业务开发人员 可以任意选择自己喜欢的发布方式来开发服务。 2 2r e s t 技术 r e s t 架构风格是全新的针对w e b 应用的丌发风格，是当今世界最成功的互 联网超媒体分布式系统架构，它使得人们真正理解了h t t p 协议本来面貌。随着 r e s t 架构成为主流技术，一种全新的互联网网络应用开发的思维方式开始流行。 2 2 1r e s t 技术特点 r e s t 定义了如何正确地使用w e b 标准，例如h t t p 和u r i 。它包括以下四条 第7 页 北京邮l 乜人学硕l ：研究生学位论文 重要特点幽1 ： 2 2 1 1 资源定位 使用“资源”( r e s o u r c e ) 这个词是r e s t 的精髓所在，在r e s t 的世界里， 整个w e b 被看作一组资源的集合，而不是一张张的网页。要理解r e s t ，就必须 转变思维，不能还认为我们所看到的只一张张的网页，以维基百科为例，我查阅 的r e s t 词条事实上并不是一张网页，它是一个资源，我们使用 h t t p ：z h w i k i p e d i a o r g w i k i r e s t 访问这个资源，并取得了它的h t m l 表示， 之所以是h t m l ，是因为浏览器是这种方式。 然后我们思考一下人们构建的系统，通常每个事物都应该是可标识的，都可 以拥有唯一的i d ，而在w e b 中，代表i d 的统一概念就是：u r i 。u r i 构成了一个 全局命名空间，使用u r i 标识资源意味着它们获得了一个唯一、全局的i d 。而 r e s t 正是使用u r i 作为资源的i d ，从而达到了对资源进行唯一定位目的。 资源定位最好是依靠一个已被定义，在全球范围内几乎完美运行，并且能被 绝大多数人所理解的规则，而u r i 正是满足这种需要的规则。人们在平时的生活 中几乎每天都会使用u r i 去访问网络资源，这种概念是再熟悉不过了。就像亚马 逊在线商城中，用户使用u r i 就可定位每一个资源，查询和购买自己心仪的商品。 当面对这个原则时，许多人惊讶于这是否意味着需要直接向外界暴露数据库 记录相关信息呢，例如商品的i d ? 这个问题的提出是有道理的，因为多年以来 面向对象的实践告诫我们，将持久化的信息作为实现细节隐藏起来一种规范和安 全的做法。但是u r i 定位原则与隐藏实现细节两者之间并没有任何冲突。因为用 u r i 标识的资源要比数据库记录抽象的多。例如，一个定单资源可以由定单项、 地址以及许多其它方面共同组成，而后面这些才是需要进行隐藏的实现细节。通 过对资源进行定位，可以进一步引导人们创造出在传统的应用程序设计中不常见 的资源：一个话题、一次聚会等等，所有这些都是应该被定位资源的示例。 2 2 1 2 基于现有标准 r e s t 标准之所以吸引人，正是因为它的简单和易用性，而形成这个结果的 原因就在于r e s t 与h t t p 协议的紧密结合。r e s t 与h t t p 协议的关系可以用密不 可分来形容，有时候r e s t 也被称为r e s t h t t p ，可以看出h t t p 对于r e s t 标准 的支撑作用有多大。事实上确实如此，h t t p 几乎承载了r e s t 标准的全部内容。 可以这么说，如果了解了h t t p 协议就可开发r e s t f u l 的w e b 服务。 为使客户端程序和服务端程序能与你的资源相互协作，资源应该正确地实现 第8 页 北京邮电人学硕l ：研究生学位论文 应用协议h t t p ，除了两个大家熟知的g e t 和p o s t 方法之外，标准方法集合中还 包含p u t 、d e l e t e 、h e a d 和o p t i o n s 乜刚。这些方法的含义连同行为一起定义在h t t p 规范之中。如果你是一名面向对象开发人员，可能基于r e s t 开发的模式与传统 模式不太一样，可以想象r e s t 方案中的所有资源都必须实现下面这个接口： i n t e r f a c er e s o u r c e r e s o u r c e ( u r iu ) ： r e s p o n s eg e t 0 ： r e s p o n s ep o s t ( r e q u e s tr ) ： r e s p o n s ep u t ( r e q u e s tr ) ： r e s p o n s ed e l e t e0 ： 系统中的所有资源都必须按照这个接口进行开发。构造函数用来将u r i 与资 源进行绑定，从而达到资源定位的目的；g e t 方法用来提交对资源进行查询；p o s t 方法用来对资源的信息进行修改；p u t 用来增加新的资源；而d e l e t e 很明显则 是用来删除已经存在的资源。 2 2 1 3 资源多重表示 r e s t 所依赖的h t t p 协议还有一个优点就是客户端知道针对特定类型的数据 格式如何进行处理，这样的话客户端就可以与所有提供这种表达格式的资源进行 交互。在实际应用中，资源多重表述还有着其它重要的好处。如果r e s t 式的w e b 服务为资源提供h t m l 和x m l 两种表述方式，那这些资源不仅可以被你的应用所 用，还可以被任意标准w e b 浏览器所用，这时你的应用信息可以被所有会使用 w e b 的人获取到。 2 2 1 4 无状态通信 r e s t 包含无状态的概念，但并不是说r e s t 式的w e b 服务所暴露的功能应用 不能有状态。r e s t 要求状态要么被放入资源状态中，要么保存在客户端上。或 者换句话说，服务器端不能保持除了单次请求之外的，任何与其通信的客户端的 通信状态。这样做的最直接的理由就是可伸缩性。如果服务器需要保持客户端状 态，那么大量的客户端交互会严重影响服务器的内存可用空间。 除此以外，还有其它一些理由让r e s t 的无状态通信特点显得更为重要。无 状态通信使服务器的变化对客户端是不可见的，因为在两次连续的请求中，客户 端很可能并不依赖于同一台服务器。假设一个客户端从某台服务器上收到一份包 第9 页 北京邮电人学顾。l ：研究生学位论文 含链接的文档，在它做自己的一些业务处理时，原来的这台服务器停止服务，原 因可能是硬盘坏掉或是软件需要升级重启，而这时如果这个客户端访问了从这台 服务器接收到的链接，它肯定不会察觉到后台的服务器已经发生了变化。 2 2 2r e s t 技术相关规范 基于w e b 的架构，实际上就是各种规范的集合，这些规范共同组成了w e b 架构。比如h t t p 协议，比如客户端服务器模式，这些都是规范。每当我们在原 有规范的基础上增加新的规范，就会形成新的架构。而r e s t 正是这样一种架构， 他结合了一系列的规范，而形成了一种新的基于w e b 的架构风格。它包括了如下 一些规范： 客户一服务器。这种规范的提出，改善了用户接口跨多个平台的可移植性， 并且通过简化服务器组件，改善了系统的可伸缩性。最为关键的是通过分离 用户接口和数据存储这两个关注点，使得不同用户终端享受相同数据成为了 可能。 无状态性。无状态性是在客户- n 务器约束的基础上添加的又一层规范。他 要求通信必须在本质上是无状态的，即从客户到服务器的每个r e q u e s t 都必 须包含理解该r e q u e s t 所必须的所有信息。这个规范改善了系统的可见性( 无 状态性使得客户端和服务器端不必保存对方的详细信息，服务器只需要处理 当前r e q u e s t ，而不必了解所有的r e q u e s t 历史) ，可靠性( 无状态性减少了 服务器从局部错误中恢复的任务量) ，可伸缩性( 无状态性使得服务器端可 以很容易的释放资源，因为服务器端不必在多个r e q u e s t 中保存状态) 。同 时，这种规范的缺点也是显而易见得，由于不能将状态数据保存在服务器上 的共享上下文中，因此增加了在一系列r e q u e s t 中发送重复数据的开销，严 重的降低了效率。 缓存。为了改善无状态性带来的网络的低效性，我们填加了缓存约束。缓存 约束允许隐式或显式地标记一个r e s p o n s e 中的数据，这样就赋予了客户端 缓存r e s p o n s e 数据的功能，这样就可以为以后的r e q u e s t 共用缓存的数据， 部分或全部的消除一部分交互，增加了网络的效率。但是用于客户端缓存了 信息，也就同时增加了客户端与服务器数据不致的可能，从而降低了可靠 性。 统一接口。r e s t 架构风格的核心特征就是强调组件之间有一个统一的接口， 这表现在r e s t 世界里，网络上所有的事物都被抽象为资源，而r e s t 就是通 过通用的链接器接口对资源进行操作。这样设计的好处是保证系统提供的服 务都是解耦的，极大的简化了系统，从而改善了系统的交互性和可重用性。 第1 0 页 北京邮电人学硕l j 研究生学位论文 并且r e s t 针对w e b 的常见情况做了优化，使得r e s t 接口被设计为可以高效 的转移大粒度的超媒体数据。 分层系统。分层系统规则的加入提高了各种层次之间的独立性，为整个系统 的复杂性设置了