我確信這個標題引起了良好的反應 - “好吧，又開始了……”但是讓我用 5 到 10 分鐘來吸引您的注意力，我會盡力不辜負您的期望。
文章的架構如下：採取一種刻板印象的陳述，並揭示這種刻板印像出現的「本質」。 我希望這能讓您從一個新的角度來看待專案中資料交換範式的選擇。
為了清楚什麼是RPC，我建議考慮標準 。 對 REST 來說，沒有明確性。 但事實不應該如此。 關於 REST 您需要了解的一切 - 它與 .
RPC 請求更快、更有效率，因為它們允許您發出批次請求。
重點是，在 RPC 中，您可以在一個請求中同時呼叫多個過程。 例如，建立一個用戶，為他添加頭像，並在同一請求中為他訂閱一些主題。 只要一求，多大的好處！
事實上，如果您只有一個後端節點，那麼批次請求看起來會更快。 因為三個 REST 請求將需要一個節點三倍的資源來建立連結。
請注意，在 REST 情況下，第一個請求必須傳回使用者 ID，以便發出後續請求。 這也會對整體結果產生負面影響。
但此類基礎設施只能在內部解決方案和企業中找到。 作為最後的手段，在小型 WEB 專案中。 但成熟的 WEB 解決方案，甚至那些稱為 HighLoad 的解決方案，都不值得建造。 他們的基礎設施必須滿足高可用性和負載的標準。 而情況正在改變。
同一場景下的基礎設施活動通道以綠色標示。 請注意 RPC 現在的行為方式。 此請求僅使用從平衡器到後端的一側的基礎設施。 雖然 REST 在第一個請求中仍然會遺失，但它彌補了使用整個基礎設施損失的時間。
在腳本中輸入的不是兩個豐富請求，而是五個或十個…以及「現在誰贏了？」這個問題的答案就足夠了。 變得不清楚。
我建議從更廣泛的角度來看這個問題。 該圖顯示了基礎設施通道的使用方式，但基礎設施並不限於通道。 高負載基礎設施的一個重要組成部分是快取。 現在讓我們獲得某種使用者工件。 反覆。 假設是 32 次。
了解 RPC 基礎架構如何顯著改進以滿足高負載的需求。 問題是，與 RPC 不同，REST 使用了 HTTP 協定的全部功能。 在上圖中，這種能力是透過請求方法－GET 來實現的。
HTTP 方法除其他外還具有快取策略。 您可以在以下位置的文檔中找到它們： 。 對於RPC，使用的是POST請求，不被認為是冪等的，即重複重複相同的POST請求可能會返回不同的結果（例如，每次發送評論後，都會出現該評論的另一個副本）（).
因此，RPC 無法有效地使用基礎架構快取。 這導致需要“導入”軟體快取。 該圖顯示了 Redis 的這一角色。 反過來，軟體快取要求開發人員添加額外的程式碼層並在架構中進行顯著的更改。
現在讓我們計算一下在所考慮的基礎架構中 REST 和 RPC「產生」了多少個請求？
請求
收件箱
到後端
到資料庫管理系統
到軟體緩存（Redis）
TOTAL
REST的
1/32*
1
1
0
3 / 35
RPC
32
32
1
31
96
與第一個方案相比，差異是驚人的。 現在 REST 的好處變得顯而易見。 但我建議不要就此止步。 開發的基礎設施包括 CDN。 通常它還可以解決對抗 DDoS 和 DoS 攻擊的問題。 我們得到：
這就是 RPC 的情況變得非常糟糕的地方。 RPC 根本無法將工作負載委託給 CDN。 我們只能依靠系統來反擊攻擊。
到這裡就可以結束了嗎？ 再說一次，不。 如上所述，HTTP 方法有其自身的「魔力」。 GET 方法在網路上廣泛使用也不是沒有原因的。 請注意，此方法能夠存取一段內容，能夠設定基礎結構元素在控制權轉移到程式碼之前可以解釋的條件，等等。 所有這些使您能夠創建靈活、可管理的基礎架構，可以處理真正大的請求流。 但在 RPC 中，這個方法...被忽略。
那麼為什麼批次請求（RPC）更快的迷思如此持久？ 就我個人而言，在我看來，大多數專案根本沒有達到 REST 能夠發揮其優勢的開發水平。 而且，在小專案中，他更願意展現自己的弱點。
選擇 REST 或 RPC 並不是專案中個人的自願選擇。 這個選擇必須滿足項目的要求。 如果一個專案能夠從 REST 中榨取所有它真正能榨取的東西，而且它確實需要它，那麼 REST 將是一個很好的選擇。
但是，如果為了獲得 REST 的所有好處，您需要為專案聘請 DevOps 專家來快速擴展基礎設施、聘請管理員來管理基礎設施、聘請架構師來設計 WEB 服務的所有層…以及項目，同時，每天賣三包人造奶油...我會堅持使用RPC，因為... 這個協議更加實用。 它不需要深入了解快取和基礎設施如何運作，而是讓開發人員專注於對其所需過程的簡單且易於理解的呼叫。 生意會很愉快。
RPC 請求更可靠，因為它們可以在單一交易中執行批次請求
RPC 的這個特性是一個明顯的優勢，因為保持資料庫的一致性很容易。 但對於 REST，它會變得越來越複雜。 請求到達不同後端節點時可能不一致。
REST 的這個「缺點」是其上述優點的另一面——有效利用所有基礎設施資源的能力。 如果基礎設施設計得不好，更何況專案的架構，特別是資料庫設計得不好，那真是個很大的痛苦。
但大量請求真的像看起來那麼可靠嗎？ 讓我們來看一個案例：我們創建一個用戶，用一些描述豐富他的個人資料，並向他發送一條包含秘密的短信以完成註冊。 那些。 一批請求中的三個調用。
讓我們看一下圖表。 它提供了具有高可用性元素的基礎架構。 與簡訊網關有兩個獨立的通訊通道。 但是……我們看到了什麼？ 發送簡訊時，出現錯誤503－服務暫時無法使用。 因為簡訊發送被打包在批次請求中，那麼整個請求必須回滾。 DBMS 中的操作被取消。 客戶端收到錯誤。
下一個嘗試是彩票。 要么請求會再次命中同一個節點並再次返回錯誤，要么你很幸運，它將被執行。 但最重要的是，至少有一次我們的基礎設施已經徒勞無功。 有負載，但沒有利潤。
好吧，讓我們想像一下，當請求可以部分成功完成時，我們已經竭盡全力（！）並仔細考慮了該選項。 我們會嘗試在一段時間間隔後再次完成剩下的部分（哪一個？前面決定嗎？）。 但抽獎還是一樣。 發送 SMS 的請求有 50/50 的機會再次失敗。
同意，從客戶端來看，該服務似乎並不像我們希望的那樣可靠... REST 怎麼樣？
REST 再次使用 HTTP 的魔力，但現在帶有回應代碼。 當簡訊閘道出現503錯誤時，後端會向均衡器廣播該錯誤。 平衡器收到此錯誤，並且在不中斷與客戶端的連接的情況下，將請求發送到另一個節點，該節點成功處理了該請求。 那些。 客戶收到了預期的結果，基礎設施證實了其「高度可訪問」的崇高稱號。 用戶很高興。
再說一遍，這還不是全部。 平衡器不僅收到回應代碼 503。回應時，根據標準，建議為此代碼提供「Retry-After」標頭。 標頭向平衡器明確表明，在指定時間內不值得幹擾該路由上的該節點。 而接下來發送簡訊的請求將直接發送到簡訊網關沒有問題的節點。
正如我們所看到的，JSON-RPC 的可靠性被高估了。 事實上，在資料庫中組織一致性更容易。 但在這種情況下，犧牲的將是整個系統的可靠性。
結論與上一個大致相似。 當基礎設施很簡單時，JSON-RPC 的明顯性絕對是一個優勢。 如果專案涉及高負載的高可用性，REST 看起來是一個更正確但更複雜的解決方案。
REST 的進入門檻較低
我想，上述的分析打破了人們對RPC的刻板印象，清楚地表明，進入REST的門檻無疑比進入RPC更高。 這是因為需要深入了解 HTTP 的工作原理，以及需要對可以且應該在 WEB 專案中使用的現有基礎架構元素有足夠的了解。
那為什麼很多人認為REST會比較簡單呢？ 我個人的觀點是，這種表面上的簡單性來自於 REST 本身的表現。 那些。 REST 不是一個協議，而是一個概念...REST 沒有標準，有一些準則...REST 並不比 HTTP 更複雜。 明顯的自由和無政府狀態吸引著「自由藝術家」。
當然，REST 並不比 HTTP 複雜。 但 HTTP 本身是一個設計良好的協議，幾十年來已經證明了它的價值。 如果對HTTP本身沒有深入的了解，那麼REST是無法判斷的。
但對於 RPC - 你可以。 拿它的規格就夠了。 那你需要 ？ 或者 REST 仍然很棘手？ 你決定。
我真誠地希望我沒有浪費您的時間。
來源： www.habr.com