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 份虚拟节点,如果要修改,请配置 

你可能感兴趣的:(dubbo遇到的问题)