Dubbo高级篇3

服务化的目标

       1. 将系统中独立的业务抽取出来，按业务的独立性进行垂直划分，抽象出基础服务层。

        2.基础服务为上游业务的功能 实现提供支撑，基础服务应用本身无状态，可随着系统的负荷灵活伸缩来提供服务能力。

    

服务子系统的数量把控

过多:可能划分过细，破坏业务子系统的独立性(如支付订单、退款订单、用户、账户)

,部署维护工作量大，独立进程占用内存多

过少:没能很好地解耦

开发维护不好分工

升级维护影响面大

服务子系统划分注意事项:
不要现现A服务中的SQL需要链接查询到B服务中的表等情况，这样在A服务与B服务进行垂直拆库时就会出错

服务子系统间避免出现环状的依赖调用 (A依赖B，B依赖C,C依赖A)

服务子系统间的依赖关系不要过长（A服务依赖B服务,B服务依赖C服务，C依赖D服务.....,最好不要超过三个,可能划分不好，或者过细）

尽量避免分布式事务（尽量把做的事情放在一个服务内，即同一事务内）

1 、设计方式

action->facade->biz->dao

好的Dubbo服务接口设计，并非只是纯粹的接口服务化

2.接口类型

简单的数据查询接口:action.facade、dao(例根据Id查询记录)

带业务逻辑的数据查询接口:action、facade、biz、dao(复杂的查询，带业务逻辑)

简单的数据写入接口：action、facade、dao(简单数据插入)

带业务逻辑的数据写入接口:action、facade、biz、dao(有业务逻辑的数据处理)

同步接口

异步接口

3.设计原则

服务接口尽可能大粒度，每个服务方法应代表一个功能，而不是某功能的一个步骤，否则将地面临分布式事务问题，

Dubbo暂未提供分布式事务支持，同时可以减少系统间的网络交互

服务接口建议以业务场景为单位划分，并对相近的业务做抽象,防止接口数量爆增(爆炸)。

例:某一个接口有多个实现，做成一个接口，再在dubbo分组中多实现

不建议使用过于抽象的通用接口，如Map query(Map),这样的接口没有明确语义，会给后期维护带来不便

接口版本:

每个接口应定义版本号，为后续不兼容升级提供可能

如:

<dubbo:service interface="com.xxService" version="1.0"/>

接口兼容性:

服务接口增加方法，或服务模型增加字段，可向后兼容；

删除方法或删除字段，将不兼容，枚举类型新增字段也不兼容，需要通过变更版本号升级。

异常处理:

建议使用异常汇报错误，而不是返回错误码，异常信息能携带更多的信息，以及语义更友好。

如果担心性能问题，在必要时，可以通过override掉异常类的finlllnStackTrace()方法为空方法，使其不拷贝栈信息。

查询方法不建议抛出checked异常，否则调用 方在查询 时将过多的try...catch,并且不能进行有效处理。

服务提供方不应将DAO或者SQL等异常抛给消费方，应在服务实现中对消费方不关心的异常进行包装，否则可能出现消费方无法反序列化相应异常

必要的接口输入参数校验

在Provider上尽量多配置Consumer端属性:

原因如下:

作为服务的提供者，比服务使用方更清楚服务性能参数，如调用的超时时间，合理的重试次数，并发控制数量，负载均衡 ，等等

在Provider配置后，Consumer不配置则会使用Provider的配置值 ，

即Provider配置可以作为Comsumer的缺省值，否则，Consumer会使用Consumer端的全局设置，这对于Provider不可控的，并且往往是不合理的

Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题

样例:

启动时检查

(+) (#)

Dubbo缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止Spring初始化完成，以便上线时，能及早发现问题，默认check=true。

如果你的Spring容器是懒加载的，或者通过API编程延迟引用服务，请关闭check，否则服务临时不可用时，会抛出异常，拿到null引用，如果check=false，总是会返回引用，当服务恢复时，能自动连上。

可以通过check="false"关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。

关闭某个服务的启动时检查：(没有提供者时报错)

<dubbo:referenceinterface="com.foo.BarService"check="false"/>

例:

<!-- 调用账户服务 -->
<dubbo:reference interface="edu.pay.facade.account.service.AccountTransactionFacade" id="accountTransactionFacade" check="false" />
<dubbo:reference interface="edu.pay.facade.account.service.AccountQueryFacade" id="accountQueryFacade" check="false" />

关闭所有服务的启动时检查：(没有提供者时报错)

<dubbo:consumercheck="false"/>

关闭注册中心启动时检查：(注册订阅失败时报错)

<dubbo:registrycheck="false"/>

也可以用dubbo.properties配置：

dubbo.properties

dubbo.reference.com.foo.BarService.check=false

dubbo.reference.check=false

dubbo.consumer.check=false

dubbo.registry.check=false

也可以用-D参数：

java -Ddubbo.reference.com.foo.BarService.check=false

java -Ddubbo.reference.check=false

java -Ddubbo.consumer.check=false

java -Ddubbo.registry.check=false

注意区别

• dubbo.reference.check=false，强制改变所有reference的check值，就算配置中有声明，也会被覆盖。
• dubbo.consumer.check=false，是设置check的缺省值，如果配置中有显式的声明，如：<dubbo:reference check="true"/>，不会受影响。
• dubbo.registry.check=false，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。

引用缺省是延迟初始化的，只有引用被注入到其它Bean，或被getBean()获取，才会初始化。
如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：

<dubbo:referenceinterface="com.foo.BarService"init="true"/>

负载均衡

(+) (#)

在集群负载均衡时，Dubbo提供了多种均衡策略，缺省为random随机调用。

可以自行扩展负载均衡策略，参见：负载均衡扩展

Random LoadBalance

• 随机，按权重设置随机概率。
• 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。

权重加倍

RoundRobin LoadBalance

• 轮循，按公约后的权重设置轮循比率。
• 存在慢的提供者累积请求问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。

解决办法 :结合权重，把第二台机(性能低的)的权重设置低一点

LeastActive LoadBalance

• 最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差。
• 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。

ConsistentHash LoadBalance

• 一致性Hash，相同参数的请求总是发到同一提供者。
• 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
• 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing。
• 缺省只对第一个参数Hash，如果要修改，请配置<dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用160份虚拟节点，如果要修改，请配置<dubbo:parameter key="hash.nodes" value="320" />

Dubbo管理台配置负载均衡

权重调节

配置如：

<dubbo:serviceinterface="..."loadbalance="roundrobin"/>

或：

<dubbo:referenceinterface="..."loadbalance="roundrobin"/>

或：

<dubbo:serviceinterface="...">

    <dubbo:methodname="..."loadbalance="roundrobin"/>

</dubbo:service>

一般在实际项目我们配置权重或负载均衡时不在代码中写死，我们动态使用默认配置，需要调节时通过dubbo管控台上进行配置

或：

<dubbo:referenceinterface="...">

    <dubbo:methodname="..."loadbalance="roundrobin"/>

</dubbo:reference>