JSON-RPC? トリッキーな REST を取る

この見出しは「また始まった…」という健全な反応を引き起こしたと確信しています。しかし、5 ～ 10 分間注目を集めさせてください。期待を裏切らないように努めます。

記事の構成は次のようになります。ステレオタイプの発言を取り上げ、このステレオタイプの出現の「性質」を明らかにします。 これにより、プロジェクトにおけるデータ交換パラダイムの選択を新しい角度から見ることができるようになれば幸いです。

RPC とは何かを明確にするために、標準について検討することを提案します。 JSON-RPC 2.0。 REST では明確さがありません。 そして、そうあるべきではありません。 REST について知っておくべきことすべて - それは REST と区別できません HTTP.

RPC リクエストではバッチリクエストを実行できるため、より高速かつ効率的です。

重要なのは、RPC では XNUMX つのリクエストで複数のプロシージャを同時に呼び出すことができるということです。 たとえば、ユーザーを作成し、そのユーザーにアバターを追加し、同じリクエストでいくつかのトピックを購読します。 たった XNUMX つのリクエストで、どれほどのメリットがあることでしょう。

実際、バックエンド ノードが XNUMX つしかない場合は、バッチ リクエストを使用したほうが高速であるように見えます。 XNUMX つの REST リクエストでは、接続を確立するために XNUMX つのノードから XNUMX 倍のリソースが必要になるためです。

REST の場合、後続のリクエストを行うためには、最初のリクエストでユーザー ID を返す必要があることに注意してください。 これも全体的な結果に悪影響を及ぼします。

しかし、そのようなインフラストラクチャは、社内ソリューションとエンタープライズでのみ見つかります。 小規模な WEB プロジェクトの場合は最後の手段として。 しかし、本格的な WEB ソリューションは、たとえ HighLoad と呼ばれるものであっても、構築する価値はありません。 インフラストラクチャは、高可用性と負荷の基準を満たしている必要があります。 そして絵も変わっていきます。

同じシナリオのインフラストラクチャ アクティビティ チャネルは緑色でマークされます。 RPC がどのように動作するかに注目してください。 リクエストは、バランサーからバックエンドまでの XNUMX つの区間のみでインフラストラクチャを使用します。 REST は最初のリクエストで依然として損失を負いますが、インフラストラクチャ全体を使用して失われた時間を埋め合わせます。

スクリプトには、エンリッチメントのリクエストを XNUMX つではなく、たとえば XNUMX つまたは XNUMX つ入力するだけで十分です...そして、「誰が今勝者ですか?」という質問に対する答えを入力するだけで十分です。 が不明瞭になります。

私はこの問題をさらに広範囲に見てみることを提案します。 この図はインフラストラクチャ チャネルがどのように使用されるかを示していますが、インフラストラクチャはチャネルに限定されません。 高負荷インフラストラクチャの重要なコンポーネントはキャッシュです。 次に、ある種のユーザー アーティファクトを取得しましょう。 繰り返し。 32回としましょう。

高負荷の要求を満たすために RPC インフラストラクチャがどのように大幅に改善されたかをご覧ください。 重要なのは、RPC とは異なり、REST は HTTP プロトコルの能力を最大限に活用するということです。 上の図では、この機能はリクエスト メソッド GET によって実現されています。

HTTP メソッドなどには、キャッシュ戦略があります。 これらは次のドキュメントで見つけることができます。 HTTP。 RPC の場合、冪等とはみなされない POST リクエストが使用されます。つまり、同じ POST リクエストを繰り返し実行すると、異なる結果が返される可能性があります (たとえば、各コメントが送信された後、このコメントの別のコピーが表示されます) (ソース).

その結果、RPC はインフラストラクチャ キャッシュを効果的に使用できなくなります。 これにより、ソフトウェア キャッシュを「インポート」する必要が生じます。 この図は、この役割の Redis を示しています。 ソフトウェア キャッシュでは、開発者がコード層を追加したり、アーキテクチャに顕著な変更を加えたりする必要があります。

