微服务的一些琐屑 Dubbo

ldy 3月前 ⋅ 49 阅读

微服务的一些琐屑 Dubbo

Dubbo 比 Spring Cloud 性能要高一些?

Dubbo 是一个分布式服务框架,致力于提供高性能和透明化的 RPC 远程服务调用方案,以及 SOA 服务治理方案。简单的说,Dubbo 就是个服务框架,说白了就是个远程服务调用的分布式框架

远程调用需要需要考虑系统的IO模型,Java传统的IO模型是同步阻塞的。一次请求对应一个线程去处理,如果请求过多线程池里的线程不够,大量的请求只能排队等待。而NIO是异步非阻塞(Node运行环境也是采用这种IO模型,虽然Node是单线程,但是非阻塞确实能很好应对性能问题),NIO是可以做到用一个线程来处理多个操作的。假设有10000个请求过来,根据实际情况,可以分配50或者100个线程来处理。不像之前的阻塞IO那样,非得分配10000个。

因为 Dubbo 采用单一长连接和 NIO 异步通讯(保持连接/轮询处理),使用自定义报文的 TCP 协议,并且序列化使用定制 Hessian2 框架,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况,但不适用于传输大数据的服务调用。而 Spring Cloud 直接使用 HTTP 协议(但也不是强绑定,也可以使用 RPC 库,或者采用 HTTP 2.0 + 长链接方式(Fegin 可以灵活设置))。

Dubbo的结构与流程

模块注解:
  • Provider: 暴露服务的服务提供方
  • Consumer: 调用远程服务的服务消费方
  • Registry: 服务注册与发现的注册中心
  • Monitor: 统计服务的调用次调和调用时间的监控中心
  • Container: 服务运行容器
注册中心:

注册中心可以说是微服务架构中的”通讯录“,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址,进行调用。

了解了什么是注册中心,那么我们继续谈谈,为什么需要注册中心。

在分布式系统中,我们不仅仅是需要在注册中心找到服务和服务地址的映射关系这么简单,我们还需要考虑更多更复杂的问题:

  • 服务注册后,如何被及时发现
  • 服务宕机后,如何及时下线
  • 服务如何有效的水平扩展
  • 服务发现时,如何进行路由
  • 服务异常时,如何进行降级
监控中心:

按照本人理解,监控中心是整个应用的晴雨表。监控服务器的内存、cup,查看系统运行日志,监控熔断情况,jvm运行情况等等。

流程详解:
  • 0 服务容器负责启动,加载,运行服务提供者(Standalone 容器)。
  • 1 服务提供者在启动时,向注册中心注 册自己提供的服务(Zookeeper/Redis)。
  • 2 服务消费者在启动时,向注册中心订阅自己所需的服务。
  • 3 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
  • 4 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
  • 5 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心(根据数据可以动态调整权重) dubbo.png

Dubbo 集群

面对服务消费方,当业务逻辑中需要调用一个服务时,真正调用的其实是 Dubbo 创建的一个 Proxy,该 Proxy 会把调用转化成调用指定的 Invoker(Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker,对上层透明,伪装过程包含了容错逻辑,调用失败后,重试另一个(通过 LoadBalance),Invoker 封装了 Provider 地址及 Service 接口信息)。而在这一系列的委托调用的过程里就完成了服务治理的逻辑,最终完成调用。 435188-20180412214429759-1005871251.png


全部评论: 0

    我有话说: