接着前面的说，前两篇中分析了解析和动态服务列表的获取，这两步完成后那接下来要做的事就是重组解析后的URL路径和发起通信了，这一步完成应该是在前面分析的RibbonLoadBalancerClient.execute方法中接着往下走
从Debugger中可以看到这个request返回的是LoadBalancerRequestFactory并且是一个lambda表达式,打开进去看过后发现他返回的是一个LoadBalancerRequest，并且里面有ServiceRequestWrapper包装器增加了请求，包装完成后由execution.execute(serviceRequest, body);执行返回一个ClientHttpResponse对象传给LoadBalancerRequestFactory，所以我们要进入LoadBalancerRequestFactory里面
进入后发现 apply方法是LoadBalancerRequest接口中的一个方法，且LoadBalancerRequest接口没有实现类，那么apply方法的实现是在哪里实现的呢？
竟然没有实现那就只能回退看它的内部类是怎么实现的
点击execute方法进入第一个if判断是前面执行的一个拦截，这个拦截是上篇中说的LoadBalancerInterceptor的拦截，这次的拦截进入的是else逻辑中，在else逻辑中可以看到最终会进行一个调用，在调用的过程中他会执行一个
equestFactory.createRequest(request.getURI(), method);这里面的request我们已经很清楚是怎么来的了，但这里面的getURI是啥玩意还不清楚，所以可以进去看下
进入ServiceRequestWrapper的getURI()方法，至于为什么是ServiceRequestWrapper的URI这个应该就不用解析了吧，那是因为request是由前面的ServiceRequestWrapper传的
走到这里可以再Debugger再看下，从结果可以很清楚看到URL路径得到了重构，
点击reconstructURI进入重构逻辑