ここで、検討中のインフラストラクチャ内で REST および RPC が「生み出した」リクエストの数を数えてみましょう。

リクエスト
受信トレイ
バックエンドへ
DBMSへ
ソフト キャッシュ (Redis) へ
合計

REST
1 / 32 *
1
1
0
3 / 35

RPC
32
32
1
31
96

[*] 最良の場合 (ローカル キャッシュが使用されている場合) は 1 リクエスト (32 つ!)、最悪のケースでは XNUMX リクエストが受信されます。

最初の計画と比較すると、その違いは顕著です。 REST の利点が明らかになりました。 しかし、そこで立ち止まらないことをお勧めします。 開発されたインフラストラクチャには CDN が含まれています。 多くの場合、DDoS および DoS 攻撃への対策の問題も解決されます。 我々が得る：

ここが、RPC にとって事態が非常に悪いところです。 RPC はワークロードを CDN に委任することができません。 攻撃に対抗するにはシステムに頼るしかありません。

ここで終わることは可能でしょうか？ そしてまた、いいえ。 前述したように、HTTP メソッドには独自の「魔法」があります。 GET メソッドがインターネットで広く使用されているのには理由がないわけではありません。 このメソッドは、コンテンツの一部にアクセスしたり、制御がコードに移される前にインフラストラクチャ要素が解釈できる条件を設定したりできることに注意してください。 これらすべてにより、非常に大きなリクエストのフローを処理できる、柔軟で管理しやすいインフラストラクチャを作成できます。 しかし、RPC ではこのメソッドは無視されます。

では、なぜバッチ リクエスト (RPC) のほうが高速であるという通説が根強く残っているのでしょうか? 個人的には、ほとんどのプロジェクトは REST がその強みを発揮できる開発レベルに到達していないように思えます。 さらに、小規模なプロジェクトでは、自分の弱点をさらすことに積極的です。

REST または RPC の選択は、プロジェクト内の個人の自発的な選択ではありません。 この選択はプロジェクトの要件を満たす必要があります。 プロジェクトが REST から実際にできることすべてを絞り出すことができ、それが本当に必要な場合、REST は優れた選択肢になります。

しかし、REST の利点を最大限に活用するには、インフラストラクチャを迅速に拡張するプロジェクトの DevOps スペシャリスト、インフラストラクチャを管理する管理者、WEB サービスのすべてのレイヤーを設計するアーキテクトを雇う必要がある場合...そしてプロジェクト同時に、マーガリンを XNUMX 日に XNUMX パック販売します。私なら RPC を使い続けるでしょう。なぜなら... このプロトコルはより実用的です。 キャッシュやインフラストラクチャがどのように機能するかについての深い知識は必要ありませんが、開発者は必要なプロシージャへのシンプルでわかりやすい呼び出しに集中できます。 ビジネスも楽しくなるでしょう。

RPC リクエストは単一トランザクション内でバッチリクエストを実行できるため、信頼性が高くなります。

RPC のこの特性は明らかな利点です。 データベースの一貫性を保つのは簡単です。 しかし、REST では、それはますます複雑になります。 リクエストは、異なるバックエンド ノードに一貫性なく到着する可能性があります。

REST のこの「欠点」は、前述した REST の利点、つまりすべてのインフラストラクチャ リソースを効率的に使用できる機能の裏返しです。 インフラストラクチャの設計が不十分な場合、特にプロジェクトのアーキテクチャとデータベースの設計が不十分な場合、これは非常に大きな問題となります。

しかし、バッチリクエストは見た目ほど信頼できるのでしょうか? ケースを見てみましょう。ユーザーを作成し、そのプロフィールに説明を追加して、登録を完了するための秘密を含む SMS を送信します。 それらの。 XNUMX つのバッチ リクエストで XNUMX つの呼び出しを実行します。

