23 | 如何在沒有接口的情況下進行RPC調用？
我們什麼情況下需要在沒有接口時進行RPC調用？
列舉2個典型場景：
- 我們搭建一個測試平臺，允許各個業務方在測試憑條上通過輸入接口、分組名、方法名以及參數值，在線測試自己發佈的RPC服務。
- 我們要搭建一個輕量級的服務網關，可以讓各個業務方用HTTP的方式，通過服務網關調用其他服務。
所謂RPC調用，本質上就是調用端向服務端發送一條請求消息，服務端接收並處理，之後向調用端發送一條響應消息，調用端處理完響應消息後，一次RPC調用就完成了。
如果調用端可以將服務端需要知道的消息，例如接口名、業務分組名、方法名以及參數信息封裝成請求消息發送給服務器，服務端就能夠解析並處理這條請求信息，這樣問題就解決了。
我們可以使用泛化接口的方式，來讓RPC框架通過動態代理的方式，在沒有接口的情況下，進行RPC調用，也稱爲泛化調用。
24 | 如何在線上環境裏兼容多種RPC協議？
不同的RPC框架隨着互聯網技術的發展而慢慢湧現，這些框架會在不同時期被引入到不同的項目中去解決應用之間的通信問題，這樣就導致了我們在線上的環境中會存在各種各樣的RPC框架。
我們可以嘗試通過自下而上的滾動升級方式，最終讓所有的應用都切換到統一的RPC框架上，這種方法有2個侷限：
- 這要求我們能夠清楚的梳理出各個應用之間的調用關係，只有這樣，我們才能按部就班地把所有應用都升級到新的RPC框架上。
- 這要求應用之間的關係不能存在互相調用的情況，最好是應用之間的調用關係就像一棵樹，有一定的層次關係。但實際上，應用之間的調用關係往往會變成一張網。
這裏的關鍵在於，我們要讓新的RPC能同時支持多種RPC調用，當一個調用方切換到新的RPC之後，調用方和服務提供方之間就可以用新的協議完成調用，當調用方用老的RPC進行調用時，調用方和服務提供方之間就繼續沿用老的協議完成調用。
RPC協議的作用是用來分割二進制數據流，不同的協議約定的數據包格式是不一樣的，而且每種協議開頭都有一個協議編碼， 一般叫做magic number。
當RPC收到數據包之後，我們可以先解析出magic number，之後就可以找到對應協議的數據格式，然後使用相應的數據格式去解析收到的二進制數據包。
協議解析過程就是把一連串的二進制數據變成一個RPC內部對象，我們可以把和協議相關的對象轉換成一個和協議無關的對象。
當完成真正的方法調用以後，RPC返回的也是一個和協議無關的通用對象，當我們向調用方回寫數據時，我們還需要把通用對象轉換成和協議相關的對象。