BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

当当网开源Dubbox,扩展Dubbo服务框架支持REST风格远程调用

| 作者 沈理 关注 1 他的粉丝 发布于 2014年10月23日. 估计阅读时间: 5 分钟 | 都知道硅谷人工智能做的好,你知道 硅谷的运维技术 也值得参考吗?QCon上海带你探索其中的奥义

当当网近日开源了Dubbox项目,可为Dubbo服务框架提供多项扩展功能,包括REST风格远程调用、Kryo/FST序列化等等。

当当网架构部和技术委员会架构师沈理向InfoQ中文站介绍了Dubbox项目,开发背景和主要特点描述如下:

Dubbo是一个被国内很多互联网公司广泛使用的开源分布式服务框架,即使从国际视野来看应该也是一个非常全面的SOA基础框架。作为一个重要的技术研究课题,在当当网我们根据自身的需求,为Dubbo实现了一些新的功能,并将其命名为Dubbox(即Dubbo eXtensions)。

主要的新功能包括:

  • 支持REST风格远程调用(HTTP + JSON/XML):基于非常成熟的JBoss RestEasy框架,在dubbo中实现了REST风格(HTTP + JSON/XML)的远程调用,以显著简化企业内部的跨语言交互,同时显著简化企业对外的Open API、无线API甚至AJAX服务端等等的开发。事实上,这个REST调用也使得Dubbo可以对当今特别流行的“微服务”架构提供基础性支持。 另外,REST调用也达到了比较高的性能,在基准测试下,HTTP + JSON与Dubbo 2.x默认的RPC协议(即TCP + Hessian2二进制序列化)之间只有1.5倍左右的差距,详见下文的基准测试报告。

  • 支持基于Kryo和FST的Java高效序列化实现:基于当今比较知名的KryoFST高性能序列化库,为Dubbo 默认的RPC协议添加新的序列化实现,并优化调整了其序列化体系,比较显著的提高了Dubbo RPC的性能,详见下图和文档中的基准测试报告。

  • 支持基于嵌入式Tomcat的HTTP remoting体系:基于嵌入式tomcat实现dubbo的HTTP remoting体系(即dubbo-remoting-http),用以逐步取代Dubbo中旧版本的嵌入式Jetty,可以显著的提高REST等的远程调用性能,并将Servlet API的支持从2.5升级到3.1。(注:除了REST,dubbo中的WebServices、Hessian、HTTP Invoker等协议都基于这个HTTP remoting体系)。

  • 升级Spring:将dubbo中Spring由2.x升级到目前最常用的3.x版本,减少项目中版本冲突带来的麻烦。

  • 升级ZooKeeper客户端:将dubbo中的zookeeper客户端升级到最新的版本,以修正老版本中包含的bug。

上面很多功能已在当当网内部稳定的使用,现在开源出来,供大家参考和指正。也希望感兴趣的朋友也来为Dubbo贡献更多的改进。

注:dubbox和dubbo 2.x是兼容的,没有改变dubbo的任何已有的功能和配置方式(除了升级了Spring之类的版本)。另外,dubbox也严格遵循了Apache 2.0许可证的要求。

附:分布式服务框架与RPC框架

目前开源领域能找到的分布式服务框架也有不少,比较有代表性的包括Twitter的Finagle(基于Scala语言),Flipkart(印度最大的B2C网站)的Phantom(文档较少),Apache的Tuscany(有点陈旧,而且不是很适合互联网公司)等等,其实国内也有少数公司提供了开源Java服务框架,但dubbo在其功能完善性、架构优雅性、使用简便性等方面依然有其相对独特的优势,尽管dubbo绝大部分的开发都是2012年以前完成的。

另外,业界的开源RPC框架更是数量众多,难以计数,但是,一般的RPC框架和我们讨论的分布式服务框架还是具有相当大的距离,比如在远程调用的多协议、多序列化支持,完善的服务治理等等方面都有较多的缺失。也正是由于这种缺失,著名的Apache Thrift等框架在这里也可归为RPC框架,而主要构建在Thrift之上的Finagle、Phantom等框架更接近于完整的分布式服务框架(当然,Dubbo其实也支持Thrift,只是还不太完善)。

