第一章
1：協(xié)議端口
<!-- dubbo應用的名稱 -->
<dubbo:application name="dubbo-02-provider"/>
<!-- protocol是協(xié)議的意思，這里采用是dubbo的協(xié)議，默認的端口號是20880 -->
<dubbo:protocol name="dubbo" port="20880"/>
補充說明1：
顯示指定Dubbo服務啟動的端口號：一個服務器上起多個Provider都這樣顯示的指定port端口號的話，會造成端口號沖突。
解決方式：我們可以port設置為-1，服務啟動時默認采用20880（dubbo協(xié)議默認端口），此端口被占用默認會+1，一直到加端口不占用為止。強烈建立端口號設置為-1
<!-- protocol是協(xié)議的意思，這里采用是dubbo的協(xié)議，默認的端口號是20880 -->
<dubbo:protocol name="dubbo" port="-1"/>
2：第一個程序運行過程淺析
從形象和概念上進行一個分析，源碼后續(xù)在進行分析~
解釋說明1：
提供者里邊我們編寫了一個Service層之后，基xml里邊的配置暴露Dubbo服務，真正將一個Service發(fā)布成一個Dubbo服務的是<dubbo:service/>這個標簽。為暴露出來的服務齊了一個名字，指定了通信的協(xié)議和端口號。
消費者當中也配置了dubbo服務的名稱。通過<dubbo:reference>指定了PRC的接口和對象id，并將此對象交由Spring工廠進行管理。同時也指定了所發(fā)布的提供者的UserService的URL。
消費者和提供者之間進行通信是跨越JVM實例通信的，是一種跨進程通訊，這種通訊方式一定是走網(wǎng)絡通信的。所以，我們的URL當中包含了提供者暴露的Dubbo服務的IP、端口號、協(xié)議、具體的接口的全限定名稱，它具體漲這個樣子
<dubbo:reference interface="com.suns.service.UserService" id="userService"
url="dubbo://192.168.8.1:20880/com.suns.service.UserService"/>
分析到這里，我們可以看到概念上，我們整個流程是通的。
3：兩個問題
問題分析1：
為什么提供者提供了UserService的實現(xiàn)，在另外一個虛擬機的消費者當中可以記性調用呢？消費者當中調用的到底是什么？
并沒有直接調用遠端JVM實例當中的UserServiceImpl，實際上是調用的是UserServiceImpl的代理對象 Proxy，這個代理對象是在消費者的JVM實例當中的。這個對象是從消費者的JVM實例當中的Spring工廠獲取的。比如：($Proxy20@4109)是基于JDK的動態(tài)代理的方式創(chuàng)建的，他是基于Proxy.newProcyInstance();
問題分析2：
代理的核心工作是什么呢？
代理設計模式在Java開發(fā)中是廣泛使用的。代理仿佛就是一個偉大而又理想的中間商，讓你更好的去訪問后續(xù)的內容。消費者和實際的消費對象之間是割裂的，被代理對象所連接。
代理對象被Consumer實際調用，對consumer屏蔽了網(wǎng)絡的通信過程(通信方式 協(xié)議 序列化)，最后通過代理傳遞通信的數(shù)據(jù)。
通信必須得有對方的地址，所以代理對象當中必須得有一個URL文章來源：http://www.zghlxwxcb.cn/news/detail-613601.html
文章來源地址http://www.zghlxwxcb.cn/news/detail-613601.html
到了這里，關于干翻Dubbo系列第四篇：Dubbo3第一個應用程序細節(jié)補充的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
