引入

最近一直在研究rpc，或者說在學習使用一些框架，比如spring系列的有阿里的dubbo，springcloud等，實驗了一些奇怪的東西。雖然沒有看原始碼，但是大致瞭解了這些東西。自問自答吧。

在我們釋出服務的時候，一般會發佈一個api包，那麼通過這個jar包，伺服器是怎麼被客戶端呼叫的？

比如說在dubbo中

provider.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 

    xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!-- 提供方應用資訊，用於計算依賴關係 -->
 

    <dubbo:application name="hello-world-app"  />

    <!-- 使用multicast廣播註冊中心暴露服務地址 -->
    <dubbo:registry address="multicast://224.5.6.7:1234" />

    <!-- 用dubbo協議在20880埠暴露服務 -->
    <dubbo:protocol name="dubbo" port="20880" />

    <!-- 宣告需要暴露的服務介面 -->
    <dubbo:service
 
 interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />

    <!-- 和本地bean一樣實現服務 -->
    <bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />

</beans>

client.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"
    xsi:schemaLocation="http://www.springframework.org/schema/beans        http://www.springframework.org/schema/beans/spring-beans.xsd        http://code.alibabatech.com/schema/dubbo        http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

    <!-- 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方一樣 -->
    <dubbo:application name="consumer-of-helloworld-app"  />

    <!-- 使用multicast廣播註冊中心暴露發現服務地址 -->
    <dubbo:registry address="multicast://224.5.6.7:1234" />

    <!-- 生成遠端服務代理，可以和本地bean一樣使用demoService -->
    <dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

</beans>

通過以上我們可以看出，服務提供方需要暴露一個埠，監聽請求，客戶端會拿到這個埠，進行請求。而它們是通過註冊中心相互連線的。

在很久很久之前，在我還沒有註冊中心的概念的時候，知道的就是我這邊服務提供者提供服務和埠，那你客戶端還要每一次問我的最新地址，每一次遷移什麼的都麻煩死了。這個註冊中心就正好解決了這個問題。扯遠了，其實今天並不想說註冊中心的。。。話多 好吧

伺服器端

服務端做了什麼？
1. 監聽埠
2. 解析客戶端請求
3. 執行服務
4. 返回結果

好，差不多就是這個四步，什麼高可用，伺服器容災，算是擴充套件不算是原理的，。。。。
伺服器怎麼做呢
那麼先說一下我的理解吧
1. 開啟一個埠，確定暴露協議
開啟埠監聽請求毋庸置疑，那麼拿到請求了肯定需要解析請求，這樣就需要我們指定協議了。。
2. 掃描註冊的服務
例項化一個服務實現類，愛包裝就包裝，不包裝就直接通過反射實現，反正據我所知的在java中都是使用的反射實現的。
3. 返回結果
從上一步得到了結果，通過各種序列化後，自己選用協議，返回。。。。

客戶端

客戶端又稱為消費者 。。廢話
客戶端在請求的時候仍然會掃描它需要什麼藉口，據我發現，我司裡面的是掃描所有的api包的帶了某註解的介面，然後生成對應的代理類。
在dubbo中，我們可以看到是按需生成代理類，按需的好點的地方就是應用啟動的時候會變快，因為不用生成代理類啊。。。方法區也不會有溢位的風險，雖然現在還沒有在生產環境上見過由於代理導致的方法區溢位，但是還是需慎重啊。。。。
客戶端的就上面解釋完了。。。

1. 根據配置掃描api包或者從xml載入
2. 代理介面
   你不代理怎麼注入啊，你能注入介面嗎。。。當然最重要的原因是通過代理之後，我們每一次呼叫介面，我們的代理物件會幫助我們請求伺服器，然後返回伺服器的結果

其實通過很久的積澱已經可以解釋清楚了這些原理了。沉住氣，堅持下來還是有收穫的。