帶你手寫基於 Spring 的可插拔式 RPC 框架（一）介紹

目錄：
帶你手寫基於 Spring 的可插拔式 RPC 框架（一）介紹
帶你手寫基於 Spring 的可插拔式 RPC 框架（二）總體結構
帶你手寫基於 Spring 的可插拔式 RPC 框架（三）通訊協議模塊
帶你手寫基於 Spring 的可插拔式 RPC 框架（四）代理類的注入與服務啓動
帶你手寫基於 Spring 的可插拔式 RPC 框架（五）註冊中心

源碼在第五篇博客的末尾

概述

首先這篇文章是要帶你們來實現一個框架，聽到框架你們可能會以爲很是高大上，其實這和咱們平時寫業務員代碼沒什麼區別，可是框架是要給別人使用的，因此咱們要換位思考，怎麼才能讓別人用着舒服，怎麼樣才能讓咱們的框架性能優異。經過本身寫一個框架，咱們能學到的有不少，能讓咱們脫離 CURD，在更高的層面上去思考。

目的

寫這個框架最主要的目的是要讓你們瞭解整個框架的設計思想和用到的技術，並非讓你們關注代碼，固然我實現的代碼必定不是完美的，還有不少須要改進的地方，但願你們不吝賜教，一塊兒進步。

提早準備

若是把全部細節給你們講清楚，那徹底能夠出一本書了。咱們的文章固然也會將細節，不過但願你們有一些知識儲備，這樣咱們才能重點去關注設計思想，瞭解如何去設計這個 RPC 框架，把本身想不通的地方給想明白了。

提早學習的知識

1. Netty 框架，但願你們對這個框架有個基礎的瞭解，可以編寫簡單的客戶端服務端通訊的 Demo，若是沒學過能夠臨時補一下。傳送門->Netty
2. 動態代理，其實不只僅是動態代理，基本的設計模式是每一個程序員必備的，而動態代理使用的又很是普遍，你們至少要對動態代理的概念有所瞭解。
3. Dubbo 的使用經歷，若是你用過 Dubbo 的話對於理解咱們接下來的文章有很大的幫助。

解決了什麼問題

這個框架到底解決了什麼問題？咱們在什麼場景下須要使用這個框架那？咱們先來了解一個概念。
微服務架構
微服務架構旨在將原來傳統的單體的 web 程序進行解耦，按功能進行劃分，將原來的大應用拆分紅一個一個小的服務。這樣很大程度上提升了整個系統的可伸縮行，能夠高效的應對各類各樣的併發和數據壓力。
來看官方定義：
一、一些由獨立的服務共同組成系統
二、單獨部署，跑在本身的進程中
三、每一個服務爲獨立的業務開發
四、分佈式管理
五、很是強調隔離性

微服務已經成爲目前互聯網公司的標配了，使用微服務時咱們須要思考一個問題，原來是在一個程序內，如今被拆分紅不一樣的程序，並且頗有可能部署在不一樣的服務器上。那麼服務之間如何通訊那？

RPC
RPC 是一種遠程調用協議，他能夠高效準確的完成服務之間的相互調用，並且最重要的是用戶不須要關心 RPC 協議的底層實現，網絡傳輸使用 Http，Netty，仍是 Socket 均可以。
有人可能會有疑問，我用 http 請求，裏面寫上目標的 ip，端口，加上參數不是也能調用服務而且返回數據嗎？爲何要引入 RPC 這個概念那？

若是你能思考到這，說明你已經很厲害了，懂得在使用工具時思考爲何。
對於直接使用 http 請求來講，適合接口較少，服務之間相互調用很少的狀況，並且須要指定地址，端口等等信息。優勢就是簡單直接，可是沒法應對高併發以及複雜服務交互的狀況。
RPC 就是爲了解決上面的問題而生的，首先用戶只須要調用服務便可，鏈接和發送數據交給底層協議去完成，另外對於高併發支持很是好，另外提供服務治理，註冊中心等功能。適合大型網站，服務複雜，高併發的狀況。

從一個點看 RPC 的架構
使用過 Dubbo 等 RPC 框架的應該知道，咱們能夠像調用本地方法同樣調用另外一個服務器上的服務，有的人可能不明白這句話時什麼意思，代碼演示一下。

UserService 是另外一個服務器上的服務，咱們能夠像調用本地方法同樣調用，不用管底層協議，不夠用管 UserService 在哪一個服務器上。

UserService userService = ProxyFactory.getProxy(UserService.class);
User user = userService.get("11112");

那麼咱們是如何把在另一個服務器上的服務拿到咱們本地來的那？有人看上面的 ProxyFactory 可能就已經猜出來了，使用的是動態代理，咱們在本地獲取到了接口的代理類，在 invoke 方法中將參數傳給對應的服務，服務端在接收到數據後，使用反射調用對應的實現類，完成處理後將結果返回給調用端。

若是你不明白上面的解釋，咱們用一張圖來解釋這個過程：

簡單點說，RPC 幫咱們把對應的請求發過去，服務端有一個服務器一直接收這種請求，收到數據後調用服務對應的處理方法處理後返回給調用端。