聲明
本文轉自
https://developer.51cto.com/art/201906/597963.htm什麼是RPC
RPC（Remote Procedure Call）：遠端過程調用，它是一種通過網絡從遠端計算機程式上請求服務，而不需要了解底層網絡技術的思想。
RPC 是一種技術思想而非一種規範或協定，常見 RPC 技術和架構有：
- 應用級的服務架構：阿裡的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
- 遠端通信協定：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
- 通信架構：MINA 和 Netty。
目前流行的開源 RPC 架構還是比較多的，有阿裡巴巴的 Dubbo、Facebook 的 Thrift、Google 的 gRPC、Twitter 的 Finagle 等。
常用的RPC架構
- gRPC：是 Google 公布的開源軟體，基于最新的 HTTP 2.0 協定，并支援常見的衆多程式設計語言。RPC 架構是基于 HTTP 協定實作的，底層使用到了 Netty 架構的支援。
- Thrift：是 Facebook 的開源 RPC 架構，主要是一個跨語言的服務開發架構。 使用者隻要在其之上進行二次開發就行，應用對于底層的 RPC 通訊等都是透明的。不過這個對于使用者來說需要學習特定領域語言這個特性，還是有一定成本的。
- Dubbo：是阿裡集團開源的一個極為出名的 RPC 架構，在很多網際網路公司和企業應用中廣泛使用。協定和序列化架構都可以插拔是極其鮮明的特色。
完整的 RPC 架構
在一個典型 RPC 的使用場景中，包含了服務發現、負載、容錯、網絡傳輸、序列化等元件，其中“RPC 協定”就指明了程式如何進行網絡傳輸和序列化。
圖 1：完整 RPC 架構圖
如下是 Dubbo 的設計架構圖，分層清晰，功能複雜：
圖 2：Dubbo 架構圖
RPC 核心功能
RPC 的核心功能是指實作一個 RPC 最重要的功能子產品，就是上圖中的”RPC 協定”部分：
圖 3：RPC 核心功能
一個 RPC 的核心功能主要有 5 個部分組成，分别是：用戶端、用戶端 Stub、網絡傳輸子產品、服務端 Stub、服務端等。
圖 4：RPC 核心功能圖
下面分别介紹核心 RPC 架構的重要組成：
- 用戶端（Client）：服務調用方。
- 用戶端存根（Client Stub）：存放服務端位址資訊，将用戶端的請求參數資料資訊打包成網絡消息，再通過網絡傳輸發送給服務端。
- 服務端存根（Server Stub）：接收用戶端發送過來的請求消息并進行解包，然後再調用本地服務進行處理。
- 服務端（Server）：服務的真正提供者。
- Network Service：底層傳輸，可以是 TCP 或 HTTP。
Python 自帶 RPC Demo
Server.py：
fromSimpleXMLRPCServer importSimpleXMLRPCServer
deffun_add(a,b):
totle = a + b
returntotle
if__name__ == '__main__':
s = SimpleXMLRPCServer(( '0.0.0.0', 8080)) #開啟xmlrpcserver
s.register_function(fun_add) #注冊函數fun_add
print"server is online..."
s.serve_forever #開啟循環等待
Client.py：
fromxmlrpclib importServerProxy #導入xmlrpclib的包
s = ServerProxy( "http://172.171.5.205:8080") #定義xmlrpc用戶端
prints.fun_add( 2, 3) #調用伺服器端的函數
開啟服務端：
開啟用戶端：
Wireshark 抓包分析過程
用戶端去往服務端：
- 用戶端 IP：172.171.4.176
- 服務端 IP：172.171.5.95
通信使用 HTTP 協定，XML 檔案傳輸格式。傳輸的字段包括：方法名 methodName，兩個參數 2，3。
圖 5：Request 抓包
服務端傳回結果，字段傳回值 Value，結果是 5：
圖 6：Response 抓包
在這兩次網絡傳輸中使用了 HTTP 協定，建立 HTTP 協定之間有 TCP 三次握手，斷開 HTTP 協定時有 TCP 四次揮手。
圖 7：基于 HTTP 協定的 RPC 連接配接過程
詳細調用過程
Python 自帶 RPC 的 Demo 小程式的實作過程，流程和分工角色可以用下圖來表示：
圖 8：RPC 調用詳細流程圖
一次 RPC 調用流程如下：
- 服務消費者（Client 用戶端）通過本地調用的方式調用服務。
- 用戶端存根（Client Stub）接收到調用請求後負責将方法、入參等資訊序列化（組裝）成能夠進行網絡傳輸的消息體。
- 用戶端存根（Client Stub）找到遠端的服務位址，并且将消息通過網絡發送給服務端。
- 服務端存根（Server Stub）收到消息後進行解碼（反序列化操作）。
- 服務端存根（Server Stub）根據解碼結果調用本地的服務進行相關處理
- 服務端(Server)本地服務業務處理。
- 處理結果傳回給服務端存根（Server Stub）。
- 服務端存根（Server Stub）序列化結果。
- 服務端存根（Server Stub）将結果通過網絡發送至消費方。
- 用戶端存根（Client Stub）接收到消息，并進行解碼（反序列化）。
- 服務消費方得到最終結果。
RPC 核心之功能實作
RPC 的核心功能主要由 5 個子產品組成，如果想要自己實作一個 RPC，最簡單的方式要實作三個技術點，分别是：
- 服務尋址
- 資料流的序列化和反序列化
- 網絡傳輸
服務尋址可以使用 Call ID 映射。在本地調用中，函數體是直接通過函數指針來指定的，但是在遠端調用中，函數指針是不行的，因為兩個程序的位址空間是完全不一樣的。
是以在 RPC 中，所有的函數都必須有自己的一個 ID。這個 ID 在所有程序中都是唯一确定的。
用戶端在做遠端過程調用時，必須附上這個 ID。然後我們還需要在用戶端和服務端分别維護一個函數和Call ID的對應表。
當用戶端需要進行遠端調用時，它就查一下這個表，找出相應的 Call ID，然後把它傳給服務端，服務端也通過查表，來确定用戶端需要調用的函數，然後執行相應函數的代碼。
實作方式 服務注冊中心。
要調用服務，首先你需要一個服務注冊中心去查詢對方服務都有哪些執行個體。Dubbo 的服務注冊中心是可以配置的，官方推薦使用 Zookeeper。
實作案例：
RMI（Remote Method Invocation，遠端方法調用）也就是 RPC 本身的實作方式。
圖 9：RMI 架構圖
Registry(服務發現)：
借助 JNDI 釋出并調用了 RMI服務。實際上，JNDI 就是一個系統資料庫，服務端将服務對象放入到系統資料庫中，用戶端從系統資料庫中擷取服務對象。
RMI 服務在服務端實作之後需要注冊到 RMI Server 上，然後用戶端從指定的 RMI 位址上 Lookup 服務，調用該服務對應的方法即可完成遠端方法調用。
Registry 是個很重要的功能，當服務端開發完服務之後，要對外暴露，如果沒有服務注冊，則用戶端是無從調用的，即使服務端的服務就在那裡。
序列化和反序列化
用戶端怎麼把參數值傳給遠端的函數呢？在本地調用中，我們隻需要把參數壓到棧裡，然後讓函數自己去棧裡讀就行。
但是在遠端過程調用時，用戶端跟服務端是不同的程序，不能通過記憶體來傳遞參數。
這時候就需要用戶端把參數先轉成一個位元組流，傳給服務端後，再把位元組流轉成自己能讀取的格式。
- 将二進制流轉換成對象的過程叫做反序列化
這個過程叫序列化和反序列化。同理，從服務端傳回的值也需要序列化反序列化的過程。
主流序列化協定優缺點對比
JSON
優點
1 簡單易用開發成本低
2 跨語言
3 輕量級資料交換
4 非冗長性（對比xml标簽簡單括号閉環）
缺點
1 體積大，影響高并發
2 無版本檢查，自己做相容
3 片段的建立和驗證過程比一般的XML複雜
4 缺乏命名空間導緻資訊混合
總結：最簡單最通用的應用協定，使用廣泛，開發效率高，性能相對較低，維護成本較高。
Protobuf
Protobuf是一種以有效并可擴充的格式編碼結構化資料的方式。
1 跨語言，可自定義資料結構。
2 字段被編号，新添加的字段不影響老結構。解決了向後相容問題。
3 自動化生成代碼，簡單易用。
4 二進制消息，效率高，性能高。
5 Netty等架構內建了該協定，提供了編×××提高開發效率。
1 二進制格式，可讀性差（抓包dump後的資料很難看懂）
2 對象備援，字段很多，生成的類較大，占用空間。
3 預設不具備動态特性（可以通過動态定義生成消息類型或者動态編譯支援）
總結：簡單快速上手，高效相容性強，維護成本較高。
Thrift（Facebook）
1 序列化和RPC支援一站式解決，比pb更友善
2 跨語言，IDL接口定義語言，自動生成多語言檔案
3 省流量，體積較小
4 包含完整的用戶端/服務端堆棧，可快速實作RPC
5 為服務端提供了多種工作模式，如線程池模型、非阻塞模型
1 早期版本問題較大，0.7以前有相容性問題
2 不支援雙通道
3 rpc方法非線程安全，伺服器容易被挂死，需要串行化。
4 預設不具備動态特性（可以通過動态定義生成消息類型或者動态編譯支援）
5 開發環境、編譯較麻煩
總結：跨語言、實作簡單，初次使用較麻煩，需要避免使用問題和場景限制。
網絡傳輸：
遠端調用往往用在網絡上，用戶端和服務端是通過網絡連接配接的。
所有的資料都需要通過網絡傳輸，是以就需要有一個網絡傳輸層。網絡傳輸層需要把 Call ID 和序列化後的參數位元組流傳給服務端，然後再把序列化後的調用結果傳回用戶端。
隻要能完成這兩者的，都可以作為傳輸層使用。是以，它所使用的協定其實是不限的，能完成傳輸就行。
盡管大部分 RPC 架構都使用 TCP 協定，但其實 UDP 也可以，而 gRPC 幹脆就用了 HTTP2。
TCP 的連接配接是最常見的，簡要分析基于 TCP 的連接配接：
通常 TCP 連接配接可以是按需連接配接（需要調用的時候就先建立連接配接，調用結束後就立馬斷掉），也可以是長連接配接（用戶端和伺服器建立起連接配接之後保持長期持有，不管此時有無資料包的發送，可以配合心跳檢測機制定期檢測建立的連接配接是否存活有效），多個遠端過程調用共享同一個連接配接。
是以，要實作一個 RPC 架構，隻需要把以下三點實作了就基本完成了：
- Call ID 映射：可以直接使用函數字元串，也可以使用整數 ID。映射表一般就是一個哈希表。
- 序列化反序列化：可以自己寫，也可以使用 Protobuf 或者 FlatBuffers 之類的。
- 網絡傳輸庫：可以自己寫 Socket，或者用 Asio，ZeroMQ，Netty 之類。
RPC 核心之網絡傳輸協定
在第三節中說明了要實作一個 RPC，需要選擇網絡傳輸的方式。
圖 10：網絡傳輸
在 RPC 中可選的網絡傳輸方式有多種，可以選擇 TCP 協定、UDP 協定、HTTP 協定。
每一種協定對整體的性能和效率都有不同的影響，如何選擇一個正确的網絡傳輸協定呢？首先要搞明白各種傳輸協定在 RPC 中的工作方式。
基于 TCP 協定的 RPC 調用
由服務的調用方與服務的提供方建立 Socket 連接配接，并由服務的調用方通過 Socket 将需要調用的接口名稱、方法名稱和參數序列化後傳遞給服務的提供方，服務的提供方反序列化後再利用反射調用相關的方法。
最後将結果傳回給服務的調用方，整個基于 TCP 協定的 RPC 調用大緻如此。
但是在執行個體應用中則會進行一系列的封裝，如 RMI 便是在 TCP 協定上傳遞可序列化的 Java 對象。
基于 HTTP 協定的 RPC 調用
該方法更像是通路網頁一樣，隻是它的傳回結果更加單一簡單。
其大緻流程為：
由服務的調用者向服務的提供者發送請求，這種請求的方式可能是 GET、POST、PUT、DELETE 等中的一種，服務的提供者可能會根據不同的請求方式做出不同的處理，或者某個方法隻允許某種請求方式。
而調用的具體方法則是根據 URL 進行方法調用，而方法所需要的參數可能是對服務調用方傳輸過去的 XML 資料或者 JSON 資料解析後的結果，最後傳回 JOSN 或者 XML 的資料結果。
由于目前有很多開源的 Web 伺服器，如 Tomcat，是以其實作起來更加容易，就像做 Web 項目一樣。
兩種方式對比
基于 TCP 的協定實作的 RPC 調用，由于 TCP 協定處于協定棧的下層，能夠更加靈活地對協定字段進行定制，減少網絡開銷，提高性能，實作更大的吞吐量和并發數。
但是需要更多關注底層複雜的細節，實作的代價更高。同時對不同平台，如安卓，iOS 等，需要重新開發出不同的工具包來進行請求發送和相應解析，工作量大，難以快速響應和滿足使用者需求。
基于 HTTP 協定實作的 RPC 則可以使用 JSON 和 XML 格式的請求或響應資料。
而 JSON 和 XML 作為通用的格式标準（使用 HTTP 協定也需要序列化和反序列化，不過這不是該協定下關心的内容，成熟的 Web 程式已經做好了序列化内容），開源的解析工具已經相當成熟，在其上進行二次開發會非常便捷和簡單。
但是由于 HTTP 協定是上層協定，發送包含同等内容的資訊，使用 HTTP 協定傳輸所占用的位元組數會比使用 TCP 協定傳輸所占用的位元組數更高。
是以在同等網絡下，通過 HTTP 協定傳輸相同内容，效率會比基于 TCP 協定的資料效率要低，資訊傳輸所占用的時間也會更長，當然壓縮資料，能夠縮小這一差距。
使用 RabbitMQ 的 RPC 架構
在 OpenStack 中服務與服務之間使用 RESTful API 調用，而在服務内部則使用 RPC 調用各個功能子產品。
正是由于使用了 RPC 來解耦服務内部功能子產品，使得 OpenStack 的服務擁有擴充性強，耦合性低等優點。
OpenStack 的 RPC 架構中，加入了消息隊列 RabbitMQ，這樣做的目的是為了保證 RPC 在消息傳遞過程中的安全性和穩定性。
下面分析 OpenStack 中使用 RabbitMQ 如何實作 RPC 的調用。
RabbitMQ 簡介
以下摘錄自知乎：
對于初學者，舉一個飯店的例子來解釋這三個分别是什麼吧。不是百分百恰當，但是應該足以解釋這三者的差別。
RPC：
假設你是一個飯店裡的服務員，顧客向你點菜，但是你不會做菜，是以你采集了顧客要點什麼之後告訴後廚去做顧客點的菜，這叫 RPC(remote procedure call)，因為廚房的廚師相對于服務員而言是另外一個人(在計算機的世界裡就是 Remote 的機器上的一個程序)。廚師做好了的菜就是RPC的傳回值。
任務隊列和消息隊列：
本質都是隊列，是以就隻舉一個任務隊列的例子。假設這個飯店在高峰期顧客很多，而廚師隻有很少的幾個，是以服務員們不得不把單子按下單順序放在廚房的桌子上，供廚師們一個一個做，這一堆單子就是任務隊列，廚師們每做完一個菜，就從桌子上的訂單裡再取出一個單子繼續做菜。
角色分擔如下圖：
圖 11：RabbitMQ 在 RPC 中角色
使用 RabbitMQ 的好處：
- 同步變異步：可以使用線程池将同步變成異步，但是缺點是要自己實作線程池，并且強耦合。使用消息隊列可以輕松将同步請求變成異步請求。
- 低内聚高耦合：解耦，減少強依賴。
- 流量削峰：通過消息隊列設定請求最大值，超過閥值的抛棄或者轉到錯誤界面。
- 網絡通信性能提高：TCP 的建立和銷毀開銷大，建立 3 次握手，銷毀 4 次分手，高峰時成千上萬條的連結會造成資源的巨大浪費，而且作業系統每秒處理 TCP 的數量也是有數量限制的，必定造成性能瓶頸。 RabbitMQ 采用信道通信，不采用 TCP 直接通信。一條線程一條信道，多條線程多條信道，公用一個 TCP 連接配接。 一條 TCP 連接配接可以容納無限條信道（硬碟容量足夠的話），不會造成性能瓶頸。
RabbitMQ 的三種類型的交換器
RabbitMQ 使用 Exchange（交換機）和 Queue（隊列）來實作消息隊列。
在 RabbitMQ 中一共有三種交換機類型，每一種交換機類型都有很鮮明的特征。
基于這三種交換機類型，OpenStack 完成兩種 RPC 的調用方式。首先簡單介紹三種交換機。
圖 12：RabbitMQ 架構圖
①廣播式交換器類型（Fanout）
該類交換器不分析所接收到消息中的 Routing Key，預設将消息轉發到所有與該交換器綁定的隊列中去。
圖 13：廣播式交換機
②直接式交換器類型（Direct）
該類交換器需要精确比對 Routing Key 與 Binding Key，如消息的 Routing Key = Cloud，那麼該條消息隻能被轉發至 Binding Key = Cloud 的消息隊列中去。
圖 14：直接式交換機
③主題式交換器（Topic Exchange）
該類交換器通過消息的 Routing Key 與 Binding Key 的模式比對，将消息轉發至所有符合綁定規則的隊列中。
Binding Key 支援通配符，其中“*”比對一個詞組，“#”比對多個詞組（包括零個）。
圖 15：主題式交換機
注：以上四張圖檔來自部落格園，如有侵權，請聯系作者：
https://www.cnblogs.com/dwlsxj/p/RabbitMQ.html。
當生産者發送消息 Routing Key=F.C.E 的時候，這時候隻滿足 Queue1，是以會被路由到 Queue 中。
如果 Routing Key=A.C.E 這時候會被同時路由到 Queue1 和 Queue2 中，如果 Routing Key=A.F.B 時，這裡隻會發送一條消息到 Queue2 中。
Nova 基于 RabbitMQ 實作兩種 RPC 調用：
- RPC.CALL（調用）
- RPC.CAST（通知）
其中 RPC.CALL 基于請求與響應方式，RPC.CAST 隻是提供單向請求，兩種 RPC 調用方式在 Nova 中均有典型的應用場景。
RPC.CALL
RPC.CALL 是一種雙向通信流程，即 RabbitMQ 接收消息生産者生成的系統請求消息，消息消費者經過處理之後将系統相應結果回報給調用程式。
圖 16：RPC.CALL 原理圖
一個使用者通過 Dashboard 建立一個虛拟機，界面經過消息封裝後發送給 NOVA-API。
NOVA-API 作為消息生産者，将該消息以 RPC.CALL 方式通過 Topic 交換器轉發至消息隊列。
此時，Nova-Compute 作為消息消費者，接收該資訊并通過底層虛拟化軟體執行相應虛拟機的啟動程序。
待使用者虛拟機成功啟動之後，Nova-Compute 作為消息生産者通過 Direct 交換器和響應的消息隊列将虛拟機啟動成功響應消息回報給 Nova-API。
此時 Nova-API 作為消息消費者接收該消息并通知使用者虛拟機啟動成功。
RPC.CALL 工作原理如下圖：
圖 17：RPC.CALL 具體實作圖
工作流程：
- 用戶端建立 Message 時指定 reply_to 隊列名、correlation_id 标記調用者。
- 通過隊列，服務端收到消息。調用函數處理，然後傳回。
- 傳回的隊列是 reply_to 指定的隊列，并攜帶 correlation_id。
- 傳回消息到達用戶端，用戶端根據 correlation_id 判斷是哪一個函數的調用傳回。
如果有多個線程同時進行遠端方法調用，這時建立在 Client Server 之間的 Socket 連接配接上會有很多雙方發送的消息傳遞，前後順序也可能是随機的。
Server 處理完結果後，将結果消息發送給 Client，Client 收到很多消息，怎麼知道哪個消息結果是原先哪個線程調用的？
Client 線程每次通過 Socket 調用一次遠端接口前，生成一個唯一的 ID，即 Request ID（Request ID必需保證在一個 Socket 連接配接裡面是唯一的），一般常常使用 AtomicLong 從 0 開始累計數字生成唯一 ID。
RPC.CAST
RPC.CAST 的遠端調用流程與 RPC.CALL 類似，隻是缺少了系統消息響應流程。
一個 Topic 消息生産者發送系統請求消息到 Topic 交換器，Topic 交換器根據消息的 Routing Key 将消息轉發至共享消息隊列。
與共享消息隊列相連的所有 Topic 消費者接收該系統請求消息，并把它傳遞給響應的服務端進行處理。
其調用流程如圖所示：
圖 18：RPC.CAST 原理圖
連接配接設計
RabbitMQ 實作的 RPC 對網絡的一般設計思路：消費者是長連接配接，發送者是短連接配接。但可以自由控制長連接配接和短連接配接。
一般消費者是長連接配接，随時準備接收處理消息；而且涉及到 RabbitMQ Queues、Exchange 的 auto-deleted 等沒特殊需求沒必要做短連接配接。發送者可以使用短連接配接，不會長期占住端口号，節省端口資源。
Nova 中 RPC 代碼設計：
簡單對比 RPC 和 Restful API
RESTful API 架構
REST 最大的幾個特點為：資源、統一接口、URI 和無狀态。
①資源
所謂"資源"，就是網絡上的一個實體，或者說是網絡上的一個具體資訊。它可以是一段文本、一張圖檔、一首歌曲、一種服務，就是一個具體的實在。
②統一接口
RESTful 架構風格規定，資料的元操作，即 CRUD(Create，Read，Update 和 Delete，即資料的增删查改)操作，分别對應于 HTTP 方法：GET 用來擷取資源，POST 用來建立資源（也可以用于更新資源），PUT 用來更新資源，DELETE 用來删除資源，這樣就統一了資料操作的接口，僅通過 HTTP 方法，就可以完成對資料的所有增删查改工作。
③URL
可以用一個 URI（統一資源定位符）指向資源，即每個 URI 都對應一個特定的資源。
要擷取這個資源，通路它的 URI 就可以，是以 URI 就成了每一個資源的位址或識别符。
④無狀态
所謂無狀态的，即所有的資源，都可以通過 URI 定位，而且這個定位與其他資源無關，也不會因為其他資源的變化而改變。有狀态和無狀态的差別，舉個簡單的例子說明一下。
如查詢員工的工資，如果查詢工資是需要登入系統，進入查詢工資的頁面，執行相關操作後，擷取工資的多少，則這種情況是有狀态的。
因為查詢工資的每一步操作都依賴于前一步操作，隻要前置操作不成功，後續操作就無法執行。
如果輸入一個 URI即可得到指定員工的工資，則這種情況是無狀态的，因為擷取工資不依賴于其他資源或狀态。
且這種情況下，員工工資是一個資源，由一個 URI與之對應，可以通過 HTTP 中的 GET 方法得到資源，這是典型的 RESTful 風格。
RPC 和 Restful API 對比
面對對象不同：
- RPC 更側重于動作。
- REST 的主體是資源。
RESTful 是面向資源的設計架構，但在系統中有很多對象不能抽象成資源，比如登入，修改密碼等而 RPC 可以通過動作去操作資源。是以在操作的全面性上 RPC 大于 RESTful。
傳輸效率：
- RPC 效率更高。RPC，使用自定義的 TCP 協定，可以讓請求封包體積更小，或者使用 HTTP2 協定，也可以很好的減少封包的體積，提高傳輸效率。
複雜度：
- RPC 實作複雜，流程繁瑣。
- REST 調用及測試都很友善。
RPC 實作（參見第一節）需要實作編碼，序列化，網絡傳輸等。而 RESTful 不要關注這些，RESTful 實作更簡單。
靈活性：
- HTTP 相對更規範，更标準，更通用，無論哪種語言都支援 HTTP 協定。
- RPC 可以實作跨語言調用，但整體靈活性不如 RESTful。
總結
RPC 主要用于公司内部的服務調用，性能消耗低，傳輸效率高，實作複雜。
HTTP 主要用于對外的異構環境，浏覽器接口調用，App 接口調用，第三方接口調用等。
RPC 使用場景（大型的網站，内部子系統較多、接口非常多的情況下适合使用 RPC）：
- 長連結。不必每次通信都要像 HTTP 一樣去 3 次握手，減少了網絡開銷。
- 注冊釋出機制。RPC 架構一般都有注冊中心，有豐富的監控管理；釋出、下線接口、動态擴充等，對調用方來說是無感覺、統一化的操作。
- 安全性，沒有暴露資源操作。
- 微服務支援。就是最近流行的服務化架構、服務化治理，RPC 架構是一個強力的支撐。
參考文章
http://www.mamicode.com/info-detail-2443824.html部落格
Java技術倉庫《Java程式員複習指南》
https://github.com/h2pl/Java-Tutorial整合全網優質Java學習内容，幫助你從基礎到進階系統化複習Java
面試指南
全網最熱的Java面試指南，共200多頁，非常實用，不管是用于複習還是準備面試都是不錯的。
在公衆号【Java技術江湖】回複“PDF”即可免費領取。