一、问题
从这个问题开始，就会考察你dubbo在实际使用中的一些问题啦。
1、服务治理：这个问题如果问你，就是想看看你有没有服务治理的思想。因为这个是做过复杂微服务的人肯定会遇到的一个问题。
2、服务降级：这个是涉及到复杂分布式系统中必备的一个话题。因为分布式系统相互来回调用，任何一个系统崩溃了，你不降级，直接就全盘崩溃？那就太坑爹了。
3、失败重试：分布式系统中网络请求如此频繁，要是因为网络问题不小心失败了一次。是不是要重试？
4、超时重试：同上，如果不小心，网络满了一点，超时了，那如何重试。
二、服务治理
服务分的太多了。几百上千个服务。
1、调用链路自动生成
一个大型的分布式系统，或者用现在流行的话就微服务架构。分布式系统由大量的服务组成。那么这些服务之间是如何相互调用的？调用链路是啥？说实话，几乎到后面没人搞的清楚了。因为服务是在太多了，可能几百个甚至上千个。
那就需要基于dubbo的分布式系统中，对各个服务之间的调用自动记录下来。然后自动将各个服务之间的依赖关系和调用链路生成出来，做成一张图，显示出来。大家才可以看到。
2、服务访问压力以及时长统计
需要自动统计各个接口和服务之间的调用次数以及访问延迟,而且需要分成两个级别。第一个级别是接口粒度。就是每个服务的每个接口每天被调用多少次。TP50、TP90、TP99。三个档次的请求延时分别是多少； 第二个级别是从源头入口开始，一个完整的请求链路经过几十个服务之后，完成一次请求。每天全链路走多少次。全链路请求延时TP50、TP90、TP99，分别是多少？
这些东西都搞定了之后，后面才可以来看当前系统的压力在哪里？如何来扩容和优化啊？
三、服务降级
比如说，服务A调用服务B，结果服务B挂掉了。服务A重试几次调用服务B，还是不行。直接降级，走一个备用的逻辑。给用户返回相应。
基于mock，在consumer端，模拟一个数据，返回给用户。
三、失败重试和超时重试