有关沈理

沈理,目前在当当网的架构部和技术委员会担任架构师,主要负责当当网的SOA实施(即服务化)以及分布式服务框架的开发。以前也有在BEA、Oracle、Redhat等外企的长期工作经历,从事过多个不同SOA相关框架和容器的开发。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

支持 by 张 亮

Dubbo确实是个好东西,但是已经有段时间没更新了。希望这个项目能继续把Dubbo做的更好

Dubbo是个不错的框架,总算后继有人了 by Z YW

国内的开源还是不成规模,用国内的开源产品就怕过两天没人管了!

两个提议 by Kimm King

nice job
1、新增特性都不影响原有功能,建议PR
2、开源协议建议对商业使用友好

Re: 支持 by 沈 理

多谢哈!

Re: 两个提议 by 沈 理

谢谢,不过不知什么是PR呢?现在国内公司开源多数都是用的apache许可证,对商业应该是极为友好了

Re: Dubbo是个不错的框架,总算后继有人了 by 沈 理

我个人感觉对开源来说最持久的是依赖于社区的力量,或者说国外那种发达的NGO,即使强大还“不作恶”的如google,说关闭就真的关闭多少线上服务,reader、notebook、wave、igoogle……毕竟,对一个人和商业公司来说,做一件好事不难,难的是一直做好事

其实一个优秀的开源项目应该是可以接力改进的,比如mysql被收购了,未来存在风险,开源社区为了延续mysql,就分支开发出MariaDB等等

另外,我个人对任何开源都心怀感激和敬意,因为即使你不用别人的东西,至少也可以参考别人的思路和成果,开放代码(以及文档)的最低的价值一般也不会少于发布一篇同样的论文吧。

Re: 支持 by 沈 理

多谢哈!

支持 & 感谢 by hao cen

Dubbo 支持REST 确实是个让人振奋的消息,目前的REST 是基于 JAX-RS,如果能支持Spring mvc 那就更好了,之前有研究过一下,但在REST的支持不是很好,另外如果想在Open Api 及 对外使用Dubbo 后面要走的路还有很多,例如鉴权这块,之前Dubbo的鉴权做的比较鸡肋,期待后面的更新与讨论

Re: 支持 & 感谢 by 沈 理

谢谢,对于jax-rs和spring mvc,其实我对spring mvc的rest支持还没有太深入的看过,说点初步想法,请大家指正:

spring mvc也支持annotation的配置,其实和jax-rs看起来是非常非常类似的。

我个人认为spring mvc相对更适合于面向web应用的restful服务,比如被AJAX调用,也可能输出HTML之类的,应用中还有页面跳转流程之类,spring mvc既可以做好正常的web页面请求也可以同时处理rest请求。但总的来说这个restful服务是在展现层或者叫web层之类实现的

而jax-rs相对更适合纯粹的服务化应用,也就是传统Java EE中所说的中间层服务,比如它可以把传统的EJB发布成restful服务。在spring应用中,也就把spring中充当service之类的bean直接发布成restful服务。总的来说这个restful服务是在业务、应用层或者facade层。而MVC层次和概念在这种做比如(后台)服务化的应用中通常是没有多大价值的。

当然jax-rs的有些实现比如jersey,也试图提供mvc支持,以更好的适应上面所说的web应用,但应该是不如spring mvc。

在dubbo应用中,我想很多人都比较喜欢直接将一个本地的spring service bean(或者叫manager之类的)完全透明的发布成远程服务,则这里用JAX-RS是更自然更直接的,不必额外的引入MVC概念。当然,先不讨论透明发布远程服务是不是最佳实践,要不要添加facade之类。

