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只是一个停止维护的阉割版。