dubbo遇到的问题

最近做fastDFS项目，发现暴露出来的上传接口，不太适合传大文件，查Dubbo官方文档发现

下面是官方文档给出的解释

• 为什么不能传大包?

因 dubbo 协议默认采用单一长连接，如果每次请求的数据包大小为 500KByte，假设网络为千兆网卡 [3:1]，每条连接最大 7MByte(不同的环境可能不一样，供参考)，单个服务提供者的 TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的 TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。如果能接受，可以考虑使用，否则网络将成为瓶颈。

那么要如何上传大文件呢

非常简单，默认采用单一长连接，那么我们不用dubbo协议就可以了，据查阅，dubbo支持一下几种协议

• dubbo
• rmi
• http
• hessian
• rest
• webservice
• redis
• memcached
   

我们使用hessian和rmi协议都是可以的，这两个都是多个短连接的

或者也可以直接改为多连接，配置如下

• 或表示该服务使用独立两条长连接。

虽然dubbo官方推荐使用dubbo协议（性能更强大），但解决需求才是最重要的

 

另外开发时，开发环境和测试环境公用zookeeper时，会经常有连接的问题，有两个解决方案

1. 一个是通过版本号，将消费者和生产者版本号统一，即可

     2. 通过配置 服务时 用点对点连接

实际上，版本号还可以用来做版本升级

当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。

可以按照以下的步骤进行版本迁移：

1. 在低压力时间段，先升级一半提供者为新版本
2. 再将所有消费者升级为新版本
3. 然后将剩下的一半提供者升级为新版本

拓展

 Dubbo在安全机制方面是如何解决的：

通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者

dubbo通信协议dubbo协议为什么要消费者比提供者个数多：

因dubbo协议采用单一长连接，假设网络为千兆网卡(1024Mbit=128MByte)，

根据测试经验数据每条连接最多只能压满7MByte(不同的环境可能不一样，供参考)，理论上1个服务提供者需要20个服务消费者才能压满网卡。

为什么采用异步单一长连接：

因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如 Morgan 的提供者只有 6 台提供者，却有上百台消费者，每天有 1.5 亿次调用，如果采用常规的 hessian 服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步 IO，复用线程池，防止 C10K 问题。

负载均衡策略

Random LoadBalance

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

RoundRobin LoadBalance

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性 Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只对第一个参数 Hash，如果要修改，请配置 
• 缺省用 160 份虚拟节点，如果要修改，请配置