1.背景

想象下这么个场景：

有个做生活服务的APP，主要提供一些生活化的咨询信息，比如天气、新闻、个人三金账单、政府办事事项等等，那么把这些功能全部放入一个应用肯定是不现实的。

按照分布式服务的设计理念，可能最终的结果是用户登录、注册相关的作为一个user应用，天气相关的一个weather应用，新闻资讯相关的一个news应用，账单相关的一个bill应用，政府办事相关的一个life应用，这样就被拆分成了若干个功能相对稳定的应用，同时应用之间通过RPC调用，共同构成了一个分布式服务框架。

这种分布式服务架构在流量、服务数量相对小的时候足够满足实际需要，但是在服务数量越来越大、流量增大或者间断性流量出现峰值、服务间调用越来越复杂的情况下，这种架构就就很难再满足需要了。比如上述的APP这周搞推广注册送礼的活动，突然间登录、注册的操作暴增，此时负责处理相关业务的user应用负荷增加，出现响应慢、超时、宕机的情况，怎么办？按分布式服务框架，最简单直接的办法是增加user应用的实例、带宽等硬件资源，再在调用方或者Nginx端改改user应用相关的负载列表，重启over。等推广结束之后再改改负载列表，停掉增加的资源，重启over.......

如此一来，反复地增加、删除、停止、启动，只要中间某一步做错，就会造成难以想象的错误。那么如何弹性、动态地计算所需资源，又如何动态地增加、删除资源，最大程度不影响业务流转，减少犯错误的几率，是一个新的课题。由此流动式的架构理念运用而生，而dubbo框架正是流动式计算架构的一种。

2.Dubbo是什么

Dubbo是阿里旗下的一个弹性的分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。

3.Dubbo能做什么

3.1.透明化的远程方法调用

没有API侵入，就能像调用本地方法一样调用远程方法。

在实际项目中，通常会对Provider和Consumer使用的公共部分，抽象为一个通用的一个jar包，内部定义需要的Service、DTO、POJO、工具类等。此时，Provider端实现Service服务，Consumer引入jar包，申明服务。通过此种方法，实现无API侵入，Service对Consumer透明，但最终实现了Consumer对Provider的调用。

3.2.服务自动注册与发现

服务的注册、发现、更新都是基于注册中心Registry来实现的。

Registry与Provider、Registry与Consumer之间实现了基于Socket长连接的实时心跳检测，每隔几秒钟检测一次，收集Provider、Consumer的服务信息，整理更新服务列表。通过这样的实现，Provider和Consumer均不再需要写死服务提供方地址，只需要配置注册中心地址即可，实现动态化。

3.3.软负载均衡及容错机制

Dubbo提供了一系列的软负载均衡算法供使用，可替代F5等硬件负载均衡器，降低硬件成本，减少单点。

Consumer通过订阅服务，在本地缓存可调用的服务列表，在实际调用某服务时，基于负载均衡算法，选取某一节点调用。当某服务节点宕机、或网络不可用时，Registry基于心跳检测实时更新可调用者列表，并将更新信息推送到Consumer，由Consumer更新本地缓存，实现容错，实现高可用。

4.Dubbo服务架构及调用流程

Dubbo架构图如下所示：

节点角色说明：

Provider: 暴露服务的服务提供方。

Consumer: 调用远程服务的服务消费方。

Registry: 服务注册与发现的注册中心，可选。

Monitor: 统计服务的调用次调和调用时间的监控中心，可选。

Container: 服务运行容器。

调用流程：

0. 服务容器负责启动、加载，运行Provider。

1. Provider在启动时，向Registry注册自己提供的服务，Registry缓存服务列表，并建立长连接心跳检测。

2. Consumer在启动时，向Registry订阅自己所需的服务，并建立长连接心跳检测。

3. Registry返回服务提供者地址列表给Consumer并缓存，如果服务有变更，Registry将基于长连接推送变更数据给Consumer并更新。

4. Consumer在使用服务时，基于软负载均衡算法，从提供者地址列表中，选一台Provider进行调用，如果调用失败，则切换到另一台调用。

5. Consumer和Provider，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到Monitor。

5.Dubbo应用搭建

Dubbo采用全Spring配置方式，透明化接入应用，只需用Spring加载Dubbo的配置即可。

代码结构

代码project结构非常简单，如图：

其中，

dubbo-api是公共的基础包，主要声明provider和consumer共用的服务接口、工具类、实体等，以jar包形式提供；

dubbo-provider是服务提供者，声明provider需要提供的哪些服务，以war包形式提供；

dubbo-customer是服务消费者，声明需要使用的服务，以war包形式提供；

dubbo-service是dubbo-api中服务的实现者，此包可直接包含在dubbo-provider中，以jar包形式体现。