当然,我知道在dubbo不支持rest的情况下,很多朋友采用的架构是spring mvc restful调用dubbo (spring) service来发布restful服务的。这种方式我觉得也非常好,只是如果不修改spring mvc并将其与dubbo深度集成,restful服务不能像dubbo中的其他远程调用协议比如webservices、dubbo rpc、hessian等等那样,享受诸多高级的服务治理的功能,比如:注册到dubbo的服务注册中心,通过dubbo监控中心监控其调用次数、TPS、响应时间之类,通过dubbo的统一的配置方式控制其比如线程池大小、最大连接数等等,通过dubbo统一方式做服务流量控制、权限控制、频次控制。另外spring mvc仅仅负责服务端,而在消费端,通常是用spring restTemplate,如果restTemplate不和dubbo集成,有可能像dubbo服务客户端那样自动或者人工干预做服务降级。如果服务端消费端都是dubbo系统,通过spring的rest交互,如果spring rest不深度整合dubbo,则不能用dubbo统一的路由分流等功能。

当然,其实我个人认为这些东西不必要非此即彼的。我听说spring创始人rod johnson总是爱说一句话,the customer is always right,其实与其非要探讨哪种方式更好,不如同时支持两种方式就是了,所以原来在文档中也写过计划支持spring rest annoation,只是不知道具体可行性有多高。

Re: 支持 & 感谢 by 沈 理

另外,真的要直接支持open api,要做的工作还有很多,除了授权,还有各种频次、流量控制等等。但是,由于dubbo自身可以通过filter扩展功能,而rest中也支持interceptor、filter等概念,有些东西即使底层框架没有提供完全支持,我猜想自己好像也是可以做应用级实现的。

Re: Dubbo是个不错的框架,总算后继有人了 by 预 流

同意

感觉找到了组织,我们也修复了几个bug,也准备拉分支来搞 by 邱 波

我空了把一些东东提交上来.

令人振奋 by chenl ray

这就是开源的力量。

赞当当! by deng nickey

能够继续维护dubbo! dubbo整体框架不错, 可以做持续升级真是很好!

Re: 感觉找到了组织,我们也修复了几个bug,也准备拉分支来搞 by 沈 理

如果有机会合作最好了

Re: 支持 & 感谢 by 易 海军

准备什么时候提交到maven中央仓库吗?目前在search.maven.org/#search在看不到你们的成果呢

Re: 支持 & 感谢 by 沈 理

谢谢,暂时可能还不想走得太快吧,先避免造成一定的误会

如果对dubbox的功能感兴趣,目前直接安装到私有或者本地maven库即可

Re: 两个提议 by Kimm King

PR=Pull Request

dangdangdotcom.github.io/dubbox/rest.html
版权:Creative Commons 3.0许可证 署名-非商业性使用-禁止演绎
这是说的是文档还是dubbox?

Re: 两个提议 by 沈 理

多年没做过开源,落伍了哈

我个人对PR完全赞同,而且长远来讲很有意义,稍后也是可以尝试的(但能否成行就不完全取决于我们了)。只是以现在dubbo的状态,似乎暂时还没有太大意义,另外也会给各方面都带来一些麻烦(以及工作量)

我觉得各个公司不管大小,如果有开放的胸襟,适当进行一些基础性项目和软件的协作,不管是对于每个公司研发成本的降低、影响力的扩大,还是项目或者软件的持久维护、改进,甚至良性开源社区的形成,并推动国家软件行业的整体进步,都是极有帮助。

这一点我觉得在国外做得非常好,比如我亲自见证过在Apache Tuscany项目,IBM、BEA、IONA等等多个公司,甚至加上独立开发者,一起长期协作,推动了SOA基础框架的迅速发展,而且扩展性极高,功能覆盖面极广,虽然这些公司在体量上各自差距悬殊。当然,可能多个公司和个人的合作难免也会有矛盾冲突,甚至主导权、方向之争等等,但我觉得这在国外多数开源项目的合作中不是不可解决的问题,否则难以想象linux内核之类连续发展了这么多年。

Re: 两个提议 by 沈 理

creative commons是指文档版权,稍后去修改文档再写得更清楚一点。这是模仿spring的做法,项目是apache 2.0许可证,但在文档上单独标识一个非常利于共享转载的版权声明。

如果代码居然是creative commons许可证的署名-非商业性使用-禁止演绎,那开源项目就真成了发论文了,呵呵

欣慰 by 林锋 李

Dubbo在互联网企业的应用还是比较广泛的,在阿里不继续发展Dubbo的情况下,当当率先将自己的扩展开源出来,值得称赞!

