A
GRpc(100+ req / sec)、Java生成スタブを介してサービス(10レプリカ)を呼び出すサービスがあります。ロードバランサーはありませんが、どちらの場合もベストプラクティスは何ですか。
クライアントはサービスへの呼び出しごとにチャネルを構築する必要がありますA
か、それともアプリがシャットダウンするまでManagedChannelを1回作成する必要がありますか?
リクエストごとに1つ作成すると、呼び出しは10個のレプリカに沿って分散されますが、アプリケーションの開始時にのみ作成すると、すべての呼び出しは同じサービスA
レプリカに送られます。
一方、各呼び出しで作成した場合、アイドル状態になるまで(defeaultでは30分)、何千もの接続が開いていませんか?
ManagedChannel managedChannel = ManagedChannelBuilder
.forAddress(host, port)
.usePlaintext()
.build()
ServiceA.newBlockingStub(managedChannel)).fooBar(...)
ManagedChannelはめったに作成せず、頻繁に再利用する必要があります。ManagedChannelが使用されなくなった場合は、シャットダウンすることが不可欠です。そうしないと、漏れます。
これは負荷分散の質問であり、答えは負荷分散アーキテクチャによって異なります。説明に基づいて、次の2つの構造のいずれかを使用している可能性があります。
すべてのバックエンドはDNSで公開されています。クライアントはバックエンドに直接接続します。これを「露出」と呼びます
クライアントが接続を作成するTCPロードバランサーがあり、バランサーはその接続をバックエンドに拡張します。これを「隠し」と呼びます
どちらのアプローチでも、nettyServerBuilder.maxConnectionAge(...)
クライアントが新しいバックエンドの使用を開始するには、通常、バックエンドを設定する必要があります。
公開されたアーキテクチャでは、ManagedChannelで負荷分散を構成する必要があります。これはおそらく、を使用するのと同じくらい簡単managedChannelBuilder.defaultLoadBalancingPolicy("round_robin")
です。round_robin
ポリシーは、DNSによって返された各IPアドレスへの接続を行うと、アドレス全体でRPCを配布します。maxConnectionAge
クライアントが原因でバックエンドが切断されると、DNSが再解決され、新しい接続が確立されます。
隠しアーキテクチャでは、各クライアントが各バックエンドと比較して「小さい」クライアントが多数ある場合maxConnectionAge
は、それで十分です。maxConnectionAge
クライアントが原因でバックエンドが切断されると、新しいバックエンドを選択できるロードバランサーへの新しい接続が確立されます。
隠しアーキテクチャでは、単一のバックエンドが処理できるよりも多くの負荷を生成する「大きな」クライアントがある場合、事態はより困難になります。クライアントはバックエンドの数とその状態を把握できませんが、バックエンド自体で負荷を管理することはできません。ここで行う最も簡単なことは、複数のチャネルを作成し、それらをラウンドロビンすることです。Javaでは、これをとして実装できるChannel
ため、コードの大部分からは見えません。が原因でバックエンドが切断された場合maxConnectionAge
その1つのチャネルは、新しいバックエンドを選択できるロードバランサーへの新しい接続を確立します。このアプローチの難しさは、いくつのチャネルを作成するかを知ることです。大規模なクライアントを使用する隠しアーキテクチャは、TCP負荷分散の代わりにHTTP負荷分散を使用することで多くのメリットがあります。HTTP負荷分散を使用する場合でも、ロードバランサーの負荷を分散するために、複数の管理対象チャネルを使用する必要がある場合があります。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加