Dubbo-api

在公共jar包中，定义服务接口，如下：

dubbo-service

在实现jar包中，实现dubbo-api中定义的接口（此实现对消费方式透明的），如下：

dubbo-provider

使用Spring配置声明对外暴露服务，主要包含：

dubbo-application服务提供者的名字：标记唯一提供者；

dubbo-registry注册中心地址及其端口：启动时，向注册中心注册服务，此处使用zookeeper；

dubbo-protocol通信协议及端口：各个终端之间通讯的协议，使用dubbo协议；

dubbo-service暴露服务声明：需要暴露哪些服务，就声明哪些dubbo:service的Bean。

dubbo-customer

使用Spring配置，引用远程暴露的服务，主要包含：

dubbo-application服务消费者名字：标记唯一消费者；

dubbo-registry注册中心地址及其端口：启动时，向注册中心订阅服务，并在本地缓存；

dubbo-reference服务引用：声明需要使用的服务接口名称，和原生spring声明bean的方式类似。

配置如下图：

服务使用时，像spring式注入JavaBean，类似本地化调用Service一样使用，如图：

dubbo工程搭建总结

通过上述代码示例，不难看出dubbo使用其实非常简单，通过Spring配置全部搞定。对于消费者来说，只需要知道服务在哪里、服务名叫什么、有什么方法、入参是哪些即可，不需要知道内部的实现细节。这种特性完全无API侵入，实现各部分之间松散耦合，减少依赖。

6.Dubbo的高级特性

除了上述基本功能之外，dubbo具有诸多高级特性，组成了dubbo整套架构体系。

多元化注册中心

注册中心可以使用zookeeper、redis等作为注册中心，也可以去中心使用广播形式。

zookeeper作为注册中心，内部存储使用了目录式结构，此为推荐；

Redis这样的K/V式数据存储，内部则使用了服务名作为Key，URL地址作为Value，比如：

另广播Multicast形式，启动时广播自身的地址，无注册中心，此为测试使用。

集群容错

上述示例中，只使用了单个zk实例、单provider、单consumer，实际生产中还可以配置多个实例即注册中心集群、provider集群、consumer集群，相同集群之间是等价的，最终为负载均衡提供条件。

软负载均衡

当注册中心其他实例宕机，只要有一个可提供服务则可保证整个应用群可正常发布、订阅服务；即使全部宕机只要之前的服务提供者可正常提供服务，虽不能发布和订阅，但是消费者任然可以调用，因为消费者本地缓存了可调用列表。

Provider集群各实例提供了相同的服务，只要有实例新增或者宕机，基于长连接通讯，每个消费者均能感知到并及时更新自身缓存列表。实时调整路由群。

Consumer消费者对服务进行invoke调用时，会根据负载均衡算法，分发请求到某个provider实例，降低各个实例的负载。成熟的负载均衡算法有随机、按公约权重轮询、最少活跃调用数、一致性Hash，使用者可以根据机器、网络等情况实时分配和调整策略，灵活方便。

统一化管理平台admin

dubbo提供了可视化的管理平台dubbo-admin，使用者只要下载运行应用即可。

此平台提供了丰富的管理功能：

服务管理：有哪些服务，哪些在使用哪些已停止，对应的主机、端口、权重是多少，实时调整；

应用管理：当前有哪些应用，各自是什么角色，相互调用关系是什么，使用的负载均衡算法是什么等等。

运营监控中心

此为可选组件，对应项目为dubbo-monitor，监控SQL执行、服务调用等统计信息。和provider、Consumer一样，通过spring配置的形式，声明dubbo:monitor角色。在provider和consumer端，声明monitor地址，并定义AOP切面，收集监控信息，并定时向监控中心发送。

7.Dubbo的缺点

上面叙述了种种dubbo的优势，下面说说它的缺点。

体系结构方面

Dubbo要求将功能服务化，抽象成若干个通用的小的服务，形成分布式结构。因此往往会在最后形成大量的服务，体系会非常庞大，管理起来比较困难。但这跟它带来的种种有点相比，还是微不足道的。

安全性方面

Dubbo在使用场景方面主要针对内部的服务，由内部人员进行管理，一般很少对外部系统开放。而通常对外的服务，一般建立WebService、Rest等形式的接口，并辅助OAuth等安全协议来来处理安全。这就造成了，Dubbo在安全方面实现的功能较少，主要原则是基本上只防君子不防小人。

目前安全性层面，Dubbo通过Token令牌防止用户绕过注册中心直连，然后在注册中心上管理授权。Dubbo还提供服务黑白名单，来控制服务所允许的调用方。

本文作者：兰伟敏（点融黑帮），主要从事Java后端开发，爱好电影、旅行、DOTA，目前主要负责贷款端LOANAPP系统研发。