服务治理
服务降级，这个是涉及到复杂分布式系统中必备的话题，因为分布式系统互相来回调用，任何一个系统故障了，你不降级，直接就全盘崩溃？
失败重试，分布式系统中网络请求如此频繁，要是因为网络问题不小心失败了一次，是不是要重试？
超时重试，同上，如果不小心网络慢一点，超时了，如何重试？
(1). 服务治理
调用链路自动生成
一个大型的分布式系统，或者说是用现在流行的微服务架构来说，分布式系统由大量的服务组成。那么这些服务之间互相是如何调用的？调用链路是啥？说实话，几乎到后面没人搞清楚了，因为服务
那就需要基于Dubbo做的分布式系统中，对各个服务之间的调用自动记录下来，然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图，显示出来，大家才可以看到是吧。
服务访问压力以及时长统计
需要自动统计各个接口和服务之间的调用次数以及访问延时，而且要分成两个级别。一个级别是接口粒度，就是每个服务的每个接口每天被调用多少次，TP50，TP90，TP99，三个档次分别是多少；第二个级别是从源头开始，一个完整的请求链路经过几十个服务之后，完成一次请求，每天全链路走多少次，全链路请求延时的TP50，TP90，TP99，分别是多少。
TP=Top Percentile，Top百分位数
TP指标: 指在一个时间段内，统计该方法每次调用所消耗的时间，并将这些时间按从小到大的顺序进行排序, 并取出结果为 ： 总次数 * 指标数 = 对应TP指标的序号 ， 再根据序号取出对应排序好的时间，即为TP指标。
这些东西都搞定了以后，后面才可以来看当前系统的压力主要在哪里，如何来扩容和优化。
(2). 服务降级
比如说服务A调用服务B，结果服务B挂掉了，服务A重试几次调用服务B，还是不行，直接降级，走备用的逻辑，给用户返回响应。
(3). 失败重试和超时重试
所谓的失败重试，就是consumer调用provider要是失败了，比如抛异常了，此时应该是可以重试的，或者调用超时了也可以重试。
<dubbo:reference id=“xxxx” interface=“xx” check=“true” async=“false” retries=“3” timeout=“2000”/>
某个服务的接口，要耗时5s，你这边不能干等着，你这边配置了timeout之后，我等待2s，还没返回，我就直接撤了，不能干等你。
如果是超时了，timeout就会设置超时时间，如果是调用失败了自动就会重试指定的次数。
说说你是怎么设置这些参数的，timeout，一般设置为200ms，我们认为不能超过200ms还没返回。
retries，3次，设置retries，还一般是在读请求的时候，比如说你要查询个数据，你可以设置retries，如果第一次没读到，报错，重试指定的次数，尝试再次读取2次。
