架构道术-企业选择Dubbo作为分布式服务框架的10个理由

在前面我们介绍过关于企业分布式系统的演进过程，其中有一个非常重要的概念：服务化治理。那服务化治理中涉及到最核心的通讯框架就是RPC（Remote Procedure Call），RPC这一概念与技术早在1981年由Nelson提出，其主要用于支持异构型分布式系统间的通讯。

今天老王带领大家了解下，分布式Dubbo框架是凭借什么样的优势突破重围，最终一枝独秀呢？

1、RPC框架应用背景

回顾40多年发展历程，RPC已在众多大中小企业所普及。我们所熟知的阿里的Dubbo、腾讯的Tars、Google的gRPC、Facebook的Thrift、京东的JSF、美团的OCTO-RPC、Spring Cloud等。

这些RPC框架在各自公司根据自己的业务情况，支撑着几乎全部业务系统，更为重要的是在大促618和11.11期间，RPC框架的抗压能力更为显著。

2、RPC协议在服务化治理中的地位

服务化在架构设计层面属于抽象概念，那最终真正用于服务化落地实现的关键还需要RPC协议。在上述个大厂不同的RPC框架对序列化实现、可读性、扩展性以及通用性方面都不尽相同。

但无论是哪一种RPC框架，他们的设计和实现思路都未离开Nelson的理念：支持分布式系统异构。那在分布式系统异构中，必然离不开RPC的两个最为核心部分：

RPC框架请求调用过程大致如下：

那在众多优秀框架中，我们不得不提到一个被业界公认的优秀RPC分布式框架Dubbo。Dubbo3 提供了 Triple、Dubbo2 协议，这是 Dubbo 框架的原生协议。除此之外，Dubbo3 也对众多第三方协议进行了集成，并将它们纳入 Dubbo 的编程与服务治理体系， 包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。

接下来老王从10个方面，来聊一聊为什么很多企业会选择Dubbo做为公司内部分布式框架。

3、企业分布式架构选择Dubbo的10个理由

科普：Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。Dubbo现如今已被Apache收购作为顶级项目，已经成为许多企业青睐的对象。

3.1 对业务代码侵入性极低

跨网络服务间的调用方式要比本地同一进程空间执行方法复杂的多，比如通信协议、对象序列化、网络传输等复杂细节。RPC框架为我们屏蔽了非业务相关的实现细节，这个能是开发人员只关注自身的业务逻辑即可。透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

3.1.1 注册中心配置

# application.properties
dubbo
 registry
  address: zookeeper://127.0.0.1:2181

3.1.2 服务端Spring XML配置注册

<bean id="demoServiceImpl" 
      class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>
<dubbo:service serialization="protobuf"     
               interface="org.apache.dubbo.demo.DemoService" 
               ref="demoServiceImpl"/>

3.1.3 消费端Spring XML引用服务

<dubbo:reference scope="remote" 
                 id="demoService" 
                 check="false" 
                 interface="org.apache.dubbo.demo.DemoService"/>

3.1.4 消费端调用服务Proxy

public void callService() throws Exception {
    // context - Spring上下文
    DemoService demoService = context.getBean("demoService", DemoService.class);
    demoService.sayHello(request); //调用服务端方法
}

3.2 服务自动注册与发现

实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based 的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。官方推荐使用Zookeeper注册中心。

3.2.1 服务端自动注册

在暴露服务时，会自动向注册中心注册接口，服务提供者会与注册中心保持长连接，一旦连接断掉会话信息失效后，注册中心会认为该服务提供者不可用，此时提供者节点会被删除。

3.2.2 客户端自动发现

避免了写死服务提供者地址，注册中心基于接口名自动查询提供者IP. 以上不论是服务提供者还在消费者，都通过自动注册和自动发现机制来完成，无需人工干预。

3.3 可适配云原生微服务

随着互联网技术的不断更新且硬件设施成本也越来越低，云原生时代的基础设施能力也在不断向上释放，Dubbo也逐渐走在了适配云原生微服务的变更的道路上。

3.3.1 适配Kubernetes平台

像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo 的应用级服务发现是适配各种微服务体系的通用模型。在架构兼容性上，Dubbo 复用下层基础设施的服务抽象能力成为了可能。

3.3.2 适配Spring Cloud平台

Spring Cloud 等业界其它微服务解决方案也沿用这种模型， 在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。

3.4 三大中心高可用天然保障

我们知道Dubbo包括三大中心：注册中心、配置中心和元数据中心。但在实际生产环境当中，难免会有异地部署、同城多活、多地多中心等场景。那在这些方面Dubbo能否保障系统的高可用呢？这一点也是架构师们最为关心的，答案是肯定的。

在Dubbo中天然支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。这主要源于阿里本身业务的特性——业务复杂且场景多样化，业务跨区域甚至跨国家等，这些因素也必然促使自身要保障好系统的稳定性和高可用。

以注册中心图例来说明高可用性。

3.4.1 支持多注册中心

