Dubbo简介ApacheDubbo是一个RPC服务开发框架，那么什么是RPC呢？全称RemoteProcedureCall，翻译过来就是远程过程调用。使用Dubbo开发的微服务本身就具备远程地址发现和相互通信的能力。利用Dubbo提供的丰富的服务治理特性，可以实现服务发现、负载均衡、流量调度等服务治理需求。Dubbo被设计成高度可扩展的，用户可以很容易地实现各种自定义的流量拦截和位置选择逻辑。1.什么是dubbo？阿里巴巴自研的云原生微服务架构框架与springcloud类似，两者各有千秋。那么什么是云原生呢？很早就有人提出云原生的想法。在计算机领域，思想很重要，首先要想到技术变革。云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个复合词，Cloud+Native。云意味着应用程序位于云端，而不是传统的数据中心；原生是指应用在设计之初就以云环境为设计初衷，原生为云而设计，在云上以最佳姿态运行，充分利用云平台弹性+分布式优势。与Springcloud相比，Dubbo开发有一些优势：易于开箱即用，比如Java版的面向接口的代理特性，可以实现本地透明调用。服务治理能力为超大规模微服务集群设计极致性能，高性能RPC通信协议设计实现水平扩展，轻松支持百万级集群实例的地址发现和流量管理拦截扩展，如Filter、Router、LB等微服务治理组件扩展，如Registry、ConfigCenter、MetadataCenter等企业级微服务治理能力国内云厂商支持的事实标准服务框架2、DubboRPC通信中的一些概念在Dubbo3，RPC通信主要使用Triple协议。Triple协议建立在HTTP/2协议之上，兼容gRPC（gRPC协议是Google开发的基于HTTP/2和protobuf的RPC协议框架），提供RequestResponse、RequestStreaming、ResponseStreaming、Bi-directional流媒体和其他通信模型；从Triple协议开始，Dubbo也支持基于IDL的服务定义。此外，Dubbo还集成了大部分业界主流协议，让用户可以在Dubbo框架内使用这些通信协议，为用户提供统一的编程模型和服务治理模型，这些协议包括rest、hessian2、jsonrpc、thrift等，注意不同语言SDK实现支持的范围会有一些差异。服务发现服务发现是消费者自动发现服务地址列表的能力。这是微服务框架需要具备的关键能力。借助自动化服务发现，微服务无需感知对端的部署位置和IP地址。实现沟通。有很多方法可以实现它。一是Dubbo提供的Client-Based服务发现机制。同时需要第三方注册中心来协调服务发现过程，比如Nacos/Zookeeper。基本原理图：流量治理从Dubbo2开始，Dubbo提供了丰富的服务治理规则，包括路由规则/动态配置等。一方面，Dubbo3正在通过对接xDS接入Istio等流行Mesh产品中使用的以VirtualService和DestinationRule为代表的治理规则；流量治理，灵活的治理能力。DubboMeshMesh网络可以理解为WiFi路由器不能覆盖一些盲点，可以在盲点可以覆盖的地方放一个中继WIFI，组成一个MESH网络，可以覆盖盲点。DubboMesh的目标是提供一个完整的适配Dubbo体系的Mesh解决方案，包括定制化的控制面（ControlPlane）和定制化的数据面解决方案。Dubbo控制面基于业界主流的Istio扩展，支持更丰富的流量治理规则、Dubbo应用级服务发现模型等。Dubbo数据面可以使用EnvoySidecar，实现DubboSDK+Envoy的部署方案，或者DubboProxyless模式。直接实现Dubbo与控制面的通信。3.Dubbo架构图从整体上看，Dubbo首先是一个RPC框架。用户在使用Dubbo时，首先需要定义Dubbo服务；其次，部署Dubbo服务上线后，依赖Dubbo的应用层通信协议实现数据交互，Dubbo传输的数据必须进行序列化，这里的序列化协议是完全可扩展的。使用Dubbo的第一步是定义Dubbo服务。Dubbo中服务的定义是一套完成业务功能的方法。您可以选择以绑定到某种语言的方式来定义它们。比如在Java中，Dubbo服务有一套Interface接口的方法，也可以使用语言中立的ProtobufBuffersIDL来定义服务。服务定义完成后，服务端（Provider）需要提供服务的具体实现，声明为Dubbo服务。从服务消费者（Consumer）的角度来看，可以通过调用Dubbo框架提供的API（stub）对象获得一个服务代理，然后就可以像调用本地服务一样调用服务方法。消费者发起服务方法调用后，Dubbo框架负责将请求发送给部署在远程机器上的服务提供者。提供者收到请求后，会调用服务的实现类，然后将处理结果返回给消费者。这样就完成了一次完整的服务调用。图中Request和Response的数据流向如图所示。需要注意的是，在Dubbo中，服务指的是RPC粒度，与读者印象中的一般函数式服务不是同一个概念。在分布式系统中，服务越来越多，应用之间的部署也越来越复杂。作为RPC的消费者，用户如何动态知道服务提供者的地址，所以Dubbo引入了一个注册中心来协调提供者和消费者的地址。提供者启动后，将自己的地址注册到注册中心，消费者通过拉取或订阅注册中心的特定节点，动态感知提供者地址列表的变化。注册中心可以使用：如Nacos、Zookeeper、Consul、Etcd等。把服务的组织和注册交给底层容器平台，比如Kubernetes，可以理解为更云原生的用法。Dubbo部署架构图：Dubbo微服务组件包括三个中心组件：注册中心，负责协调Consumer和Provider之间的寻址和发现。配置中心存储了Dubbo在启动阶段的全局配置，保证了配置的跨环境共享和全局一致性。服务治理规则（路由规则/动态配置等）的存储和推送元数据中心接收Provider上报的服务接口元数据，为Admin和Admin提供运维能力（如服务测试/接口文档等）其他游戏机。额外的扩展，作为对服务发现机制的补充，为额外的接口/方法级配置信息提供同步能力。注册中心不依赖于配置中心和元数据中心。注册中心的主要作用是负责服务注册和服务发现。Dubbo支持接口级别和应用级别两个粒度的服务发现和服务注册。如果Dubbo只使用RPC直连服务，则不需要部署注册中心。在界面或应用层面，您可以选择部署相应的注册中心。在Dubbo+Mesh场景下，随着Dubbo服务注册能力的弱化，Dubbo中的注册中心不再是必须的，其职责开始被控制面所取代。如果采用Dubbo+Mesh的部署方式，无论是ThinSDKProxyless的mesh方式，还是Proxyless的mesh方式，都不再需要独立部署注册中心。元数据（metadatacenter）对于原来使用老版本Dubbo构建的应用服务，在迁移到Dubbo3时，Dubbo3会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口之间的映射关系）和应用程序），因为如果采用应用层的服务发现和服务注册，注册中心将采用“应用-实例列表”结构的数据组织形式，而不是之前的“接口-实例列表”的数据组织形式structure以往在接口层注册发现的应用服务迁移到应用层时，无法获取接口与应用的对应关系，导致无法从注册中获取实例列表信息中心。所以，为了兼容这个，Dubbo在这个场景下，在Provider端启动的时候，会把接口和应用的映射关系存储在元数据中心。为了让注册中心更专注于地址发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据，大量的接口/方法级别的配置信息等，无论是接口粒度或应用粒度的服务发现和注册，元数据中心发挥了重要作用。如果你有以上两个需求，可以选择部署元数据中心，通过Dubbo配置集成元数据中心。元数据中心不依赖于注册中心和配置中心。用户可以自由选择是否集成和部署元数据中心，如下图所示：在配置中心的整个部署架构中，整个集群中的实例（无论是Provider还是Consumer）都会共享配置中心集群中的配置。三大中心不一定是Dubbo应用服务所必需的，但是如果三大部署中心整合起来，还是会存在可用性问题，比如多个注册中心、多个配置中心、多个元数据中心，系统应该如何运行.Dubbo支持三中心Multiple模式：多注册中心：Dubbo支持多注册中心，即一个接口或者一个应用可以注册到多个注册中心，比如ZK集群和Nacos集群，Consumers也可以是可以从多个注册中心订阅相关服务的地址信息，用于服务发现。通过支持多个注册中心，保证其中一个注册中心集群不可用时可以切换到另一个注册中心集群，从而正常提供服务和发起服务调用。这也可以满足注册中心在部署中适应各种高可用部署架构模式。多配置中心：Dubbo支持多配置中心，保证其中一个配置中心集群不可用时可以切换到另一个配置中心集群，保证全局配置、路由规则等信息可以从集群中获取配置中心正常。这也可以满足配置中心在部署中适应各种高可用部署架构模式。多数据中心：Dubbo支持多数据中心：用于应对容灾等导致某个元数据中心集群不可用的情况。此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供相关业务元数据。管理能力。如果有多个注册中心，部署结构如下：A机房，B机房，两个注册中心，ProviderA通过DubboSDK将地址注册到RegistryA，ConsumerA与注册中心A相互订阅。B机房和A机房的原理是一样的，AB机房的注册中心会进行数据同步，这样A机房的消费者A也可以看作是同步订阅地址到机房的RegistryB.4.为什么Dubbo需要强调系统的可扩展性？一个很大的原因是，比如一个系统设计好之后，后面需要添加一些功能代码或者插件。如何尽量减少对原有代码的改动，增加功能代码或插件，这就是可扩展性。Dubbo在架构时期一直很重视扩展性。可扩展性。市场上有成熟的可扩展技术，比如Spring的IOC容器，或者Factory。Dubbo在设计之初，不想过多依赖Spring的IOC，也不想花很多时间去开发一个IOC容器，所以用的最多的是SimpleFactory。Dubbo扩展加载流程如图：主要步骤4：读取并解析配置文件，缓存所有扩展，根据用户执行实现扩展，实例化对应的扩展，实现扩展实例属性的IOC注入，实例化扩展包装类，实现AOP特性，欢迎关注我的公众号：我只是一个码字。本文由博客发布平台OpenWrite发布！
