Restfulを使いすぎていますが、インターフェースに圧倒されているような気がしますか？インターフェイスはまだ準備ができていません。お待ちください。魚をファックしてエビを捕まえ、終わったかどうか兄弟に尋ねてください、答えは良くありません、今日は何もしていません、1、2、3、4、金曜日は大丈夫です、あなたはここでたくさんの質問をテストすることに夢中です、わかりました、週末の残業、これは正常です。
RPCは、Remote ProcedureCallの略語です。SAPシステムのRPC呼び出しの原理は、実際には非常に単純です。3層アーキテクチャに類似したC / Sシステムがいくつかあります。サードパーティのクライアントプログラムは、インターフェイスを介してSAPの内部標準関数またはカスタム関数を呼び出し、によって返されるデータを取得します。処理後に表示または表示する機能。印刷。RPCは主に、ソフトウェアと複数のプロセス間の呼び出しの問題を解決し、ソフトウェアとハードウェア間の通信を解決することを目的としています。CORBA（CORBA（Common ObjectRequest Broker Architecture）は、OMG組織によって開発された標準のオブジェクト指向組織です。アプリケーションプログラムシステムつまり、CORBAシステム構造は、分散処理環境（DCE）でのハードウェアシステムとソフトウェアシステムの相互接続を解決するためにObject Management Organization（OMG）によって提案されたソリューションです。OMG組織は国際的な非営利組織です。、その責任は、アプリケーション開発のためのパブリックフレームワークを提供し、業界ガイドラインとオブジェクト管理仕様を策定し、オブジェクトテクノロジの開発を加速することです。）
目次
RPCがRESTFulインターフェースサービス呼び出しを置き換える理由
原理
IPCおよびRPCを介して、プログラムは他のプログラムまたはコンピュータープロセスを使用できます。クライアント/サーバーモデルコンピューティングは、システム間の通信メカニズムとして、他のテクノロジ（メッセージパッシングなど）とともにリモートプロシージャコールを使用します。クライアントは独自のタスクを実行しますが、バックエンドファイルサービスを提供するためにサーバーに依存しています。RPCは、図R-4に示すように、クライアントがバックエンドサーバーにサービスを要求するための通信メカニズムを提供します。クライアント/サーバーアプリケーションを別個のプログラムと考えると、サーバーはデータに最も近いためデータアクセス部分を実行でき、クライアントはデータ表示とユーザー操作のフロントエンド部分を実行できます。このように、リモートプロシージャコールは、ネットワークを介して分割されたプログラムを再編成するコンポーネントと見なすことができます。LPCは、カップリング（カップリング）メカニズムと呼ばれることもあります。
このようにプログラムを分割すると、ユーザーがデータにアクセスするたびに、データベース全体またはそのプログラムのほとんどをユーザーシステムにコピーする必要がなくなります。実際、サーバーはリクエストのみを処理し、一部のデータ計算のみを実行して、結果をユーザーに送信します。データを1か所に保存するとデータベースの同期が容易になるため、複数のユーザーが同時に同じデータにアクセスできます。
分散コンピューティング環境は、通信システム（ネットワーク）によって接続されたコンピュータークラスターです。このネットワークをコンピューティングプラットフォームと考えるのは簡単です。ピアツーピア方式の場合、どのコンピューターもクライアントまたはサーバーになることができます。一部の処理タスクは、独立した実行中のプログラムに分割して、異なるネットワークコンピューターで並行して処理することができ、独立したプログラムは、このタスクの処理に最も適したコンピューターに渡されます。この戦略は、コンピューターのアイドル状態のリソースを利用して、ネットワークの効率を向上させることができます。一般的なエンタープライズネットワークには、さまざまなオペレーティングシステムを実行する多くの異種コンピュータシステムが含まれます。
エンタープライズネットワークの出現に伴い、開発者はさまざまなコンピュータおよびネットワーク通信プロトコルで実行できるプログラムをコンパイルする必要があります。現在、人々はリモートプロシージャコールを独立させようとしています。つまり、開発者は基盤となるネットワークやネットワークでのデータ転送に使用されるプロトコルを考慮する必要がありません。次に、Open Software Fund（OSF）分散コンピューティング環境でのRPCについて説明します。 （DCC）関連する実装方法。RPCは、さまざまな分散コンピューティング環境で機能します。
応用
RPCには、分散システムでのシステム環境の構築とアプリケーション設計に幅広いアプリケーションがあり、そのアプリケーションには次のものが含まれます。
- 分散オペレーティングシステムのプロセス間通信
プロセス間通信は、オペレーティングシステムが提供しなければならない基本的な機能の1つです。分散オペレーティングシステムは、異種ノードマシン上のプロセス間の通信メカニズムを提供する必要があります。RPCは、メッセージの分散プロセス間通信を実現する手段の1つです。送信モード。。
- 分散コンピューティングのためのソフトウェア環境の構築
分散ソフトウェア環境自体が地理的に分散しているため、さまざまなコンポーネント間で多数の相互作用と通信が行われ、RPCはその基本的な実装方法の1つです。2つの一般的な分散コンピューティングソフトウェア環境であるONC +とDCEは、RPCを使用して構築されており、他のいくつかの分散ソフトウェア環境もRPCを使用しています。
- リモートデータベースサービス
分散データベースシステムでは、データベースは通常サーバー上にあり、クライアントはリモートデータベースサービス機能を介してデータベースサーバーにアクセスします。既存のリモートデータベースサービスはRPCモードを使用します。たとえば、SybaseとOracleの両方がストアドプロシージャメカニズムを提供します。システムとユーザー定義のストアドプロシージャはデータベースサーバーに格納され、ユーザーはRPCモードを使用してクライアントのストアドプロシージャを呼び出します。
- 分散アプリケーションの設計
RPCメカニズムとRPCツールは、分散アプリケーション設計の手段と利便性を提供します。ユーザーは、ネットワーク構造とプロトコルの詳細を知らなくても、RPCツールを直接使用して分散アプリケーションを設計できます。
- 分散プログラムのデバッグ
RPCは、分散プログラムのデバッグに使用できます。リバースRPCを使用してサーバーをクライアントにし、分散プログラムをデバッグできるクライアントプロセスにRPCを発行します。たとえば、サーバーでリモートデバッガーを実行すると、クライアントのRPCを継続的に受信します。デバッガーのブレークポイントに遭遇すると、RPCをクライアントに送り返し、ブレークポイントに到達したことを通知します。これは、使用されるRPCでもあります。プロセスのために。コミュニケーションの例。
フレーム
言語プラットフォームにバインドされている主に次のオープンソースRPCフレームワークがあります。
- RMI：Java Remote Method Protocol（Java Remote Method Protocol）とJavaのネイティブシリアル化に基づいて、java.rmiパッケージを使用して実装されています。
- Hessian：RMI関数を簡単な方法で提供する軽量のリモートonhttpツール。HTTPプロトコルに基づき、バイナリコーデックを使用します。
- Protobuf：GoogleのProtocolBuffersプロトコルに基づくリモートメソッド呼び出しのフレームワークを提供するJavaクラスライブラリ。Nettyの基盤となるNIOテクノロジーに基づいています。TCP再利用/キープアライブ、SSL暗号化、RPC呼び出しキャンセル操作、埋め込みログおよびその他の機能をサポートします。
- Dubbo：Alibabaによって開発され、2011年末にオープンソース化された、中国で最も初期のオープンソースRPCフレームワークは、Java言語のみをサポートします。
- Motan：Weiboが内部で使用しているRPCフレームワークは2016年にオープンソース化されており、Java言語のみをサポートしています。
- Tars：Tencentが内部で使用しているRPCフレームワークは2017年にオープンソース化され、C ++言語のみをサポートしています。
- Spring Cloud：Java言語のみをサポートする2014年のPivotalの外国のオープンソースRPCフレームワーク
クロスランゲージプラットフォームのオープンソースRPCフレームワークには、主に次のタイプがあります。
- gRPC：複数の言語をサポートする2015年のGoogleのオープンソースクロスランゲージRPCフレームワーク。
- Thrift：元々はFacebookによって開発された内部システム用のクロスランゲージRPCフレームワークでした。2007年にApache Foundationに貢献し、複数の言語をサポートするApacheオープンソースプロジェクトの1つになりました。
ビジネスシナリオが1つの言語のみに制限されている場合は、言語にバインドされたRPCフレームワークの1つを選択できます。
複数の言語プラットフォーム間の相互呼び出しが含まれる場合は、言語間プラットフォームのRPCフレームワークを選択する必要があります。
RPCフレームワーク、それらの具体的な違いは何ですか？
ダボ
最初にDubboについて説明しましょう。Dubboは中国で最も初期のオープンソースRPCフレームワークと言えます。現在、Java言語のみをサポートしています。そのアーキテクチャを次の図に示します。
図からわかるように、Dubboのアーキテクチャには主に4つの役割があり、その中でコンシューマーはサービスコンシューマー、プロバイダーはサービスプロバイダー、レジストリは登録センター、モニターは監視システムです。
具体的な対話プロセスは、コンシューマー側が登録センターを介してプロバイダーノードを取得した後、DubboのクライアントSDKを介してプロバイダーとの接続を確立し、呼び出しを開始することです。プロバイダーは、DubboのサーバーSDKを介してコンシューマーの要求を受信し、処理後に結果をコンシューマーに返します。
Tomcat
Motanは、中国でよく知られているもう1つのオープンソースRPCフレームワークであり、Java言語の実装のみをサポートしています。そのアーキテクチャは次の図で説明できます。
MotanとDubboのアーキテクチャは類似しており、どちらもクライアント側（サービスコンシューマー）とサーバー側（サービスプロバイダー）にSDKを導入する必要があります。Motanフレームワークには、主に次の機能モジュールが含まれています。
登録：登録サービス、サブスクリプションサービス、サービス変更通知、サービスハートビート送信などの機能を含む、登録センターとの対話に使用されます。
プロトコル：RPCサービスを記述し、RPCサービスの管理を構成するために使用されます。このレイヤーは、統計や同時実行制限などの機能を完了するために、さまざまな機能を持つフィルターを追加することもできます。
シリアル化：RPCリクエストのパラメーター、結果、その他のオブジェクトをシリアル化および逆シリアル化します
トランスポート：リモート通信に使用されます。デフォルトでは、NettyNIOのTCPロングリンクモードが使用されます。
クラスター：要求時に、使用可能なサーバーが選択され、さまざまな高可用性および負荷分散戦略に従ってリモート呼び出しが開始されます。
タール
Tarsは、長年にわたってマイクロサービスアーキテクチャを使用するという社内慣行に基づいて、Tencentによって要約されたオープンソースプロジェクトです。C++言語のみをサポートします。アーキテクチャ図は次のとおりです。
Tarsのアーキテクチャの相互作用には、主に次のプロセスが含まれます。
サービスリリースプロセス：サーバーリリースパッケージをWebシステムのパッチにアップロードします。アップロードが成功したら、レジストリサービスによってノードに伝達されるリリースサーバー要求をWebで送信し、ノードがサーバーをプルします。パッケージをローカルにリリースして、サーバーサービスを開始します。
管理コマンドプロセス：Webシステムでは、レジストリサービスによってノードサービスに送信される管理サーバーサービスコマンド要求を送信できます。その後、ノードは管理コマンドをサーバーに送信します。
ハートビートレポートプロセス：サーバーサービスの実行後、サーバーサービスは定期的にハートビートをノードに報告し、ノードはサービスのハートビート情報をレジストリによって管理されているレジストリサービスに報告します。
情報レポートプロセス：サーバーサービスの実行後、定期的に統計をstatにレポートし、リモートログをログに出力し、属性情報をpropに定期的にレポートし、例外情報をレポートして通知し、サービス構成情報をconfigからプルします。
クライアントアクセスサーバープロセス：クライアントは、サーバーのオブジェクト名Objを介して間接的にサーバーにアクセスできます。クライアントは、サーバーのルーティング情報（IPやポート情報など）をレジストリから取得し、特定のビジネス特性に従って（同期または非同期、TCPまたはUDP）方法）サーバーにアクセスします（もちろん、クライアントはIP /ポートを介してサーバーに直接アクセスすることもできます）。
春の雲
Spring Cloudは、Spring Boot機能を使用して、オープンソース業界の優れたコンポーネントを統合し、マイクロサービスアーキテクチャ全体で一連のサービスガバナンスソリューションを提供します。
Java言語プラットフォームのみをサポートし、そのアーキテクチャ図は次の図で説明できます。
Spring Cloudマイクロサービスアーキテクチャは複数のコンポーネントで構成されており、各コンポーネントの相互作用プロセスは次のようになっていることがわかります。
APIゲートウェイZuulを介した内部サービスへの統合アクセスの要求は、最初にセキュリティ認証のためにトークンを通過します。
セキュリティ認証に合格した後、ゲートウェイZuulは、登録センターEurekaから利用可能なサービスノードのリストを取得します。
利用可能なサービスノードから利用可能なノードを選択し、このノードにリクエストを配信します。
リクエストプロセス全体を通じて、Hystrixコンポーネントはサービスタイムアウトの融合の処理を担当し、Turbineコンポーネントは通話の監視とサービス間の関連インジケーターの融合を担当し、Sleuthコンポーネントは通話チェーンの監視を担当し、ELKはログ分析を担当します。 。
gRPC
最初にgRPCを見ると、その原則は、IDL（インターフェイス定義言語）ファイルを介してサービスインターフェイスのパラメーターと戻り値のタイプを定義し、次にコード生成プログラムを介してサーバーとクライアントの特定の実装コードを生成することです。 gRPCでは、クライアントアプリケーションは、ローカルオブジェクトを呼び出すのと同じように、別のサーバー上の対応するメソッドを呼び出すことができます。
その主な特徴は3つの側面を含みます。
HTTP / 2は接続の多重化、双方向ストリーミング、サーバープッシュ、リクエストの優先度、ヘッダーの圧縮などのメカニズムを提供するため、通信プロトコルはHTTP / 2を使用します。
IDLはProtoBufを使用します。ProtoBufはGoogleによって開発されたデータシリアル化プロトコルであり、非常に高い圧縮および送信効率と単純な構文を備えています。
多言語サポート。複数の言語に基づいて、対応する言語のクライアントコードとサーバーコードを自動的に生成できます。
リサイクル
Thriftをもう一度見てみましょう。Thriftは、最大25のプログラミング言語をサポートする軽量のクロスランゲージRPC通信ソリューションです。gRPCなどの複数の言語をサポートするために、Thriftには独自のインターフェイス定義言語IDLのセットもあります。コードジェネレーターを使用して、さまざまなプログラミング言語のクライアントとサーバーのSDKコードを生成し、さまざまな言語を確保できます。互いに通信できます。互いに通信します。そのアーキテクチャ図は、次の図で説明できます。
この写真から、ThriftRPCフレームワークの特性を確認できます。
Binary、Compact、JSON、Multiplexedなどの複数のシリアル化形式をサポートします。
Socket、Framed、File、Memory、zlibなどの複数の通信方法をサポートします。
サーバーは、シンプル、スレッドプール、ノンブロッキングなどの複数の処理方法をサポートしています。
RPCがRESTFulインターフェースサービス呼び出しを置き換える理由
==========セキュリティ上の考慮事項：=================
1. RPCアドレスの隠蔽、APIアドレスを公開する必要はなく、一般公開のみコードレベルが必要ですユーザーインターフェイス
2、HTTPは安全ではありません、HTTPSベースのセキュリティプロトコルを使用する必要があります
3、内部通信規則、面倒な管理API、ドキュメントの更新はアプリケーションセキュリティBUGをタイムリーに公開していません（バージョンの不一致の問題、根本的な見つけにくい）
==========メンテナンスコストの考慮事項：=============
1.実装の代わりにインターフェイスを提供します。これにより、内部実装に注意を払わずにインターフェイスの動作が本質的に制限されます
2。インターフェイスレベルの変更は時間内に検出および調整
でき、問題はコードレベルで解決できます。3。RPCはいつでもサービスアクセスアドレスを調整できます。自然な負荷分散機能があり、分散システムに適しています
。4。RPCは双方向で呼び出すことができます。特定の動作を書き直す必要はありません。コードを使用して
5を呼び出すことができます。特定のシステムを脇に置いて、二次開発なしでその機能の一部のみを使用できます。プロジェクトの準備ができています。使用（依存関係の構成と構成RPCサービスアドレスを使用して解決）
==========クロスサービスコール：=================
1.現在、ほとんどのアプリケーションはマイクロサービスの方向に開発されています。より頻繁かつ広範。
2.サービス間の要求を保証することは困難である。本質的には、HTTPの下の層はまた、TCPプロトコルによって実装されている。また、サービス応答のための接続や待ち時間を確立します。高性能の呼び出し。
3.避け、サービスと連鎖呼び出しの間にサービスを分割されていない。サービスが利用できない
安らかが個別に展開されるために、特定の能力を必要としながら、サービスの4だけの能力が必要とされ、別途の展開が必要とされません
5.クロスドメインの問題を解決する必要はなく、Nginxが多数のエージェントである必要もありません
課題：コアサービスは複数のビジネスシステムによって呼び出され、プロジェクトの違いに適応するために毎回異なるサービスが展開されます。プロジェクトでは、RestTemplateまたはHttpClient呼び出しが毎回使用されます。実装するには、インターフェイス呼び出しを伝達する必要があります。コアプロジェクトが原因である不合理な設計は、複数のプロジェクトチームから不満を言われることがよくあります。アップグレードがリリースされるたびに、すべてのサービスパックをダウンロードし、ファイルを1つずつ置き換える必要があります。これは非常に面倒です。放棄できない場合は、メソッドを放棄するか変更します。Restfulインターフェイスを削除し、RPCを直接使用してインターフェイス呼び出しを定義することをお勧めします。サービスの動作の設計は明確です。これらのインターフェースは、定義後に開発および呼び出すことができます。なぜそうしないのですか？通信は常に最大のコストですが、コストを削減するための最良の方法でもあります。