分布式服务Dubbo的前世此生

SOA与服务治理

SOA（面向服务的体系结构）概念由来已久，在10多年前便开始进入到咱们广大软件开发者的视线中。SOA是一种粗粒度、松耦合服务架构，服务之间经过简单、精肯定义接口进行通信，不涉及底层编程接口和通信模型。SOA能够看做是B/S模型、Web Service技术以后的天然延伸。

服务治理，也称为SOA治理，是指用来管理SOA的采用和实现的过程。如下是在2006年时IBM对于服务治理要点的总结：

• 服务定义（服务的范围、接口和边界）
• 服务部署生命周期（各个生命周期阶段）
• 服务版本治理（包括兼容性）
• 服务迁移（启用和退役）
• 服务注册中心（依赖关系）
• 服务消息模型（规范数据模型）
• 服务监视（进行问题肯定）
• 服务全部权（企业组织）
• 服务测试（重复测试）
• 服务安全（包括可接受的保护范围）

限于当时的技术发展水平，广大软件设计与开发人员对于SOA和服务治理的技术认知还主要停留在Web Service和ESB总线等技术和规范上，并无真正在软件开发中得以充分落地。

Dubbo开源

直到2011年10月27日，阿里巴巴开源了本身的SOA服务化治理方案的核心框架Dubbo，服务治理和SOA的设计理念开始逐渐在国内软件行业中落地，并被普遍应用。

Dubbo做为阿里巴巴内部的SOA服务化治理方案的核心框架，在2012年时已经天天为2000+个服务提供3,000,000,000+次访问量支持，并被普遍应用于阿里巴巴集团的各成员站点。Dubbo自2011年开源后，已被许多非阿里系公司使用，其中既有当当网、网易考拉等互联网公司，也有中国人寿、青岛海尔等传统企业。

Dubbo简介

Dubbo是一个高性能服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案，使得应用可经过高性能RPC实现服务的输出和输入功能，和Spring框架能够无缝集成。

做为一个分布式服务框架，以及SOA治理方案，Dubbo其功能主要包括：高性能NIO通信及多协议集成，服务动态寻址与路由，软负载均衡与容错，依赖分析与服务降级等。Dubbo最大的特色是按照分层的方式来架构，使用这种方式可使各个层之间解耦合（或者最大限度地松耦合）。从服务模型的角度来看，Dubbo采用的是一种很是简单的模型，要么是提供方提供服务，要么是消费方消费服务，因此基于这一点能够抽象出服务提供方（Provider）和服务消费方（Consumer）两个角色。

Dubbo包含远程通信、集群容错和自动发现三个核心部分。提供透明化的远程方法调用，实现像调用本地方法同样调用远程方法，只需简单配置，没有任何API侵入。同时具有软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，下降成本，减小单点。能够实现服务自动注册与发现，再也不须要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，而且可以平滑添加或删除服务提供者。

下图来自Dubbo官网，描述了服务注册中心、服务提供方、服务消费方、服务监控中心之间的调用关系，具体以下图所示：

节点角色说明：

调用关系说明：

1. 服务容器负责启动，加载，运行服务提供者。
2. 服务提供者在启动时，向注册中心注册本身提供的服务。
3. 服务消费者在启动时，向注册中心订阅本身所需的服务。
4. 注册中心返回服务提供者地址列表给消费者，若是有变动，注册中心将基于长链接推送变动数据给消费者。
5. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，若是调用失败，再选另外一台调用。
6. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心。 Dubbo整体架构

Dubbo框架设计共划分了10层，最上面的Service层是留给实际使用Dubbo开发分布式服务的开发者实现业务逻辑的接口层。图中左边淡蓝背景的为服务消费方使用的接口，右边淡绿色背景的为服务提供方使用的接口，位于中轴线上的为双方都用到的接口。

各层说明：

