为了账号安全,请及时绑定邮箱和手机立即绑定

姚半仙:大话RPC和Dubbo架构设计

2019.12.02 13:44 459浏览

Dubbo是阿里巴巴在2012年开源的分布式服务治理框架,不仅是阿里巴巴在开源领域最出名的项目,也应该算称得上是国内影响力最大的开源大作。可是大家有所不知,阿里内部实际上都在使用另一个RPC框架叫HSF,这里面的恩怨情仇会在最后一个小节介绍(Dubbo和HSF的开发团队是同一拨人马,造轮子狂热症患者),Dubbo这些年浮浮沉沉,也曾经一度停止了更新,而随着18年Dubbo3.0的强势推进,相信这个大版本中Dubbo会充分借鉴HSF在超高并发场景下积累的经验。

在服务治理领域的泰山北斗是RPC和HTTP两派,据我观察,国内公司更偏爱基于RPC的微服务解决方案,国外公司则是偏爱Spring Cloud全家桶,不光是在服务治理的技术选型上有这种国内、国外的差别,很多开源组件的选型上都有这种地域色彩(拿持久层框架来说,国内偏爱使用iBatis/MyBatis,国外更偏爱ORM框架)

我个人偏向来说是建议使用Spring Cloud,并不是说SC在服务治理领域做得比Dubbo更好,而是更看好SC的体系构建能力。毕竟不是所有公司都有阿里这样的技术背景,可以为了追求极致造各种轮子,大部分公司需要的其实是Spring Cloud这样的微服务全套解决方案。就像盖房子一样,SC作为一家供应商,提供了应有尽有的各种建筑原材料,不用再为每个环节去费心选材。

Dubbo是一款轻量级+高性能的RPC框架,所谓天下武学殊途同归,Dubbo的很多理念和Spring Cloud中的组件都差不多。我们就来看一下Dubbo的几个核心特性,顺带和Spring Cloud中的组件关联对比一下

(1)基于接口 + 动态代理的远程方法调用

Dubbo对开发者屏蔽了底层的调用细节,在实际代码中调用远程服务就像调用一个本地接口类一样方便。这个功能和Feign很类似,但是Dubbo用起来比Feign还要简单很多,Feign有时还要独立声明一个新接口,而Dubbo真的就是拿到公共接口类后直接就能用。后面的Demo小节将带大家体验一把

(2)负载均衡

Dubbo内置多种负载均衡策略,智能感知下游节点健康状况,显著减少调用延迟,提高系统吞吐量。这部分功能和Ribbon十分接近,但是Dubbo的负载均衡策略不如Ribbon的多,而且Dubbo的负载均衡能力只能供自己享用,而Ribbon可以赋能给Spring Cloud里的各个组件

(3)集群容错

Dubbo提供了一个Cluster组件专门用来做集群容错,它其实并不是Hystrix这类降级组件,而是一种“异常重试”组件,后面我们也有一个专门的小节来介绍这部分的内容

(4)服务治理

支持多种注册中心服务,服务实例上下线实时感知。这里面的功能相信大家都能猜个八九不离十,就是服务注册、服务发现、服务下线之类的流程,这些功能和Eureka里的概念是一样一样的,只是实现方式却大有不同。比如Dubbo在服务下线后会主动将可用服务列表下发到各个服务节点,送货上门服务周到,而Eureka每次都等着服务节点自己上注册中心来拿数据,不给包邮的。

除了上面几个核心特性以外,还有诸如运行期流量调度(灰度、路由规则等)和可视化服务治理(运维工具,数据统计)等功能,我们就不一一介绍了。

可以这么说,Dubbo的技能加点比较专一,全点在了服务治理系,单就服务治理来看的话确实做得比Eureka要细致一些的。但是要论体系的话,还是不可能和Spring Cloud相提并论的。

我们先来认识下Dubbo中的五个基础组件,下面图里的紫色线条代表了组件初始化的路径,蓝色虚线是异步通知流程,蓝色实线则是同步阻塞调用。

IPing

上图中出现的五个组件分别对应如下功能

组件名称 说明
Registry 注册中心
Provider 服务提供方
Consumer 向Provider发起远程调用的消费者
Monitor 监控中心,用来统计服务调用的频率和响应时间
Container 运行服务的容器

我们弄清楚了谁是谁之后,来捋一捋RPC调用的来龙去脉。我们就顺着图中的步骤标号,从0到5挨个说一下:

  • Start 服务容器启动后初始化服务提供者
  • Register 服务提供者在启动的过程中,向注册中心发起注册,这个步骤和Eureka的流程很像
  • Subscribe 服务消费者在启动的同时,向注册中心订阅所需的服务。这一个流程就和Eureka就大不相同了,Eureka是Consumer主动到服务中心去拉取数据,而Dubbo采用了一种Pub/Sub模式,也就是发布订阅模型
  • Notify 注册中心将Provier地址列表发送给消费者,对于服务下线之类的变更,注册中心会主动推送变更数据到Consumer(建立在长连接之上)
  • Invoke 服务消费者发起远程调用,这个过程会使用负载均衡算法挑选目标服务器
  • Count Consumer和Provider每隔一段时间将统计信息发送到监控中心,平时这些信息就暂存于内存当中

Dubbo和Eureka中服务发现的不同

服务发现应该是Dubbo和Eureka最大的一个不同之处。

Dubbo里的注册中心、Provider和Consumer三者之间都是长连接,借助于Zookeeper的高吞吐量,实现基于服务端的服务发现机制。因此Dubbo利用Zookeeper+发布订阅模型可以很快将服务节点的上线和下线同步到Consumer集群。如果服务提供者宕机,那么注册中心的长连接会立马感知到这个事件,并且立即推送通知到消费者。

在服务发现的做法上Dubbo和Eureka有很大的不同,Eureka使用客户端的服务发现机制,因此对服务列表的变动响应会稍慢,比如在某台机器下线以后,在一段时间内可能还会陆续有服务请求发过来,当然这些请求会收到Service Unavailable的异常,需要借助Ribbon或Hystrix实现重试或者降级措施。

对于注册中心宕机的情况,Dubbo和Eureka的处理方式相同,这两个框架的服务节点都在本地缓存了服务提供者的列表,因此仍然可以发起调用,但服务提供者列表无法被更新,因此可能导致本地缓存的服务状态与实际情况有别。

这一小节我们了解了Dubbo的核心组件,下一小节我们去看下Dubbo的几个重要工作流。

想说一些大胡(实)话: 我们知道Spring Cloud里很多组件都来自于Netflix的贡献,我是蛮佩服这家公司的,作为一家影视公司,竟然可以将微服务领域的一整套架构开源出来,还被吸纳进Spring Cloud项目,放在国内是完全无法想象的。

所以同学们不要以为国内的BAT技术能力有多么逆天,其实我们和国外的巨头公司还是存在很大的差距的。这种差距不仅体现在硬实力上,更在于真正的软实力和价值观上,比如企业的奉献精神,诚信,还有对待用户的态度,以及对自己员工的尊重。相比较而言,国内所谓的巨头的价值观普遍过于功利(996,一切向钱看)。

·······················
更多精彩内容,欢迎关注课程:《Java架构师成长直通车》

点击查看更多内容

本文原创发布于慕课网 ,转载请注明出处,谢谢合作

1人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消