分布式的几件小事（六）dubbo如何作服务治理、服务降级以及重试

1.服务治理

服务治理主要做用是改变运行时服务的行为和选址逻辑，达到限流，权重配置等目的。
①调用链路自动生成
一个大型的分布式系统，会由大量的服务组成，那么这些服务之间的依赖关系和调用链路会很复杂，这就须要dubbo对多个服务之间的调用自动记录下来，生成一张图，显示出来。

②服务反复问压力以及时长统计
须要自动统计各个接口和服务之间的调用次数以及访问延时，并且要分红两个级别。一个级别是接口粒度，就是每一个服务的每一个接口天天被调用多少次，TP50，TP90，TP99，三个档次的请求延时分别是多少；第二个级别是从源头入口开始，一个完整的请求链路通过几十个服务以后，完成一次请求，天天全链路走多少次，全链路请求延时的TP50，TP90，TP99，分别是多少。
这些东西都搞定了以后，后面才能够来看当前系统的压力主要在哪里，如何来扩容和优化。

③服务分层
对服务的架构进行分层处理，好比Mapper负责接口映射，原子数据库操做。dao层负责数据访问，调用mapper，组装数据。service层负责对外提供dubbo服务，webservice层暴露接口等等，防止出现循环依赖的问题。

④调用链路失败的监控和报警
服务之间的调用链路可能会很长，那么就会存在出现失败的可能性很大，最好对调用链路进行监控，一旦出问题能保存本次调用链路失败的全链路日志，好作问题排查。
若是调用失败，或者超时了最好能进行报警，能够将报警发的邮件、钉钉群等里面，早点处理。

2.服务降级

好比服务A调用服务B，结果服务B挂掉了，服务A重试几回调用服务B，仍是没有响应，那么就会直接走降级逻辑，即走一个备用的逻辑，给调用者返回响应。

3.服务重试

①失败重试
consumer调用provider失败了，好比provider出现了异常，这时候就要进行重试。

②服务超时
好比某个服务的接口，要耗费5s，你这边不能干等着，你这边配置了timeout以后，我等待2s，还没返回，我直接就撤了，不能干等你。

若是是超时了，timeout就会设置超时时间；若是是调用失败了自动就会重试指定的次数。

<dubbo:reference id="xxxx" interface="xx" check="true" async="false" retries="3" timeout="2000"/>

timeout，通常设置为200ms，咱们认为不能超过200ms还没返回。

retries，3次，设置retries，还通常是在读请求的时候，好比你要查询个数据，你能够设置个retries，若是第一次没读到，报错，重试指定的次数，尝试再次读取2次。