図を見てみましょう。 これは、高可用性要素を備えたインフラストラクチャを提供します。 SMS ゲートウェイには 503 つの独立した通信チャネルがあります。 しかし...何が見えるでしょうか？ SMS の送信時にエラー XNUMX が発生し、サービスが一時的に利用できなくなります。 なぜならSMS 送信はバッチ リクエストにパッケージ化されているため、リクエスト全体をロールバックする必要があります。 DBMS 内のアクションがキャンセルされます。 クライアントはエラーを受け取ります。

次の挑戦は宝くじです。 リクエストが同じノードに再度ヒットしてエラーが返されるか、運が良ければリクエストが実行されるかのどちらかです。 しかし重要なことは、少なくとも一度は私たちのインフラがすでに無駄に機能していたということです。 負荷はありましたが、利益はありませんでした。

さて、リクエストが部分的に正常に完了できる場合のオプションを、自分自身に緊張して (!) 考え抜いたと想像してみましょう。 そして、一定の間隔を置いて、もう一度残りを完了しようとします（どれですか？前が決定しますか？）。 しかし、宝くじはそのままでした。 SMS の送信リクエストが再度失敗する可能性は 50/50 です。

同意します。クライアント側から見ると、このサービスは私たちが期待するほど信頼できるものではないようです...REST についてはどうですか?

REST は HTTP の魔法を再び使用しますが、今度は応答コードが使用されます。 SMS ゲートウェイでエラー 503 が発生すると、バックエンドはこのエラーをバランサーにブロードキャストします。 バランサーはこのエラーを受信し、クライアントとの接続を切断せずに別のノードにリクエストを送信し、そのノードがリクエストを正常に処理します。 それらの。 クライアントは期待どおりの結果を受け取り、インフラストラクチャは「アクセス性が高い」という高い称号を裏付けます。 ユーザーは満足しています。

そしてまたそれだけではありません。 バランサーは、応答コード 503 を受信しただけではありません。標準に従って、応答するときは、このコードに「Retry-After」ヘッダーを指定することをお勧めします。 ヘッダーは、指定された時間の間、このルート上のこのノードを妨害する価値がないことをバランサーに対して明確にします。 そして、SMS を送信するための次のリクエストは、SMS ゲートウェイに問題がないノードに直接送信されます。

ご覧のとおり、JSON-RPC の信頼性は過大評価されています。 確かに、データベース内の一貫性を整理するのは簡単です。 ただし、この場合、犠牲になるのはシステム全体としての信頼性です。

結論は前回とほぼ同じです。 インフラストラクチャがシンプルな場合、JSON-RPC の明白さは間違いなくプラスになります。 プロジェクトに高負荷の高可用性が含まれる場合、REST はより複雑ではありますが、より正確なソリューションのように見えます。

REST への参入しきい値が低くなります

上記の分析は、RPC に関する確立された固定概念を暴き、REST への参入の敷居が RPC よりも間違いなく高いことを明確に示したと思います。 これは、HTTP がどのように機能するかを深く理解する必要があること、および WEB プロジェクトで使用できる、または使用すべき既存のインフラストラクチャ要素について十分な知識を持っている必要があるためです。

では、なぜ多くの人が REST の方が簡単になると考えるのでしょうか? 私の個人的な意見は、この見かけの単純さは REST マニフェスト自体から来ているということです。 それらの。 REST はプロトコルではなく概念です... REST には標準はなく、いくつかのガイドラインがあります... REST は HTTP ほど複雑ではありません。 見かけ上の自由とアナーキーが「自由なアーティスト」を惹きつける。

もちろん、REST は HTTP ほど複雑ではありません。 しかし、HTTP 自体は、数十年にわたってその価値が証明されてきた、よく設計されたプロトコルです。 HTTP 自体を深く理解していなければ、REST を判断することはできません。

ただし、RPC については可能です。 その仕様を取得するだけで十分です。 それで必要ですか 愚かなJSON-RPC? それともRESTはまだ難しいのでしょうか？ あなたが決める。

あなたの時間を無駄にしないことを心から願っています。

出所： habr.com