具體錯誤示例如下
從錯誤看,是客戶方發起調用時,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端口依然對外可用(也就是服務),如果此時有流量進來發起調用,就會拋出上面的異常了