Dubbo 支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，Consumer能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。

3.4.2 支持多配置中心

Dubbo支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。

3.4.3 支持多元数据中心

Dubbo 支持多元数据中心，用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。

3.5 灵活的流量路由管理策略

通过 Dubbo 定义的路由规则，可以实现对流量分布控制。Dubbo提供了支持Mesh方式的流量管理策略，可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。

Dubbo将整个流量管理分成VirtualService和DestinationRule两部分。当Consumer接收到一个请求时，会根据VirtualService中定义的DubboRoute和DubboRouteDetail匹配到对应DubboDestination中的subnet，最后根据DestinationRule中配置的subnet信息中的labels找到对应需要具体路由的Provider集群。

首先，路由规则可以有多个，不同的路由规则之间存在优先级，一个路由规则可以路由到多个不同的应用服务，多个不同的路由规则可以路由到同一个应用服务。其次，路由规则也可以不路由到任何应用服务。最后，路由规则可以针对的是单个的实例，也可以是一个应用集群。

这种设计理念很好的解决流量分流和目标地址之间的耦合问题。不仅将配置规则进行了简化有效避免配置冗余的问题，还支持VirtualService和DestinationRule的任意组合，可以非常灵活的支持各种业务使用场景。

3.6 易于对Dubbo进行二次开发

Dubbo 中的扩展能力是从 JDK 标准的 SPI 扩展点发现机制加强而来，它改进了 JDK 标准的 SPI很多问题，Dubbo 考虑到适用场景面的问题，没有强依赖 Spring 等 IoC 容器，而是选择了最简单的 Factory 方式管理扩展。

如果你有以下场景的诉求，就可以基于Dubbo提供的扩展点来进行自定义扩展：

1）自定义负载均衡策略

2）实现自定义的注册中心

3）实现自定义的过滤器

很多小规模企业，落地生产环境的服务化架构基本都会采用Dubbo。主要是由于Dubbo的设计良好、使用简单、技术文档丰富，更重要的是开发人员可以很容易的对Dubbo进行二次开发，比如当当网的Dubbox框架在开源社区就比较受很多开发者的青睐。

在 Dubbo 中，所有内部实现和第三方实现都是平等的，用户可以基于自身业务需求，替换 Dubbo 提供的原生实现。如果用户有需求需要进行扩展，那么只需要对其关注的扩展点进行扩展就好，极大的减少用户的工作量。

扩展共四个步骤：

Dubbo 扩展能力使得 Dubbo 项目很方便的切分成一个一个的子模块，实现热插拔特性。用户完全可以基于自身需求，替换 Dubbo 原生实现，来满足自身业务需求。

3.7 完备的技术文档体系

目前Dubbo已作为Apache顶级项目，自然少不了完善的文档。Apache Dubbo

详细的开发说明文档：文档 | Apache Dubbo

众多技术牛人博客：Apache Dubbo 博客 | Apache Dubbo

完善的社区生态：社区 | Apache Dubbo

3.8 服务监控界面可视化

Dubbo-admin和Dubbo-monitor提供了完善的服务接口管理和监控功能。针对不同应用的不同接口，能够进行多版本、多协议、多注册中心管理。监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器为服务的监控运维采集数据。

监控中心可以不安装，Monitor挂掉不会影响到Consumer和Provier之间的调用，只是丢失部分采样数据。另外，监控中心可以自定义扩展开发，包括个性化运维监控、服务的健康状况、服务的压力和性能状况、告警通知以便及时处理等。

3.9 监控对服务性能影响小

序列化方面，我们都知道 Java本地的对象要在网络上传输，必须实现Serializable 接口，也就是必须序列化。常见的序列化格式有：Xml、Json、二进制流等。而Dubbo 采用的就是效率最高的二进制传输方式；另外，请求协议采用单一长连接和NIO通讯机制，从而提升了通信效率，不用反复连接,直接传输数据，并且支持大并发量。

3.10 完备的全链路跟踪方案

我们知道，有些C端核心业务系统往往对性能要求比较高，比如订单系统、商品系统等。这些系统偶尔会出现一些不可预知的问题。而且系统一旦出现问题，研究就需要及时响应并快速解决问题。这就要求应用系统有很完善的监控体系。但往往很多监控系统或监控组件对业务系统性能影响比较严重，有的甚至在关键时候阻断业务流程。

那Dubbo就为我们提供了一套完善的监控机制，对性能影响很小。Dubbo可收集每个调用链路上每个服务的执行耗时，以及整合孤立日志。便于运维人员根据TraceId便可知道整个请求链路的运行状态，从而能很好的提升排查问题效率。

4、 Dubbo框架能否一统江湖

由于Dubbo框架是由Java语言开发，如果是项目中使用了其他非Java语言，那需要选择其他RPC框架做技术选型了。如果在未来Dubbo做到多语言适配，在RPC分布式框架领域内是否有一统江湖的可能呢？让我们拭目以待。