• Config配置层：对外配置接口，以ServiceConfig、ReferenceConfig为中心，能够直接初始化配置类，也能够经过Spring解析配置生成配置类。
• Proxy服务代理层：服务接口透明代理，生成服务的客户端Stub和服务器端Skeleton，以ServiceProxy为中心，扩展接口为ProxyFactory。
• Registry注册中心层：封装服务地址的注册与发现，以服务URL为中心，扩展接口为RegistryFactory、Registry、RegistryService。
• Cluster路由层：封装多个提供者的路由及负载均衡，并桥接注册中心，以Invoker为中心，扩展接口为Cluster、Directory、Router、LoadBalance。
• Monitor监控层：RPC调用次数和调用时间监控，以Statistics为中心，扩展接口为MonitorFactory、Monitor、MonitorService。
• Protocol远程调用层：封将RPC调用，以Invocation、Result为中心，扩展接口为Protocol、Invoker、Exporter。
• Exchange信息交换层：封装请求响应模式，同步转异步，以Request、Response为中心，扩展接口为Exchanger、ExchangeChannel、ExchangeClient、ExchangeServer。
• Transport网络传输层：抽象MINA和Netty为统一接口，以Message为中心，扩展接口为Channel、Transporter、Client、Server、Codec。
• Serialize数据序列化层：可复用的一些工具，扩展接口为Serialization、ObjectInput、ObjectOutput、ThreadPool。

模块分包

各模块说明：

• dubbo-common公共逻辑模块：包括Util类和通用模型。
• dubbo-remoting远程通信模块：至关于Dubbo协议的实现，若是RPC用 RMI协议则不须要使用此包。
• dubbo-rpc远程调用模块：抽象各类协议，以及动态代理，只包含一对一的调用，不关心集群的管理。
• dubbo-cluster集群模块：将多个服务提供方假装为一个提供方，包括：负载均衡、容错、路由等，集群的地址列表能够是静态配置的，也能够是由注册中心下发。
• dubbo-registry注册中心模块：基于注册中心下发地址的集群方式，以及对各类注册中心的抽象。
• dubbo-monitor监控模块：统计服务调用次数、调用时间的、调用链跟踪的服务。
• dubbo-config配置模块：是Dubbo对外的API，用户经过Config使用Dubbo，隐藏Dubbo全部细节。
• dubbo-container容器模块：是一个Standlone的容器，以简单的Main加载Spring启动，由于服务一般不须要Tomcat/JBoss等Web容器的特性，不必用Web容器去加载服务。

协议支持

• Dubbo协议（默认协议）
• Hessian协议
• HTTP协议
• RMI协议
• WebService协议
• Thrift协议
• Memcached协议
• Redis协议

注册中心

（1）Multicast注册中心：

Multicast注册中心不须要启动任何中心节点，只要广播地址同样，就能够互相发现。组播受网络结构限制，只适合小规模应用或开发阶段使用。组播地址段：224.0.0.0 - 239.255.255.255。

（2）ZooKeeper注册中心（推荐）：

ZooKeeper是Apacahe子项目，是一个树型的目录服务，支持变动推送，适合做为Dubbo服务的注册中心，可用于生产环境。

对上图流程说明以下：

1. 服务提供者（Provider）启动时，向/dubbo/com.foo.BarService/providers目录下写入URL。
2. 服务消费者（Consumer）启动时，订阅/dubbo/com.foo.BarService/providers目录下的URL，向/dubbo/com.foo.BarService/consumers目录下写入本身的URL。
3. 监控中心（Monitor）启动时，订阅/dubbo/com.foo.BarService目录下的全部提供者和消费者URL。

（3）Redis注册中心：

阿里内部并无采用Redis作为注册中心，而是使用本身实现的基于数据库的注册中心，即：Redis注册中心并无在阿里内部长时间运行的可靠性保障，此Redis桥接实现只为开源版本提供，其可靠性依赖于Redis自己的可靠性。

（4）Simple注册中心：

