讀書筆記丨遠程服務呼叫和RESTful，如何分析和抉擇？-有解無憂

摘要：相信未來REST規范將會變得更加流行和普及，

本文分享自華為云社區《云原生時代，遠程服務呼叫和RESTful，如何分析和抉擇？》，作者：breakDawn ，

隨著云原生的概念越來越火，服務的架構應該如何發展和演進，成為很多程式員關心的話題，大名鼎鼎的《深入理解java虛擬機》一書作者于21年推出了新作《鳳凰架構》，從這本書中可以看到當前時下很多最新的技識訓者理念，

本博文將沉淀發布這本書的學習筆記和思考，如果希望了解更加詳細的內容，歡迎購買該書繼續詳細學習，

訪問遠程服務

1 遠程服務呼叫

這一個章節主要講解rpc的設計理念和發展歷史，
先是講解了IPC（行程間通信）所需要的各個必要因素
接著解釋RPC 是IPC的一種特例（這是最初科學家們的想法）
但PRC存在很多可靠性的問題，并不能直接等同IPC的擴展，

接著提出了RPC的三個基本問題：

如何表示資料
即序列化協議，有grpc的proto-buffer、json、xml、java-rmi基于java自帶序列化之列的
如何傳遞資料
基于什么網路協議傳輸
java-rmi的遠程協議
JSON-RPC協議
SOAP協議（web service 簡單對下訪問）
如何表示方法
如何定義方法，如何在不同語言、不同系統環境中保證方法簽名唯一，
需要對介面描述定義語言有一個選型

再后面講解了rpc的發展歷史
CORBA的使用過于復雜，被拋棄
SOAP使用xml很簡單，但是性能奇差
可以看出RPC想同時滿足簡單、普適、高性能是很難的
于是得出一個結論：

不存在完美的RPC框架

最近幾年的RPC框架更傾向于往高層次、插件化發展，
即不再獨立解決RPC的所有問題，而是提供一些擴展點由用戶自己選擇（比如dubbo）
可以任意切換json或者fastjson等序列化方式
可以切換傳輸協議等，

2 REST

rest并不是一種遠程呼叫協議，他只能說是一種風格，
REST的傳輸效率提升潛力有限，但是可以簡化呼叫，

2.1 REST核心概念（基于HTTP超文本傳輸協議）

資源
資源指你希望獲取或者修改的東西、資訊本身，他的表現形式可以不同，但是里子是相同的
表征
就是表現資源的形式，用html還是pdf來回傳
狀態
指的是服務端對某次會話是否持有狀態，
例如讀下一篇文章時，當前文章id由服務端存盤還是瀏覽器存盤，這就是有狀態和無狀態的區別，
轉移
就是服務端提供的行為邏輯，通常叫做資源的轉移
統一介面
就是HTTP協議里提供的GET\HEAD\POST\PUT\DELETE\TRACE\OPTIONS這七種操作，通過這些操作觸發轉移
超文本驅動
瀏覽器的行為經常是通過服務端回傳的url或者各種資訊觸發了驅動行為
自描述訊息
為了方便客戶端識別表征，回傳類似于Content-Type等內容，方便用何種字符集處理

2.2 REST核心設計原則

客戶端與服務端分離
服務端不處理渲染，由客戶端來處理
無狀態
盡可能希望服務端不要存盤rest會話狀態，達到分布式的高價值回報，
但是不太可能特別是客戶端持有會話數量級很大的情況下，所以仍舊會持有一定狀態
可快取
服務端的應答中要直接或者間接告知客戶端是否可以快取，快取多久
分層系統
客戶端不需要知道是否真的連接到了最終的服務器
代表是CDN內容分發網路
統一介面
面向資源編程
系統設計時聚焦在資源而不是行為上
例如面向行為時，登錄就是login介面，注銷就是logout介面
而面向資源時，登錄就是PUT Session, 注銷就是DELETE Session
按需代碼
客戶端的代碼可以有一部分讓服務端發回進行裝載，

2.3 REST的好處

降低服務介面的學習成本
資源天然具有集合與層次介面
這樣很多資源可以很容易組合在一起并讓使用者想到介面url是什么
例如獲取用戶 icyfenix的購物車中的第2本書，這個是有層次的，那么介面就是GET /user/icyfenix/cart/2
REST系結于HTTP協議，HTTP又是大家非常熟悉的

2.4 RMM（Richardson提出的restful成熟度模型）

第0級：完全不rest

提供的api定義里總是包含了各種動作，例如
/queryXXX
/applyXXX
類似于RPC的行為介面
壞處是一旦要提供其他對XXX的操作，必須重新撰寫介面，無法對XXX的查詢能力進行復用！

第1級：開始引入資源的概念

api的endpoint定義應該圍繞名詞+資源id而不是動詞來定義，
POST /doctors/mjones 獲取醫生的檔期
POST /schedules/{id} 觸發對這個id的調度

第2級：引入統一介面，映射到HTTP方法上

上面的method都是POST，實際上可以把HTTP方法的method、回傳碼都給利用上

對一個資源的增加用POST，洗掉用DELETE，更新用PUT
依賴HTTP的回傳碼定義資源可能的例外情況，例如201代表創建成功，409代表沖突（被人搶先預約）
利用HTTP自帶的認證和授權資訊，

第3級：超文本控制，轉移行為通過回應控制

第2級里，所有介面的定義仍然需要使用者自己查詢檔案來記憶和應用
實際上應該只需要一個操作起始入口，例如獲取醫生的檔期介面
這個介面要回傳的body里，已經告知了對應資源的名稱，例如檔期資源的key就叫做schedules
那么就能馬上知道下一個介面查詢用schedules了！
這樣代碼里可以做好適配，當你要把檔期的key名做修改時，客戶端代碼根本不用變動！

2.2.4 REST的不足和爭議

1.restful面向資源編程只適合做CRUD，不適合過于復雜的業務邏輯

面向程序編程，以演算法和處理程序為中心，這符合計算機世界中主流的互動方式
面向物件編程，將資料和物件行為統一起來，因為這符合現實世界的主流互動方式
面向資源編程，資料作為主體，行為看成統一介面，為了符合網路世界的主流互動方式

2.rest不利于事務支持
作者不同意這個觀點，認為不會有阻礙，取決于系統的事務設計

3.rest沒有傳輸可靠性支持
雖然確實沒有類似于重發等機制的保證，但rest介面一般盡可能要求冪等性，來做到應用代碼做重發時可以不用擔心重復的問題

4.缺少對資源做部分或者批量處理的能力
rest語意里不能涵蓋這種情況，得定義特殊的介面或者引數，那么低3級里面就不能涵蓋了，

讀書筆記丨遠程服務呼叫和RESTful，如何分析和抉擇？