具體錯誤示例如下
從錯誤看，是客戶方發起調用時，dubbo會去檢查本地的invoker instance，如果發現invoker已經是destroy status，則直接拋出上面的異常，下面先來說下平台部小伙伴曾遇到過的此異常情況
平台部小伙伴用springboot包裝了一個dubbo的starter出來
該starter大多是基於注解的，如果同時在多個地方去實列化引用同一個遠程服務的實列，就會出現此錯誤，究其原因，是因為spring在多次重復實列化時，會先去檢查容器中是否已有相同的class實列存在，如果有，會先銷毀舊，再去實列化一個新的，在銷毀時會調用AbstractInvoker中的destroy方法。導致destroy屬性被至為true，下面來看下該class的UML圖
從上圖可以看出，該Invoker是所有invoker的頂級父類所有的調用都會經過這里，但是任何對象的銷毀也都會調用該類的destroy方法，到此我們可以來說說最上面的問題了，上面的問題都是在發布的時候才出現，分析原因最大可能是運維GG在stop服務前，沒有將其從nginx上摘除，在停服務的過程中，要先進行資源的銷毀，但是此時8080端口依然對外可用(也就是服務)，如果此時有流量進來發起調用，就會拋出上面的異常了