目錄：
帶你手寫基於 Spring 的可插拔式 RPC 框架（一）介紹
帶你手寫基於 Spring 的可插拔式 RPC 框架（二）整體結構
帶你手寫基於 Spring 的可插拔式 RPC 框架（三）通信協議模塊
帶你手寫基於 Spring 的可插拔式 RPC 框架（四）代理類的注入與服務啟動
帶你手寫基於 Spring 的可插拔式 RPC 框架（五）注冊中心
源碼在第五篇博客的末尾
概述
首先這篇文章是要帶大家來實現一個框架，聽到框架大家可能會覺得非常高大上，其實這和我們平時寫業務員代碼沒什么區別，但是框架是要給別人使用的，所以我們要換位思考，怎么才能讓別人用着舒服，怎么樣才能讓我們的框架性能優異。通過自己寫一個框架，我們能學到的有很多，能讓我們脫離 CURD，在更高的層面上去思考。
目的
寫這個框架最主要的目的是要讓大家了解整個框架的設計思想和用到的技術，並不是讓大家關注代碼，當然我實現的代碼一定不是完美的，還有很多需要改進的地方，希望大家不吝賜教，一起進步。
提前准備
如果把所有細節給大家講清楚，那完全可以出一本書了。我們的文章當然也會將細節，不過希望大家有一些知識儲備，這樣我們才能重點去關注設計思想，了解如何去設計這個 RPC 框架，把自己想不通的地方給想明白了。
提前學習的知識
- Netty 框架，希望大家對這個框架有個基礎的了解，能夠編寫簡單的客戶端服務端通信的 Demo，如果沒學過可以臨時補一下。傳送門->Netty
- 動態代理，其實不僅僅是動態代理，基本的設計模式是每個程序員必備的，而動態代理使用的又非常廣泛，大家至少要對動態代理的概念有所了解。
- Dubbo 的使用經歷，如果你用過 Dubbo 的話對於理解我們接下來的文章有很大的幫助。
解決了什么問題
這個框架到底解決了什么問題？我們在什么場景下需要使用這個框架那？我們先來了解一個概念。
微服務架構
微服務架構旨在將原來傳統的單體的 web 程序進行解耦，按功能進行划分，將原來的大應用拆分成一個一個小的服務。這樣很大程度上提高了整個系統的可伸縮行，可以高效的應對各種各樣的並發和數據壓力。
來看官方定義：
1、一些由獨立的服務共同組成系統
2、單獨部署，跑在自己的進程中
3、每個服務為獨立的業務開發
4、分布式管理
5、非常強調隔離性
微服務已經成為目前互聯網公司的標配了，使用微服務時我們需要思考一個問題，原來是在一個程序內，現在被拆分成不同的程序，而且很有可能部署在不同的服務器上。那么服務之間如何通信那？
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 幫我們把對應的請求發過去，服務端有一個服務器一直接收這種請求，收到數據后調用服務對應的處理方法處理后返回給調用端。