今天給大家講一個知識點，就是平時我們很多兄弟開發的系統都不再是那種 10 年前的簡單單塊系統了，一個工程打包部署啟動，系統連接 MySQL，然后 Crud 整起就夠的了，我們現在開發的系統都是很高大上的分布式系統。

啥叫分布式系統?

就是說你寫的系統收到一個請求之后，你自己的代碼跑完還不夠，你得去調用別的兄弟寫的系統，讓他的系統也干一些事兒，然后他的活兒也干完了之后，你這次請求處理才算是完事兒了。

就因為你處理請求得調用別的兄弟系統一起運行，一個請求涉及到了分布在多臺機器上的多個系統，所以就叫做分布式了。

如下圖：

分布式系統之間如何調用呢?

那現在兄弟們平時開發分布式系統，就是去調用別的系統，一般都是用什么框架呢?

簡單，現在兄弟們一般都是用 SpringCloud，或者是用 Dubbo，這兩種都有人用，用 SpringCloud 的一般前兩年多一些，最近這兩年大家都紛紛轉用 SpringCloud Alibaba 了。

以前用 SpringCloud 的時候，你要調用別的系統一般用的是 Feign 這個框架，然后現在你用 SpringCloud Alibaba 的時候，一般用的都是 Dubbo 這個框架，我們今天就以 Dubbo 這個框架舉例來講講我們平時系統之間是如何進行調用的。

首先呢，我們還是看上面那個圖里的業務系統 B，這個系統如果要提供接口給別人調用，那么他必須寫一個接口，這個接口里得定義好你要允許別人調用哪些方法，大致看起來可能類似下面這樣的代碼。

如下：

public interface Service {  
    String sayHello(String name);   
}

接著呢，你得針對這個接口開發一個實現類，實現類里需要完成這個方法的邏輯，同時還得給這個實現類加上@DubboService這個注解，讓Dubbo把他識別為一個對外的服務接口，如下面的代碼：
@DubboService(version = "1.0.0", interfaceClass = Service.class)
public class ServiceImpl implements Service {    
    public String sayHello(String name) {   
        // 運行一些代碼    
      return "hello, " + name;   }  

}

那么當你的業務系統 B 開發好上面的接口和實現類，同時加上了 @DubboService 這個注解之后，這個業務系統 B 啟動以后，會干一個什么事兒呢?

簡單來說，Dubbo 框架會隨著你的業務系統 B 一起啟動，他會啟動一個網絡服務器，這個網絡服務器會監聽一個你指定的端口號，通常這個端口號是 20880 端口。

如下圖：

這個時候業務系統 B 上的 Dubbo 已經啟動好了網絡服務器監聽了一個端口號，隨時可以接收你發送過來的調用請求。

接下來就輪到咱們的業務系統 A 出場了，這個業務系統 A 假設要調用業務系統 B 的 Service 接口中定義的那些方法，他會怎么做呢?

這個代碼大概會是這樣的：

@RestController 
public class Controller {  
    // 注意，這里的Service就是業務系統B定義的接口     
    @DubboReference(version = "1.0.0")  
    private Service service;    


    @RequestMapping("/hello")  
    public Response sayHello(String name) {          
        String result = service.sayHello(name);    
        return Response.success(result);   }    
}

所以說，這里最關鍵的問題來了，上面是業務系統 A 的代碼，他僅僅是定義了一個業務系統 B 的 Service 接口的變量。

就是 Service service 這個變量，然后加了一個 @DubboReference 注解，所以這個業務系統 A 啟動的時候，Dubbo 又會干點什么事兒呢?

Dubbo 是如何基于動態代理實現 RPC 調用的

其實這里有一個很重點的點，那就是 Dubbo 此時會使用我們設計模式里的代理模式，去創建一個動態代理對象，把這個動態代理對象注入給我們上面的 Service service 這個變量，讓他那個變量引用 Dubbo 的動態代理對象。

那么這個動態代理對象是個什么東西呢?簡單來說，就是 Dubbo 可以動態生成一個類，這個類是實現了 Service 接口的，然后所有的方法都是有他自己的一套實現邏輯的。

具體什么實現邏輯一會兒我們再說，但是現在看起來應該如下圖：

所以這里其實很關鍵的一點是，大家一定要在這里理解這個 Dubbo 動態代理的概念，這是設計模式中代理模式一個很經典的運用。

就是說，一旦 Dubbo 生成了針對接口的動態代理對象，注入給了 Service service 這個變量，那么你業務系統 A 里調用 Service service 的方法時，其實是會調用 Dubbo 動態代理對象的方法的。

再看一下代碼感受一下：

@RestController 
public class Controller {     

    // 注意，這里的Service就是業務系統B定義的接口   
    // 這個接口變量其實會被注入Dubbo生成的動態代理對象     
    @DubboReference(version = "1.0.0")   
    private Service service;   

    @RequestMapping("/hello")   
    public Response sayHello(String name) { 
        // 注意，這里你調用接口方法的時候，其實是在調用Dubbo動態代理對象的方法   
        String result = service.sayHello(name);    
     return Response.success(result);
    }  

}

接著 Dubbo 動態代理對象的方法被調用的時候，他會干什么事情呢?

其實這里他就會跟我們的業務系統 B 所在的機器建立一個網絡連接，然后通過這個網絡連接把一個調用請求發送過去。

業務系統 B 里面的 Dubbo 網絡服務器收到請求之后，就會根據請求調用本地的接口實現類的方法，拿到返回值，接著通過網絡連接把返回值返回給業務系統 A 的 Dubbo 動態代理對象，最后，Dubbo 動態代理對象就會把這個返回值交給我們了。

如下圖：

好了，今天給大家分享的基于 Dubbo 實現系統間調用的原理就到這里了，希望大家平時用 Dubbo 做開發的時候，對他底層的原理也得有一定的理解。