Simple注册中心自己就是一个普通的Dubbo服务，能够减小第三方依赖，使总体通信方式一致。只是简单实现，不支持集群，可做为自定义注册中心的参考，但不适合直接用于生产环境。

远程通讯与信息交换

远程通讯须要指定通讯双方所约定的协议，在保证通讯双方理解协议语义的基础上，还要保证高效、稳定的消息传输。Dubbo继承了当前主流的网络通讯框架，主要包括以下几个：

• Mina
• Netty（默认）
• Grizzly

中止维护

从2012年10月23日Dubbo2.5.3发布后，在Dubbo开源将满一周年之际，阿里基本中止了对Dubbo的主要升级。只在以后的2013年和2014年更新过2次对Dubbo2.4的维护版本，而后中止了全部维护工做。Dubbo对Srping的支持也停留在了Spring 2.5.6版本上。

分支出现

在阿里中止维护和升级Dubbo期间，当当网开始维护本身的Dubbo分支版本Dubbox，支持了新版本的Spring，并对外开源了Dubbox。同时，网易考拉也维护了本身的独立分支Dubbok，惋惜并未对外开源。

重获新生

通过多年漫长的等待，随着微服务的火热兴起，在国内外开发者对阿里再也不升级维护Dubbo的吐槽声中，阿里终于开始从新对Dubbo的升级和维护工做。在2017年9月7日，阿里发布了Dubbo的2.5.4版本，距离上一个版本2.5.3发布已经接近快5年时间了。在随后的几个月中，阿里Dubbo开发团队以差很少每个月一版本的速度开始快速升级迭代，修补了Dubbo老版本多年来存在的诸多bug，并对Spring等组件的支持进行了全面升级。

分支合并

在2018年1月8日，Dubbo 2.6.0版本发布，新版本将以前当当网开源的Dubbo分支Dubbox进行了合并，实现了Dubbo版本的统一整合。

Dubbo与Spring Cloud

阿里巴巴负责主导了 Dubbo 重启维护的研发工程师刘军在接受采访时表示：当前因为 RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与Spring Cloud是只能二选一，这也是为何你们老是拿Dubbo和SpringCloud作对比的缘由之一。Dubbo以后会积极寻求适配到Spring Cloud生态，好比做为Spring
Cloud的二进制通讯方案来发挥Dubbo的性能优点，或者Dubbo经过模块化以及对http的支持适配到Spring Cloud。

将来展望

2018年1月8日，Dubbo创始人之一梁飞在Dubbo交流群里透露了Dubbo 3.0正在动工的消息。Dubbo 3.0内核与Dubbo2.0彻底不一样，但兼容Dubbo 2.0。Dubbo 3.0将以Streaming为内核，再也不是Dubbo时代的RPC，可是RPC会在Dubbo3.0中变成远程Streaming对接的一种可选形态。Dubbo 3.0将支持可选Service Mesh，多加一层IPC，这主要是为了兼容老系统，而内部则会优先尝试内嵌模式。代理模式Ops可独立升级框架，减小业务侵入，而内嵌模式能够带业务测试、部署节点少、稳定性检测方便。同时，能够将Dubbo3.0启动为独立进程，由dubbo-mesh进行IPC，路由、负载均衡和熔断机制将由独立进程控制。

在此我向你们推荐一个架构学习交流群。交流学习群号：575745314 里面会分享一些资深架构师录制的视频录像：有Spring，MyBatis，Netty源码分析，高并发、高性能、分布式、微服务架构的原理，JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源，目前受益良多

总结

从 Dubbo 新版本的路线规划上能够看出，新版本的Dubbo在原有服务治理的功能基础上，将全面拥抱微服务和Service Mesh。同时，考虑到在阿里云已经有了Dubbo的商业版本，在将来一段时间内，Dubbo的更新与维护应该不会再长时间中断。在咱们进行服务治理以及微服务架构设计时，新版本Dubbo对咱们广大开发者来讲都将会是一个不错的选择。