事情起因：當時接了個需求，開發過程中需要對工程A新增依賴工程B和工程C。 寫代碼，噼里啪啦噼里啪啦。。。 本地起了三個dubbo服務，其他服務依賴開發環境服務，非常開森改自己冒煙的bug。 提測！ 測試環境，工程A死活起不來，起到一半卡住！沒有任何異常！！！然后過了三分鍾 ...

使用了虛擬機之后，啟動了dubbo服務提供者應用,又連了正式環境的注冊中心； 一旦dubbo獲取的ip錯誤后， 這種情況即使提供者服務停掉，目前dubbo沒有能力清除這類錯誤的提供者； （需要修改源碼測試，需要客戶端重新更細包，因為清除動作client端，我司就是這么干的） 規避方案 ...

問題描述： zookepper服務是起在開發服務器192.168.23.180上。本機起應用服務提供者注冊到192.168.23.180上的dubbo服務可以注冊成功，用dubbo-admin看也是本機的IP:10.1.24.20。本機起的客戶端程序也可以正常調用 ...

在本地的一個案例中進行修改 修改微服務的相關pom文件修改每個微服務的pom文件，添加SpringCloud提供的基於Consul的依賴 注：由於我之前的代碼是注冊到eureka中，把配置注解要刪了，pom的依賴還在，啟動直接報錯，還是要去 ...

1.Dubbo支持哪些協議，每種協議的應用場景，優缺點？ dubbo： 單一長連接和NIO異步通訊，適合大並發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議TCP，異步，Hessian序列化； rmi： 采用JDK標准的rmi協議實現，傳輸參數和返回參數對象需要實現 ...

前言 微服務架構在如今的9102年已經不是什么新鮮的話題了，但是怎么做好微服務架構，卻又是一個永恆的話題。比如服務粒度的划分，怎么控制好粗細？服務划分后，對於項目的部署會有什么改變？... 這會是一個很大的話題，以后可以分開篇章探討一翻，但是我們本篇並不打算聊這個，而是討論一下具體的實現 ...

在使用dubbo注冊服務時會遇到IP解析錯誤導致無法正常訪問. 比如: 本機設置的IP為172.16.11.111, 但實際解析出來的是180.20.174.11 這樣就導致這個Service永遠也無法被訪問到, 而調用方一直報錯. 當然若發現服務無法訪問, 最好先通過dubbo-admin后台 ...

服務提供者使用主機名注冊到eureka改為使用ip注冊到eureka ...