点击我的GIT

dubbo源码分析一:整体分析

本文作为dubbo源码分析的第一章,先从总体上来分析一下dubbo的代码架构、功能及优缺点,注意,本文只分析说明开源版本提供的代码及功能。

1.dubbo的代码架构: 

    spring适配层:常规的spring适配方法,内容包括使用dubbo.xsd文件来定义dubbo相关的元素及属性;DubboNamespaceHandler用来向spring容器注册dubbo的元素解析器;DubboBeanDefinitionParser用来解析具体的dubbo元素。

    应用协议层:关于thrift,dubbo并没有实现原生态的thrift协议,而是进行了相应的改造,并且thrift的版本是0.8的版本,不建议在生产中使用thrift协议;关于http协议,dubbo使用了spring框架的httpinvoker相关的类及协议,客户端可以脱离dubbo独立调用服务端;关于webservice协议,支持soap协议,客户端可以脱离dubbo独立调用服务端。

    注册中心:在实际的测试过程中,多播方式的注册中心不能有效地识别服务端、客户端已经掉线停服的情况,不建议在生产环境中使用。

 

2.dubbo在服务治理方面提供的功能

    负载均衡:dubbo是在服务端配置的负载均衡情况,通过注册中心将信息传递给消费者,消费者使用第一个服务器的负载均衡配置,负载均衡配置可以通过监控中心进行统一的更改。

    路由:通过本人对于源码的解读及相关的测试,dubbo应该是不支持跨数据中心的路由。

    限流:通过在consumer上添加限流过滤器来实现,没有在服务端做限流。

 

3.dubbo的优缺点

优点:

    a.支持多种应用协议,并且协议方便扩展,例如:如果之前采用了protocolbuffer协议+netty的方式,可以在dubbo的源码上增加适配处理即可

    b.支持多种底层tcp容器

    c.支持http、webservice这样的跨语言协议,对于其它语言的客户端可以在不访问注册中心的情况下,直接通过跨语言的协议来调用dubbo服务,当然这也失去了服务治理的意义

    d.支持多种注册中心,生产环境下,注册中心可以选择redis和zookeeper两种中的一种

    e.支持多种cluster的调用方式

    f.通过服务端和监控中心来控制负载均衡的方式

缺点:

    a.缺少其它语言的支持,对于多语言的应用场景,服务治理比较困难

    b.缺少跨数据中心的流量切换功能

    c.不能支持thrift的原生协议

    d.开源版本的服务治理功能还有待加强

    e.对于tcp长连接,没有采用连接池来处理

 

4.总结

    我听到很多的程序员说,我们要上服务治理,但是各位在选择服务治理框架的过程中,还是要切实的注意以下几点:

    a.务必对于现有的服务改动最小,毕竟老板雇佣我们来工作,不是让我们玩各种技术的,最小的投入最大的收获才是我们想要看到的结果,当然系统已经确定重构不在此范畴

    b.dubbo不能解决因为代码设计和实现的bug,反而有可能因为引入了我们不熟悉的框架,使得各种异常情况出现,解决生产问题,还是要靠内功

    c.对于多语言的情况下,dubbo和motan等服务治理框架并不合适,虽说dubbo可以支持一些标准化的协议(http、webservice等),但是对于非java语言的consumer并不在服务治理的管理范围内,也就失去了服务治理的意义

    d.如果选择了dubbo,务必做好深入理解代码的准备,一定有一些情况是需要我们通过改动源码来实现的,毕竟开源的dubbo只是一个停止维护的阉割版。

posted @ 2017-03-29 10:47  _1900  阅读(930)  评论(0编辑  收藏  举报