REST RPC架構思想

rest rpc是乙個改進版的rpc架構，它是為了解決傳統的rpc和rest方案的一些不足之處而生的，它結合了rest api和rpc的優點，同時又克服了rest api和rpc的缺點。我們先來看看傳統的rpc和rest api方案的優點和一些不足之處。

傳統的rpc一般是基於protobuf或thrift去實現的，這類實現方式主要有存在這幾個問題。

輕量級，簡單易用。無需要額外的sdk，維護性和擴充套件性都比較好。

只支援http協議，使用時需要關注http協議和網路層的細節，而http協議比較臃腫。

rest rpc則吸收rpc和rest api的優點，同時又克服了他們的主要缺點，rest rpc的api和rest api類似，服務請求api是字串形式，支援mian/sub/sub形式的api，使用方便又無須提供專門的sdk，解決了rpc模型類定義複雜繁瑣的問題，也解決了多語言sdk更新的問題。因為api是字串弱型別的，無需專門的多語言支援的sdk包了，還可以快速響應api和協議公升級。它同時克服了rest api只能支援http協議的問題，rest rpc可以支援多種協議，http,tcp都可以，把協議和網路細節完全遮蔽，使用者無需關心協議，就像本地呼叫一樣簡單。

rest rpc的實現形式有兩種，一種基本形式和一種變體形式，變體形式是為了克服基本形式的缺點。

rest api的協議是json格式的，呼叫者需要先將引數序列化為json字串。 rest rpc的api是通用的，變化的只有服務端提供的api名稱和對應的引數物件，使用者傳入服務端提供的服務api名稱和引數物件對應的json字串。

通用rest api原型：

string call(string service_name, string json);

call("
handler1
", "
");

struct
person
;handler1(person p);

變體形式只適用於c++或其它支援可變引數的語言，它讓rpc api使用更簡單。

rest rpc變體原型：

string call(string service_name, args… args);

call("
handler2
", "
timax
", 20, "
zhuhai
");

handler2(string name, int age, string city);

rest rpc雖然解決了rest api和rpc的大部分缺點，但是它屬於弱型別的api（字串形式的），所以無法在編譯期檢查介面的正確性，只能在執行期檢查api的正確性。乙個改進的做法是由客戶端的使用者封裝api，在api內部將結構體序列化為json，再呼叫通用的api，這樣可以保證在編譯期檢查api的正確性。另外乙個改進方式是使用rest api變體形式，但這種形式只支援c/c++等支援可變引數的語言。

REST RPC架構思想

程式架構思想

架構 RESTful的架構思想

JAVA構建架構思想

REST RPC架構思想

程式架構思想

架構 RESTful的架構思想

JAVA構建架構思想

相關推薦