接著前面的說，前兩篇中分析瞭解析和動態服務列表的獲取，這兩步完成後那接下來要做的事就是重組解析後的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進入重構邏輯
