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