gRPC-ネットワークの現状とテスト
8137 ワード
本文は主にgRPC、ネットの現状とテストの紹介、使いにくいなどの関連内容を紹介した.
前回の記事を振り返ります.
golangでのスライス操作
gRPCはグーグルがオープンソースしたモデルバッファベースのRPCフレームワークである.
そんなに速くないのに、どうしてそれを言うのですか.倹約に比べてgRPCは遅くなるが,本稿の着目点はRPCスループットの限界値ではなく,フレームワークの通信時間が数十数千ナノ秒減少することではなく,GraphQLのほかにJSON RPC最適化のもう一つの配向であるgRPCwebを紹介する.
GraphQLが着目している最適化点は,クエリの一部をクライアントに渡すことでデータの交換量を減らすことであり,RPCは圧縮可能なバイナリ/テキストプロトコルの使用に着目し,JSONテキスト伝送による不要なプロトコル損失を減らすことであることが知られている.本稿では,これに着目し,gRPCwebの現在の進展と比較して,使いやすさ,利便性,コスト面を評価し,いくつかの武断があるが,現在のgRPCwebがさらに発展する必要があるという事実を反映した.
1.
転送データ量の減少、転送遅延の減少
HTTP/2は生まれながらにしてヘッダ圧縮などの特性を持ち、大量の頻繁なRPCインタラクティブ通信によるヘッダ重複伝送問題を解決した.バイナリストリームまたは圧縮テキスト伝送を用いて,一部の疎符号化によるバイト空洞を低減し,情報密度を向上させた.伝送速度が速く、データ量が小さく、コストを削減するだけでなく、遅延を低減することができます.
2.信頼性の高い一貫したAPI設計
クライアントサービス側は同じ元のファイルを使用してインタフェース定義を行い、双方のインタフェースは完全に同じで、一致性がより強く、従来の揺れインタフェース管理に比べて、そのデータ構造はより直観的で正確で、インタフェース-URL間の複雑な対応関係を維持する必要がなくなり、APIのアップグレード管理はより簡単である.
3.伝送インフラストラクチャを感知しない通信プロトコル
倹約がgRPCwebのような案を出すことができない理由もここにある.ThriftはプライベートTprotocol転送プロトコルを使用しており、gRPCのHTTP/2に比べて汎用性が大幅に低下しており、Nginxは最新の安定版でgrpc_を提供している.pass負荷等化サポート、従来の4層/7層負荷等化器を無痛に使用して大規模な呼び出しサポートを提供
4.効率的なシーケンス化/逆シーケンス化のサポート
gRPCはJSONに比べて、より高いシーケンス化/逆シーケンス化効率を有し、より高いスループット性能を実現しやすい
gRPC webは使えますか?使いにくいですか.
言うまでもなく、次にgRPCserver+envoyエージェント+gRPCweb on Type Scriptのecho通信テストを行います.比較として、筆者は同じ機能のwebsocketリンクを実現し、双方の通信性能をテストし、これらの機能の実現の難しさを比較し、2つの「比較的下位に見える」ネットワーク通信プロトコルを評価します.
まず、エコーサービスのモデルを定義します.
次に、サーバー側のコードを書きます.ここで使用するPythonの実装:
サーバ側のprotobufのファイルを生成し、gRPCツールを使用してコードを生成し、grpcioとこれらのprotobufのライブラリファイルを導入します.
まず、HTTP/2バイナリストリームモードのgRPCをテストします.
Pythonのコードは次のとおりです.
「Server Received:test message」というメッセージを返します.テストに成功しました.パッケージの結果は次のとおりです.
両者は「安全でない」HTTPプロトコルを用いてデータを交換し,通信が成功したことが分かる.
次に,gRPCのネットワークを用いて同様の機能を実現する.注目すべき点は、現在、gRPC幅はブラウザ上で直接実行できないことである.ブラウザは裸のHTTPプロトコルのインタフェースを提供していないため、簡単なパッケージを行い、エージェントを通じてこのパッケージを剥がしてこそ、本当のgRPCバックエンドと通信することができる.この通信方式はgRPCのウェブページテキストと呼ばれている.
同様に、gRPCのツールを使用してタイプライターファイルを生成し、生成ファイルには元のJSライブラリ、記述ファイル、TSクライアントライブラリが含まれ、コードを記述します.
HTMLではこのJSを直接参照し,特使エージェントを用いてgRPCのウェブページテキストからgRPCプロトコルへの変換を行い,以下のように構成する.
テストを行い、先ほどのWebページにアクセスすると、通信状況が表示されます.
見ただけでわかるbase 64符号化、思い切って復号:
案の定、HTTPに封入されたHTTP通信です
次に使用するWebSocketの比較を行います.
サービス・エンド・プログラムの作成:
ノードを使用して起動したら、ブラウザのコンソールに接続してアクセスします.
コンソールはサーバーに戻って受け取りました:こんにちは!
通信完了、プロトコルの表示:
1回の通信後、サーバはアップグレード接続のヘッダに直接戻り、その後、双方が使用するWebSocketの通信は、gRPCのプロトコルよりも簡単にわかります.
テストの前に私はずっと考えていて、gRPCwebはいったいどのような存在なのかを考えていました.最初にgRPCwebテキストという言葉を見て、私の最初の感じはこれです.
Gmailのメールボックスには、このような極めて類似したprotobufのXHRリクエストが充満しており、専用エージェントを用いて転送する必要があるのを見たとき、このような高度に圧縮されたテキストプロトコルが正式に汎用的なフレームワークに現れたと思っていたが、実際には、gRPC-webでもgRPCweb-textでも、使いやすさでもリクエスト応答体の長さでも、jon over brotli over websocketよりも大きな進歩の余地があり、CDNを通じてjsを配布してAPIサーバの帯域幅を節約する構想を実現するには、現在も自分で車輪を作る必要があり、gRPCwebは銀弾ではなく、少なくとも現在はそうではない.
本文は公衆番号「小米運維」に先発し、クリックして原文を見る.
前回の記事を振り返ります.
golangでのスライス操作
gRPCとは何ですか。
gRPCはグーグルがオープンソースしたモデルバッファベースのRPCフレームワークである.
そんなに速くないのに、どうしてそれを言うのですか.倹約に比べてgRPCは遅くなるが,本稿の着目点はRPCスループットの限界値ではなく,フレームワークの通信時間が数十数千ナノ秒減少することではなく,GraphQLのほかにJSON RPC最適化のもう一つの配向であるgRPCwebを紹介する.
GraphQLが着目している最適化点は,クエリの一部をクライアントに渡すことでデータの交換量を減らすことであり,RPCは圧縮可能なバイナリ/テキストプロトコルの使用に着目し,JSONテキスト伝送による不要なプロトコル損失を減らすことであることが知られている.本稿では,これに着目し,gRPCwebの現在の進展と比較して,使いやすさ,利便性,コスト面を評価し,いくつかの武断があるが,現在のgRPCwebがさらに発展する必要があるという事実を反映した.
01 gRPC webは私たちに何をもたらすことができますか?
1.
転送データ量の減少、転送遅延の減少
HTTP/2は生まれながらにしてヘッダ圧縮などの特性を持ち、大量の頻繁なRPCインタラクティブ通信によるヘッダ重複伝送問題を解決した.バイナリストリームまたは圧縮テキスト伝送を用いて,一部の疎符号化によるバイト空洞を低減し,情報密度を向上させた.伝送速度が速く、データ量が小さく、コストを削減するだけでなく、遅延を低減することができます.
2.信頼性の高い一貫したAPI設計
クライアントサービス側は同じ元のファイルを使用してインタフェース定義を行い、双方のインタフェースは完全に同じで、一致性がより強く、従来の揺れインタフェース管理に比べて、そのデータ構造はより直観的で正確で、インタフェース-URL間の複雑な対応関係を維持する必要がなくなり、APIのアップグレード管理はより簡単である.
3.伝送インフラストラクチャを感知しない通信プロトコル
倹約がgRPCwebのような案を出すことができない理由もここにある.ThriftはプライベートTprotocol転送プロトコルを使用しており、gRPCのHTTP/2に比べて汎用性が大幅に低下しており、Nginxは最新の安定版でgrpc_を提供している.pass負荷等化サポート、従来の4層/7層負荷等化器を無痛に使用して大規模な呼び出しサポートを提供
4.効率的なシーケンス化/逆シーケンス化のサポート
gRPCはJSONに比べて、より高いシーケンス化/逆シーケンス化効率を有し、より高いスループット性能を実現しやすい
02
gRPC webは使えますか?使いにくいですか.
言うまでもなく、次にgRPCserver+envoyエージェント+gRPCweb on Type Scriptのecho通信テストを行います.比較として、筆者は同じ機能のwebsocketリンクを実現し、双方の通信性能をテストし、これらの機能の実現の難しさを比較し、2つの「比較的下位に見える」ネットワーク通信プロトコルを評価します.
gRPCのウェブサイトのテスト
まず、エコーサービスのモデルを定義します.
syntax = "proto3";package chatman;
message ChatRequest {
string messages = 1;
}
message ChatResponse {
string messages = 1;
}
service Chat { rpc chat (ChatRequest) returns (ChatResponse);
}次に、サーバー側のコードを書きます.ここで使用するPythonの実装:
サーバ側のprotobufのファイルを生成し、gRPCツールを使用してコードを生成し、grpcioとこれらのprotobufのライブラリファイルを導入します.
import grpcimport service_pb2,service_pb2_grpc
from concurrent.futures import ThreadPoolExecutorimport time
class ChatServicer(service_pb2_grpc.ChatServicer):
def chat(self,request,context): print(request.messages)
return service_pb2.ChatResponse(messages="Server Received: %s" % request.messages)def server_start():
server = grpc.server(ThreadPoolExecutor(max_workers=5))
service_pb2_grpc.add_ChatServicer_to_server(ChatServicer(),server)
server.add_insecure_port('0.0.0.0:8800')
server.start()
time.sleep(3600*24)if __name__ == '__main__':
server_start()まず、HTTP/2バイナリストリームモードのgRPCをテストします.
Pythonのコードは次のとおりです.
import grpcimport service_pb2_grpcimport service_pb2
channel = grpc.insecure_channel('0.0.0.0:8800')
stub = service_pb2_grpc.ChatStub(channel)
message = service_pb2.ChatRequest(messages="test message")
msg = stub.chat(message)
print(msg)「Server Received:test message」というメッセージを返します.テストに成功しました.パッケージの結果は次のとおりです.
両者は「安全でない」HTTPプロトコルを用いてデータを交換し,通信が成功したことが分かる.
次に,gRPCのネットワークを用いて同様の機能を実現する.注目すべき点は、現在、gRPC幅はブラウザ上で直接実行できないことである.ブラウザは裸のHTTPプロトコルのインタフェースを提供していないため、簡単なパッケージを行い、エージェントを通じてこのパッケージを剥がしてこそ、本当のgRPCバックエンドと通信することができる.この通信方式はgRPCのウェブページテキストと呼ばれている.
同様に、gRPCのツールを使用してタイプライターファイルを生成し、生成ファイルには元のJSライブラリ、記述ファイル、TSクライアントライブラリが含まれ、コードを記述します.
import { ChatRequest,ChatResponse } from './service_pb'import { ChatClient } from './ServiceServiceClientPb'const client1 = new ChatClient("http://127.0.0.1:8001",{},{});
let req = new ChatRequest()
req.setMessages("messages")
client1.chat(req,{},(err: any, res)=>{
console.log(res);
});HTMLではこのJSを直接参照し,特使エージェントを用いてgRPCのウェブページテキストからgRPCプロトコルへの変換を行い,以下のように構成する.
admin:
access_log_path: /tmp/admin_access.log
address:
socket_address: { address: 127.0.0.1, port_value: 9901 }
static_resources:
listeners:
- name: listener_0
address:
socket_address: { address: 127.0.0.1, port_value: 8080 }
filter_chains:
- filters:
- name: envoy.http_connection_manager
config:
codec_type: auto
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: local_service
domains: ["*"]
routes:
- match: { prefix: "/" }
route:
cluster: echo_service
max_grpc_timeout: 0s
cors:
allow_origin:
- "*"
allow_methods: GET, PUT, DELETE, POST, OPTIONS
allow_headers: keep-alive,user-agent,cache-control,content-type,content-transfer-encoding,custom-header-1,x-accept-content-transfer-encoding,x-accept-response-streaming,x-user-agent,x-grpc-web,grpc-timeout
max_age: "1728000"
expose_headers: custom-header-1,grpc-status,grpc-message
enabled: true
http_filters:
- name: envoy.grpc_web
- name: envoy.cors
- name: envoy.router
clusters:
- name: echo_service
connect_timeout: 0.25s
type: logical_dns
http2_protocol_options: {}
lb_policy: round_robin
hosts: [{ socket_address: { address: 127.0.0.1, port_value: 8800 }}]テストを行い、先ほどのWebページにアクセスすると、通信状況が表示されます.
見ただけでわかるbase 64符号化、思い切って復号:
案の定、HTTPに封入されたHTTP通信です
Web Socketのテスト
次に使用するWebSocketの比較を行います.
サービス・エンド・プログラムの作成:
console.log("Server started");
var Msg = '';
var WebSocketServer = require('ws').Server
, wss = new WebSocketServer({port: 8010});
wss.on('connection', function(ws) {
ws.on('message', function(message) {
console.log('Received: %s', message);
ws.send('Server received: ' + message);
});
});ノードを使用して起動したら、ブラウザのコンソールに接続してアクセスします.
const ws_echo = new WebSocket("ws://127.0.0.1:8081/")
ws_echo.addEventListener('message', (event) => {
console.log(event.data);
})
ws_echo.send("Hello!")コンソールはサーバーに戻って受け取りました:こんにちは!
通信完了、プロトコルの表示:
1回の通信後、サーバはアップグレード接続のヘッダに直接戻り、その後、双方が使用するWebSocketの通信は、gRPCのプロトコルよりも簡単にわかります.
結論
テストの前に私はずっと考えていて、gRPCwebはいったいどのような存在なのかを考えていました.最初にgRPCwebテキストという言葉を見て、私の最初の感じはこれです.
Gmailのメールボックスには、このような極めて類似したprotobufのXHRリクエストが充満しており、専用エージェントを用いて転送する必要があるのを見たとき、このような高度に圧縮されたテキストプロトコルが正式に汎用的なフレームワークに現れたと思っていたが、実際には、gRPC-webでもgRPCweb-textでも、使いやすさでもリクエスト応答体の長さでも、jon over brotli over websocketよりも大きな進歩の余地があり、CDNを通じてjsを配布してAPIサーバの帯域幅を節約する構想を実現するには、現在も自分で車輪を作る必要があり、gRPCwebは銀弾ではなく、少なくとも現在はそうではない.
本文は公衆番号「小米運維」に先発し、クリックして原文を見る.