Re: 欣慰 by 沈 理

谢谢,我们也了解到国内用dubbo公司确实比较多。我们做的扩展确实还很有限,只当是抛砖引玉啊!期待更多朋友未来为类似这种基础性软件添砖加瓦

Re: 欣慰 by Xuan Yang

将spring版本升级,引入Kryo,restFul
这几个扩展还是比较实在的功能

请教多语言问题 by z zz

请问,服务的多语言支持一般是怎么做的?是通过rest方式还是多语言客户端方式?
另外,rest的服务,是不是实现service就要按照JAX-RS 2.0方式来开发,而不是dubbo那样只依赖接口实现的方式

Re: 请教多语言问题 by 沈 理

要支持服务的多语言,最好的方式可能还是开发每种语言的框架实现(或者叫客户端),就像Tuscany等等一样,只是工作量巨大

通过REST,确实可以解决很多场景下的跨语言调用问题,只是还要结合一些现成的*服务器端*的负载均衡机制等等,比如haproxy、lvs等等(而dubbo里面是在*客户端*做的负载均衡、failover等等)。当然flipkart的phantom框架也提供了java实现的服务器端proxy,基于这种方式应该还可以实现更多有价值的功能。相比于上面开发各种语言的专门客户端,比如有一些高级的服务治理功能在这里可能比较难实现。

Re: 请教多语言问题 by 沈 理

REST要annotation是因为它必须配置http endpoint等的信息,这些信息是不可能由java接口直接描述的,而用xml描述又显得很麻烦。

其实dubbo rpc中很多方法级别的配置可能也是用annotation来做更好,可能比<dubbo:method/>更可维护。

Re: 请教多语言问题 by z zz

多谢回复~
那要用一个框架,既能实现java的基于接口类的方式开发,简化server端的开发,又有多语言的需求,只能是开发多语言客户端了?
而且,还不能简单用java的接口,必须要用protobuf这类的idl才行吧?不然其他语言无法得到正确的接口描述

Re: 请教多语言问题 by 沈 理

其实我觉得java接口+REST就是一种既简化开发,又一定程度满足跨语言的方式。

多语言客户端确实可能需要IDL或者像WSDL之类来定义中立的接口

Re: 请教多语言问题 by z zz

没有太细研究Dubbox,Dubbox提供的REST,可以使同一份代码既支持Java接口调用,又同时支持REST调用吗?

Re: 请教多语言问题 by 沈 理

是的,一般只要添加JAX-RS annotation即可

运行的时候遇到了一点问题 by Lai Mead

github.com/dangdangdotcom/dubbox/issues/20
是不是xsd太旧了啊?
demo没有跑起来.

有个问题 by fc xzhang

能支持分布式事物吗?

有个问题 by fc xzhang

能支持分布式事物吗?

有个问题 by fc xzhang

能支持分布式事物吗?

有个问题 by fc xzhang

能支持分布式事物吗?

正是需要的 by peng chester

正是需要的

同一集群Rest负载均衡 by 徐 志刚

我在同一个集群A和B两台服务器上部署了相同的服务提供者,两个服务都注册在统一注册中心。注册中心的地址为“192.168.192.175:2181” ;rest的端口为“8888”;A的地址为“192.168.192.175”;B的地址为“192.168.192.176”。当我把A上的服务停了后,我通过“192.168.192.175:8888”地址就无法访问了(注:B上的服务也是注册到192.168.192.175:2181)。现在当A服务停了之后,我想通过访问A的端口继续访问该服务的话,该怎么实现?

Re: 欣慰 by chang jay

正在看你写的分布式服务框架,非常感谢分享你多年在分布式服务框架积累的经验

相同接口怎么区分不同的实现类 by ye tao

dubbo 服务提供者配置文件中相同接口怎么区分不同的实现类;消费者通过接口调用时又该怎么调用?

测试数据里面的复杂对象是多大呢? by Shen YaFei

测试数据里面的复杂对象是多大呢?

فروشگاه اینترنتی by baneh بانه

Thanks for your information. i am professionally www.baneh.com specialist. If you need any help then please contact me.

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

41 讨论

深度内容

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT