1. 從單體到分布式為什么要在 Spring 里引入 Dubbo很多做 Java 后端的同學(xué)第一次接觸分布式服務(wù)調(diào)用都是從“本地方法調(diào)用”直接跳到“遠(yuǎn)程調(diào)用”這個(gè)概念的。在單體應(yīng)用里Service A 調(diào) Service B就是一次普通的 Java 方法調(diào)用編譯器幫你把參數(shù)壓棧、把返回值帶回來(lái)整個(gè)過(guò)程在同一個(gè) JVM 里完成快得你根本感覺不到它的存在?？梢坏I(yè)務(wù)膨脹訂單、庫(kù)存、用戶、支付這些模塊各自獨(dú)立部署本地調(diào)用就徹底失效了——你沒法在一個(gè)進(jìn)程里 new 出另一個(gè)進(jìn)程的對(duì)象。這時(shí)候就需要一個(gè)“遠(yuǎn)程調(diào)用框架”來(lái)補(bǔ)位。Dubbo 就是干這個(gè)的它把“調(diào)用遠(yuǎn)程服務(wù)”這件事偽裝得跟“調(diào)用本地方法”幾乎一樣。你寫orderService.createOrder(...)底層其實(shí)經(jīng)歷了網(wǎng)絡(luò)傳輸、序列化、負(fù)載均衡、服務(wù)發(fā)現(xiàn)這一整套流程但對(duì)你來(lái)說(shuō)代碼寫起來(lái)跟本地調(diào)用沒區(qū)別。這就是 RPC遠(yuǎn)程過(guò)程調(diào)用框架的核心價(jià)值讓分布式調(diào)用對(duì)開發(fā)者透明。那為什么是 Spring 整合 Dubbo而不是單獨(dú)用 Dubbo因?yàn)?Spring 的 IOC 容器和 AOP 能力能把 Dubbo 的服務(wù)暴露和引用過(guò)程變成幾個(gè)注解或者幾行 XML 配置的事。你不用手動(dòng)去寫ServiceConfig、ReferenceConfig這些底層 APISpring 幫你管理 Bean 的生命周期Dubbo 幫你管理服務(wù)的注冊(cè)與發(fā)現(xiàn)。兩者結(jié)合才是生產(chǎn)環(huán)境里最常見的落地方式。這篇文章適合誰(shuí)看如果你已經(jīng)會(huì)寫 Spring Boot 或者 Spring MVC 的常規(guī)業(yè)務(wù)代碼但對(duì)“服務(wù)怎么拆出去”“消費(fèi)者怎么找到提供者”這些問題還比較模糊那這篇內(nèi)容就是給你準(zhǔn)備的。我會(huì)從零開始把 Spring 整合 Dubbo 的完整鏈路拆開包括依賴選型、配置細(xì)節(jié)、啟動(dòng)順序、常見報(bào)錯(cuò)以及我實(shí)際踩過(guò)的幾個(gè)坑。不堆概念只講能跑起來(lái)的代碼和能復(fù)現(xiàn)的排查思路。提示本文基于 Dubbo 2.7.x 與 Spring Boot 2.x 的整合場(chǎng)景展開這是目前存量項(xiàng)目里最主流的組合。如果你用的是 Dubbo 3.x核心思路一致但部分配置項(xiàng)和注冊(cè)中心行為有差異我會(huì)在對(duì)應(yīng)位置標(biāo)注。2. 動(dòng)手之前的選型賬注冊(cè)中心、協(xié)議與依賴版本2.1 注冊(cè)中心為什么首選 ZooKeeper 或 NacosDubbo 要工作必須有一個(gè)“服務(wù)注冊(cè)中心”。提供者啟動(dòng)時(shí)把自己的地址寫進(jìn)去消費(fèi)者啟動(dòng)時(shí)從里面讀出來(lái)這樣雙方才能建立連接。沒有注冊(cè)中心你就得手動(dòng)配置提供者的 IP 和端口一旦提供者擴(kuò)容或者遷移消費(fèi)者就得跟著改配置這在生產(chǎn)環(huán)境里是不可接受的。常見的注冊(cè)中心有兩個(gè)主流選擇ZooKeeper 和 Nacos。ZooKeeper 是 Dubbo 早期默認(rèn)的注冊(cè)中心基于 ZAB 協(xié)議保證一致性成熟穩(wěn)定很多老項(xiàng)目都在用。Nacos 是后來(lái)者除了服務(wù)注冊(cè)發(fā)現(xiàn)還集成了配置管理控制臺(tái)更友好支持臨時(shí)實(shí)例和持久實(shí)例的靈活切換。我個(gè)人的建議是新項(xiàng)目直接用 Nacos老項(xiàng)目如果已經(jīng)在用 ZooKeeper沒必要為了換而換。兩者的整合代碼差異很小主要就是依賴和配置地址不同。下面這張表可以幫你快速?zèng)Q策對(duì)比維度ZooKeeperNacos一致性協(xié)議ZABRaftCP DistroAP控制臺(tái)無(wú)原生UI需第三方自帶Web控制臺(tái)配置管理不支持原生支持健康檢查會(huì)話心跳心跳主動(dòng)探測(cè)適用場(chǎng)景存量老項(xiàng)目新項(xiàng)目、云原生環(huán)境2.2 依賴引入別小看這幾個(gè) artifactSpring 整合 Dubbo依賴引入是最容易出問題的地方。很多人直接抄網(wǎng)上的 pom結(jié)果啟動(dòng)就報(bào)NoSuchMethodError或者ClassNotFoundException根源就是版本沒對(duì)齊。核心依賴其實(shí)就三個(gè)dubbo-spring-boot-starterDubbo 官方提供的 Spring Boot 整合包封裝了自動(dòng)配置。dubboDubbo 核心包starter 會(huì)傳遞依賴進(jìn)來(lái)但有時(shí)需要顯式指定版本。注冊(cè)中心客戶端用 ZooKeeper 就引curator-framework和curator-recipes用 Nacos 就引nacos-client。這里有個(gè)細(xì)節(jié)Dubbo 2.7.x 的 starter 版本號(hào)要和 Dubbo 核心版本保持一致。比如你用dubbo-spring-boot-starter:2.7.8那dubbo也應(yīng)該是2.7.8。如果項(xiàng)目里還有其他依賴間接引入了不同版本的 Dubbo就會(huì)產(chǎn)生沖突。我習(xí)慣在 pom 里用dependencyManagement鎖定版本避免這種隱性沖突。dependencyManagement dependencies dependency groupIdorg.apache.dubbo/groupId artifactIddubbo-dependencies-bom/artifactId version2.7.8/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement注意Dubbo 2.7 之后groupId 從com.alibaba變成了org.apache如果你還在用老版本的com.alibaba.dubbo配置項(xiàng)前綴也是dubbo.而不是spring.dubbo.這個(gè)遷移坑很多人踩過(guò)。2.3 通信協(xié)議的選擇邏輯Dubbo 支持多種通信協(xié)議默認(rèn)是dubbo協(xié)議基于 Netty 的單一長(zhǎng)連接和 NIO 異步通信適合小數(shù)據(jù)量、高并發(fā)的服務(wù)調(diào)用。除此之外還有rmi、hessian、http等。為什么默認(rèn)用 dubbo 協(xié)議因?yàn)樗槍?duì)服務(wù)調(diào)用場(chǎng)景做了優(yōu)化單一長(zhǎng)連接減少了連接建立的開銷二進(jìn)制序列化比文本協(xié)議更緊湊異步通信提升了吞吐量。但如果你要調(diào)用的服務(wù)參數(shù)或返回值特別大比如傳輸大文件dubbo 協(xié)議的單一長(zhǎng)連接反而會(huì)成為瓶頸這時(shí)候可以考慮hessian協(xié)議它支持多連接和短連接。對(duì)于入門場(chǎng)景直接用默認(rèn)的 dubbo 協(xié)議就行不需要額外配置。等你遇到性能瓶頸或者跨語(yǔ)言調(diào)用需求時(shí)再考慮換協(xié)議。3. 提供者端把本地服務(wù)暴露成遠(yuǎn)程服務(wù)3.1 接口抽離為什么必須單獨(dú)建一個(gè) API 模塊這是新手最容易忽略的一步。提供者和消費(fèi)者要能互相調(diào)用雙方必須共享同一份接口定義。如果你把接口寫在提供者模塊里消費(fèi)者就得依賴提供者的整個(gè) jar 包這顯然不合理——消費(fèi)者可能只需要一個(gè)接口卻被迫引入了提供者的所有實(shí)現(xiàn)和依賴。正確的做法是單獨(dú)建一個(gè) API 模塊里面只放接口和傳輸對(duì)象DTO提供者和消費(fèi)者都依賴這個(gè)模塊。這樣消費(fèi)者編譯時(shí)只需要 API 模塊的 jar運(yùn)行時(shí)通過(guò) Dubbo 動(dòng)態(tài)代理調(diào)用遠(yuǎn)程實(shí)現(xiàn)。// api 模塊中的接口定義 public interface UserService { UserDTO getUserById(Long id); boolean register(UserDTO user); }這個(gè)接口里不要出現(xiàn)任何提供者特有的類比如數(shù)據(jù)庫(kù)實(shí)體、內(nèi)部工具類。DTO 也要盡量簡(jiǎn)單只包含需要傳輸?shù)淖侄尾⑶覍?shí)現(xiàn)Serializable接口——因?yàn)榭邕M(jìn)程傳輸需要序列化。3.2 服務(wù)實(shí)現(xiàn)與 DubboService 注解提供者端的服務(wù)實(shí)現(xiàn)類就是普通的 Spring Bean只不過(guò)要加上DubboService注解Dubbo 2.7.7 之后推薦用這個(gè)之前是Service但會(huì)和 Spring 的Service沖突。DubboService(version 1.0.0, timeout 3000) public class UserServiceImpl implements UserService { Autowired private UserMapper userMapper; Override public UserDTO getUserById(Long id) { User user userMapper.selectById(id); if (user null) { return null; } UserDTO dto new UserDTO(); dto.setId(user.getId()); dto.setName(user.getName()); return dto; } Override public boolean register(UserDTO user) { // 注冊(cè)邏輯 return true; } }這里有幾個(gè)關(guān)鍵參數(shù)需要解釋version服務(wù)版本號(hào)。當(dāng)同一個(gè)接口有多個(gè)實(shí)現(xiàn)時(shí)用版本號(hào)區(qū)分。消費(fèi)者引用時(shí)必須指定相同的版本號(hào)否則找不到服務(wù)。timeout調(diào)用超時(shí)時(shí)間單位毫秒。默認(rèn)是 1000ms但實(shí)際業(yè)務(wù)中數(shù)據(jù)庫(kù)查詢可能超過(guò)這個(gè)時(shí)間建議根據(jù)業(yè)務(wù)設(shè)置合理值。group服務(wù)分組用于隔離不同環(huán)境或不同業(yè)務(wù)線的服務(wù)。提示DubboService注解默認(rèn)會(huì)把服務(wù)注冊(cè)到所有配置的注冊(cè)中心。如果你有多個(gè)注冊(cè)中心可以用registry屬性指定。3.3 配置文件里的那些必填項(xiàng)提供者的application.yml里至少需要配置應(yīng)用名、注冊(cè)中心地址和協(xié)議端口dubbo: application: name: user-service-provider registry: address: nacos://127.0.0.1:8848 protocol: name: dubbo port: 20880 scan: base-packages: com.example.provider.service逐項(xiàng)說(shuō)明dubbo.application.name應(yīng)用名必須唯一。注冊(cè)中心里就是靠這個(gè)區(qū)分不同應(yīng)用的。dubbo.registry.address注冊(cè)中心地址。用 Nacos 就寫nacos://ip:port用 ZooKeeper 就寫zookeeper://ip:port。dubbo.protocol.portDubbo 服務(wù)暴露的端口。默認(rèn)是 20880如果一臺(tái)機(jī)器部署多個(gè)提供者端口會(huì)自增20880、20881...。生產(chǎn)環(huán)境建議顯式指定避免端口沖突。dubbo.scan.base-packages掃描DubboService注解的包路徑。不配這個(gè)注解不會(huì)被處理服務(wù)也不會(huì)暴露。我見過(guò)有人只配了注冊(cè)中心忘了配scan結(jié)果啟動(dòng)沒報(bào)錯(cuò)但消費(fèi)者就是調(diào)不到服務(wù)。排查了半天才發(fā)現(xiàn)是注解沒被掃描到。這個(gè)坑很隱蔽因?yàn)?Dubbo 不會(huì)主動(dòng)提示你“有注解沒掃描”。3.4 啟動(dòng)順序與注冊(cè)中心連接驗(yàn)證提供者啟動(dòng)時(shí)Dubbo 會(huì)做幾件事連接注冊(cè)中心、創(chuàng)建服務(wù)代理、把服務(wù)地址寫入注冊(cè)中心、啟動(dòng) Netty 監(jiān)聽端口。如果注冊(cè)中心連不上啟動(dòng)會(huì)失敗并拋出RpcException。啟動(dòng)成功后你可以去 Nacos 控制臺(tái)或者 ZooKeeper 客戶端里驗(yàn)證服務(wù)是否注冊(cè)成功。Nacos 的話在“服務(wù)管理-服務(wù)列表”里應(yīng)該能看到你的應(yīng)用名和對(duì)應(yīng)的實(shí)例地址。ZooKeeper 的話用ls /dubbo/com.example.api.UserService/providers命令查看。如果注冊(cè)中心里沒有你的服務(wù)按這個(gè)順序排查DubboService注解是否加在實(shí)現(xiàn)類上而不是接口上。dubbo.scan.base-packages是否覆蓋了實(shí)現(xiàn)類所在的包。注冊(cè)中心地址是否正確網(wǎng)絡(luò)是否連通。是否有多個(gè)注冊(cè)中心配置沖突。4. 消費(fèi)者端像調(diào)用本地 Bean 一樣調(diào)用遠(yuǎn)程服務(wù)4.1 DubboReference 的注入邏輯消費(fèi)者端要引用遠(yuǎn)程服務(wù)只需要在字段上加DubboReference注解RestController public class UserController { DubboReference(version 1.0.0, timeout 3000) private UserService userService; GetMapping(/user/{id}) public UserDTO getUser(PathVariable Long id) { return userService.getUserById(id); } }Spring 啟動(dòng)時(shí)Dubbo 會(huì)為這個(gè)字段生成一個(gè)動(dòng)態(tài)代理對(duì)象。當(dāng)你調(diào)用userService.getUserById(id)時(shí)代理對(duì)象會(huì)攔截調(diào)用從注冊(cè)中心獲取提供者地址列表經(jīng)過(guò)負(fù)載均衡選出一個(gè)提供者把方法名、參數(shù)類型、參數(shù)值序列化后通過(guò)網(wǎng)絡(luò)發(fā)送過(guò)去等待響應(yīng)后再反序列化返回結(jié)果。整個(gè)過(guò)程對(duì)開發(fā)者完全透明。你不需要寫任何網(wǎng)絡(luò)代碼也不需要手動(dòng)處理連接池。4.2 消費(fèi)者配置少即是多消費(fèi)者的配置比提供者更簡(jiǎn)單通常只需要應(yīng)用名和注冊(cè)中心地址dubbo: application: name: order-service-consumer registry: address: nacos://127.0.0.1:8848不需要配protocol因?yàn)橄M(fèi)者不暴露服務(wù)只發(fā)起調(diào)用。也不需要配scan因?yàn)镈ubboReference是在字段上Spring 處理 Bean 注入時(shí)就會(huì)處理。但有一個(gè)配置建議加上dubbo.consumer.checkfalse。默認(rèn)情況下消費(fèi)者啟動(dòng)時(shí)會(huì)檢查依賴的服務(wù)是否可用如果提供者還沒啟動(dòng)消費(fèi)者會(huì)啟動(dòng)失敗。在開發(fā)環(huán)境或者提供者啟動(dòng)較慢的場(chǎng)景下這個(gè)檢查很煩人。設(shè)為false后消費(fèi)者啟動(dòng)時(shí)不會(huì)檢查調(diào)用時(shí)如果服務(wù)不可用才會(huì)報(bào)錯(cuò)。dubbo: consumer: check: false timeout: 5000 retries: 2check啟動(dòng)時(shí)是否檢查服務(wù)可用性。timeout默認(rèn)調(diào)用超時(shí)時(shí)間可以被DubboReference上的配置覆蓋。retries失敗重試次數(shù)默認(rèn)是 2。注意重試只對(duì)冪等操作安全非冪等操作比如插入數(shù)據(jù)要設(shè)為 0否則可能重復(fù)插入。4.3 直連模式開發(fā)調(diào)試時(shí)的救命稻草有時(shí)候你只想本地調(diào)試不想啟動(dòng)注冊(cè)中心或者提供者還沒注冊(cè)到注冊(cè)中心。這時(shí)候可以用直連模式繞過(guò)注冊(cè)中心直接調(diào)用指定地址DubboReference(url dubbo://127.0.0.1:20880, version 1.0.0) private UserService userService;或者在配置里全局指定dubbo: reference: url: dubbo://127.0.0.1:20880直連模式在排查“是注冊(cè)中心問題還是服務(wù)本身問題”時(shí)特別有用。如果直連能調(diào)通說(shuō)明服務(wù)實(shí)現(xiàn)沒問題問題出在注冊(cè)中心如果直連也調(diào)不通那就是服務(wù)本身或者網(wǎng)絡(luò)的問題。注意直連模式只適合開發(fā)調(diào)試生產(chǎn)環(huán)境絕對(duì)不要用。因?yàn)橹边B繞過(guò)了服務(wù)發(fā)現(xiàn)提供者擴(kuò)容或遷移后消費(fèi)者無(wú)法感知。4.4 異步調(diào)用與泛化調(diào)用簡(jiǎn)介Dubbo 還支持異步調(diào)用消費(fèi)者發(fā)起調(diào)用后不阻塞等待結(jié)果而是通過(guò) Future 或者回調(diào)獲取。這在批量調(diào)用或者對(duì)響應(yīng)時(shí)間敏感的場(chǎng)景下很有用。配置方式是在DubboReference上加async true然后通過(guò)RpcContext.getContext().getFuture()獲取 Future 對(duì)象。泛化調(diào)用則是消費(fèi)者沒有 API 接口的情況下的兜底方案。比如你做一個(gè)網(wǎng)關(guān)需要調(diào)用各種未知的服務(wù)不可能為每個(gè)服務(wù)都引入 API 包。這時(shí)候可以用GenericService接口傳入方法名、參數(shù)類型和參數(shù)值Dubbo 會(huì)幫你完成調(diào)用。泛化調(diào)用的性能比正常調(diào)用略低因?yàn)樯倭司幾g期的類型檢查但靈活性極高。這兩個(gè)特性入門階段可以先了解等有具體需求時(shí)再深入。5. 聯(lián)調(diào)時(shí)最容易卡住的幾個(gè)環(huán)節(jié)5.1 服務(wù)找不到從注冊(cè)中心到網(wǎng)絡(luò)的全鏈路排查“No provider available for the service”是 Dubbo 最常見的報(bào)錯(cuò)。這個(gè)報(bào)錯(cuò)的意思是消費(fèi)者在注冊(cè)中心里找不到可用的提供者。排查要按鏈路走不要跳步。第一步確認(rèn)提供者是否真的注冊(cè)成功了。去注冊(cè)中心控制臺(tái)看服務(wù)列表里有沒有提供者的應(yīng)用名實(shí)例列表里有沒有具體的 IP 和端口。如果沒有回到提供者端排查DubboService和scan配置。第二步確認(rèn)消費(fèi)者和提供者連的是同一個(gè)注冊(cè)中心。這個(gè)聽起來(lái)很蠢但我確實(shí)見過(guò)有人提供者連的是測(cè)試環(huán)境的 Nacos消費(fèi)者連的是本地的 ZooKeeper兩邊完全不在一個(gè)頻道上。第三步確認(rèn)服務(wù)接口的全限定名、版本號(hào)、分組是否完全一致。消費(fèi)者寫version 1.0.0提供者寫version 1.0.1或者消費(fèi)者沒寫版本號(hào)而提供者寫了都會(huì)導(dǎo)致找不到服務(wù)。Dubbo 的匹配是精確匹配差一個(gè)字符都不行。第四步檢查網(wǎng)絡(luò)連通性。消費(fèi)者能不能 ping 通提供者的 IP提供者的端口是不是被防火墻攔了。Dubbo 默認(rèn)用 20880 端口有些公司的安全策略會(huì)封禁非標(biāo)準(zhǔn)端口。5.2 序列化異常實(shí)體類沒實(shí)現(xiàn) Serializable 的后果這個(gè)報(bào)錯(cuò)信息通常是org.apache.dubbo.remoting.RemotingException: Failed to invoke the method ... cause: java.io.NotSerializableException。原因很簡(jiǎn)單傳輸?shù)膶?duì)象沒有實(shí)現(xiàn)Serializable接口。Dubbo 默認(rèn)用 Hessian2 序列化它要求傳輸?shù)膶?duì)象必須可序列化。不僅是 DTO 本身DTO 里嵌套的所有對(duì)象也都要可序列化。我遇到過(guò)有人在 DTO 里放了一個(gè)java.util.DateDate 本身是可序列化的但它的子類java.sql.Timestamp在某些序列化器下會(huì)有問題。所以 DTO 里的字段類型盡量用基本類型和 String復(fù)雜類型要確認(rèn)序列化兼容性。另外如果 DTO 里有無(wú)參構(gòu)造函數(shù)之外的構(gòu)造函數(shù)但沒有保留無(wú)參構(gòu)造函數(shù)Hessian2 反序列化時(shí)也會(huì)失敗。因?yàn)榉葱蛄谢枰葎?chuàng)建實(shí)例再填充字段沒有無(wú)參構(gòu)造函數(shù)就沒法創(chuàng)建。5.3 超時(shí)與重試默認(rèn)參數(shù)在真實(shí)業(yè)務(wù)里的陷阱Dubbo 默認(rèn)超時(shí)是 1000ms默認(rèn)重試 2 次。這兩個(gè)默認(rèn)值在真實(shí)業(yè)務(wù)里經(jīng)常出問題。先說(shuō)超時(shí)。1000ms 對(duì)于簡(jiǎn)單的內(nèi)存操作夠用但一旦涉及數(shù)據(jù)庫(kù)查詢、遠(yuǎn)程緩存、第三方接口調(diào)用很容易超過(guò)。超時(shí)后消費(fèi)者會(huì)拋出TimeoutException然后觸發(fā)重試。如果提供者的業(yè)務(wù)邏輯已經(jīng)執(zhí)行了比如已經(jīng)扣了庫(kù)存但響應(yīng)因?yàn)榫W(wǎng)絡(luò)慢沒及時(shí)返回重試就會(huì)導(dǎo)致重復(fù)扣減。再說(shuō)重試。默認(rèn)重試 2 次加上首次調(diào)用一共 3 次。對(duì)于查詢操作重試是安全的還能提高成功率。但對(duì)于插入、更新、刪除操作重試就是災(zāi)難。所以我的習(xí)慣是所有非冪等的服務(wù)在DubboService或DubboReference上顯式設(shè)置retries 0。DubboService(version 1.0.0, timeout 5000, retries 0) public class OrderServiceImpl implements OrderService { // 下單邏輯絕對(duì)不能重試 }超時(shí)時(shí)間也要根據(jù)業(yè)務(wù)設(shè)置。我的經(jīng)驗(yàn)值是數(shù)據(jù)庫(kù)單表查詢?cè)O(shè) 3000ms復(fù)雜查詢?cè)O(shè) 5000ms調(diào)用第三方接口設(shè) 10000ms。不要全局設(shè)一個(gè)很大的值那樣一旦提供者真的掛了消費(fèi)者會(huì)長(zhǎng)時(shí)間阻塞拖垮整個(gè)調(diào)用鏈。5.4 啟動(dòng)順序?qū)е碌募偎垃F(xiàn)象在微服務(wù)架構(gòu)里服務(wù)之間有依賴關(guān)系。如果消費(fèi)者啟動(dòng)時(shí)提供者還沒啟動(dòng)消費(fèi)者會(huì)報(bào)“No provider available”然后啟動(dòng)失敗如果checktrue。但如果checkfalse消費(fèi)者能啟動(dòng)成功但第一次調(diào)用時(shí)會(huì)失敗。更隱蔽的情況是提供者啟動(dòng)了但還沒完成服務(wù)注冊(cè)消費(fèi)者就開始調(diào)用了。Dubbo 的服務(wù)注冊(cè)是異步的提供者啟動(dòng)完成后注冊(cè)中心的通知可能還有延遲。如果消費(fèi)者在這個(gè)窗口期發(fā)起調(diào)用就會(huì)失敗。解決辦法有兩個(gè)一是消費(fèi)者配置checkfalse并配合重試機(jī)制二是用 Dubbo 的lazy屬性延遲初始化。但最根本的還是要保證啟動(dòng)順序或者在網(wǎng)關(guān)層做健康檢查等所有依賴服務(wù)都就緒后再放流量進(jìn)來(lái)。6. 從能跑到好用幾個(gè)值得提前知道的優(yōu)化點(diǎn)6.1 服務(wù)分組與多版本并行當(dāng)同一個(gè)接口需要同時(shí)存在多個(gè)實(shí)現(xiàn)時(shí)比如灰度發(fā)布場(chǎng)景老版本和新版本要并行運(yùn)行這時(shí)候就需要用group和version來(lái)區(qū)分。// 提供者老版本 DubboService(version 1.0.0, group stable) public class UserServiceStableImpl implements UserService { } // 提供者新版本 DubboService(version 2.0.0, group gray) public class UserServiceGrayImpl implements UserService { } // 消費(fèi)者指定調(diào)用灰度版本 DubboReference(version 2.0.0, group gray) private UserService userService;這樣可以在不影響老用戶的情況下讓部分流量走新版本。等新版本驗(yàn)證穩(wěn)定后再把所有消費(fèi)者的配置切到新版本。6.2 本地偽裝與容錯(cuò)降級(jí)Dubbo 提供了mock機(jī)制當(dāng)遠(yuǎn)程調(diào)用失敗時(shí)可以返回一個(gè)本地偽裝的結(jié)果而不是直接拋異常。這在依賴服務(wù)不可用時(shí)能保證主流程不被阻塞。DubboReference(version 1.0.0, mock com.example.mock.UserServiceMock) private UserService userService;UserServiceMock需要實(shí)現(xiàn)UserService接口并提供一個(gè)無(wú)參構(gòu)造函數(shù)。當(dāng)遠(yuǎn)程調(diào)用失敗時(shí)Dubbo 會(huì)調(diào)用 Mock 類的對(duì)應(yīng)方法返回兜底數(shù)據(jù)。這個(gè)機(jī)制在秒殺、大促場(chǎng)景下特別有用。比如推薦服務(wù)掛了返回一個(gè)默認(rèn)的熱門列表總比整個(gè)頁(yè)面報(bào)錯(cuò)要好。6.3 監(jiān)控與治理的入口Dubbo 自帶了一個(gè)簡(jiǎn)單的監(jiān)控中心dubbo-monitor可以統(tǒng)計(jì)調(diào)用次數(shù)、成功率、響應(yīng)時(shí)間等指標(biāo)。雖然功能不如專業(yè)的 APM 系統(tǒng)但對(duì)于入門和中小項(xiàng)目來(lái)說(shuō)夠用了。配置方式是在提供者和消費(fèi)者都加上dubbo: monitor: protocol: registry這樣監(jiān)控?cái)?shù)據(jù)會(huì)通過(guò)注冊(cè)中心上報(bào)。啟動(dòng) dubbo-monitor 后可以在控制臺(tái)看到服務(wù)的調(diào)用統(tǒng)計(jì)。如果公司有 Prometheus Grafana 的監(jiān)控體系Dubbo 也支持通過(guò)dubbo-metrics-prometheus模塊暴露指標(biāo)接入現(xiàn)有的監(jiān)控大盤。6.4 線程模型與連接數(shù)控制Dubbo 默認(rèn)的線程模型是all即所有消息都派發(fā)到業(yè)務(wù)線程池。線程池默認(rèn)大小是 200隊(duì)列長(zhǎng)度是 0即不排隊(duì)直接拒絕。在高并發(fā)場(chǎng)景下這個(gè)配置可能導(dǎo)致請(qǐng)求被拒絕。如果服務(wù)大多是 CPU 密集型線程數(shù)可以設(shè)小一點(diǎn)比如 CPU 核數(shù) 1。如果是 IO 密集型線程數(shù)可以設(shè)大一點(diǎn)比如 500。隊(duì)列長(zhǎng)度建議設(shè)一個(gè)合理的值比如 1000避免瞬間流量直接打滿線程池。dubbo: protocol: threads: 500 queues: 1000連接數(shù)方面Dubbo 默認(rèn)是共享單一長(zhǎng)連接。如果提供者的服務(wù)處理時(shí)間較長(zhǎng)單一連接可能成為瓶頸?？梢酝ㄟ^(guò)connections參數(shù)增加連接數(shù)DubboReference(connections 10) private UserService userService;但連接數(shù)不是越多越好每個(gè)連接都會(huì)占用系統(tǒng)資源。一般建議根據(jù)壓測(cè)結(jié)果來(lái)調(diào)整不要盲目設(shè)大。7. 我踩過(guò)的三個(gè)真實(shí)坑與對(duì)應(yīng)解法第一個(gè)坑是注解沖突。早期 Dubbo 用Service注解暴露服務(wù)但 Spring 也有Service。我在同一個(gè)類上同時(shí)寫了兩個(gè)Service結(jié)果 Spring 把它當(dāng)成了普通 BeanDubbo 沒識(shí)別到服務(wù)一直注冊(cè)不上去。后來(lái)?yè)Q成DubboService才解決。如果你用的是 Dubbo 2.7.7 之前的版本要么用 XML 配置要么確保Service的包路徑是org.apache.dubbo.config.annotation.Service。第二個(gè)坑是泛型擦除導(dǎo)致的序列化問題。我在 DTO 里用了一個(gè)ListT字段運(yùn)行時(shí) T 被擦除成 ObjectHessian2 序列化時(shí)無(wú)法確定具體類型反序列化后變成了ListMap。消費(fèi)者拿到數(shù)據(jù)后強(qiáng)轉(zhuǎn)報(bào)ClassCastException。解決辦法是 DTO 里的集合字段盡量用具體類型比如ListUserDTO而不是ListT或者用JSONField之類的注解指定類型信息。第三個(gè)坑是注冊(cè)中心地址配了多個(gè)但只生效一個(gè)。我在dubbo.registry.address里寫了兩個(gè)地址用逗號(hào)分隔以為會(huì)同時(shí)注冊(cè)到兩個(gè)注冊(cè)中心。實(shí)際上 Dubbo 默認(rèn)只使用第一個(gè)可用的地址后面的作為備份。如果要同時(shí)注冊(cè)到多個(gè)注冊(cè)中心需要配置多個(gè)dubbo.registries節(jié)點(diǎn)并在DubboService上指定registry屬性。這個(gè)細(xì)節(jié)官方文檔里寫得很隱蔽我是看了源碼才搞明白。最后分享一個(gè)排查小技巧Dubbo 啟動(dòng)時(shí)會(huì)打印服務(wù)暴露和引用的日志把日志級(jí)別調(diào)到DEBUG可以看到服務(wù)注冊(cè)的詳細(xì)過(guò)程包括注冊(cè)中心地址、服務(wù)接口、版本號(hào)、分組等信息。如果服務(wù)找不到先看這些日志比盲目猜要快得多。logging: level: org.apache.dubbo: DEBUG這個(gè)配置在開發(fā)環(huán)境建議一直開著生產(chǎn)環(huán)境再調(diào)回INFO。