GRPCのリクエスト構造とエラーハンドリング - Qiita
この記事について GRPC は HTTP/2 の上に構築されているため、クライアントからサーバーのサービス呼び出しや、サーバーからクライアントへ戻り値やエラーの送信、といったやり取りは HTTP/2 のリクエストとレスポンスで実装されています(もうちょっと厳密に言うと HTTP/2 フレームを使って実装されている)。 この記事ではGo言語のGRPC実装(grpc-go)を用いて、以下についてまとめてみました。 GRPC が用いる HTTP/2 のリクエスト、レスポンスの流れと構造 その中でエラーがどう伝播されるか GRPC の Unary RPC のエラーハンドリング 扱いにちょっと悩む Streaming RPC のエラーハンドリング 環境等の情報 記事の作成に用いた環境: Go言語 : v1.15.6 grpc-go : v1.34.0 この記事で用いたソースコード grpc-erro
node.jsを10->12に更新したときに起きたエラーと対処内容 - Qiita
表題通りの記事です。 これからnode.jsを10->12に更新する方の助けになれば幸いです。 確認環境 Ubuntu: 18.04.3 LTS node.js: 10.16.0、12.14.1 ビルドツール: gulp (後述しますが4系へのアップデートが必須でした) やったこと(全体像) n をつかってローカル環境のnode.jsを10->12に更新 (参考: nodeとnpmのバージョン更新方法) npm ciして、出てきたエラーを潰す firebaseの更新 node-sassの更新 npm run buildして、出てきたエラーを潰す gulpを3系->4系へ移行 エラー1 (firebaseの更新により解消) 最初はイージーケースから。 事象 npm ciしたところ、大量(体感3分)のログが出力され、最後に以下のエラーが吐かれました。 # これ以前にも大量のエラーログが出る c
kubernetesでgRPCするときにenvoy挟んでみたよ - Qiita
kubernetes(今回はGKE内)でgRPCの通信を場合にぶち当たる問題として、ロードバランシングの問題があります。 gRPCの通信は永続化されるので、そのままの状態で使うとバックエンドにあるサービスがスケールしても分散されないということになります。 具体例 上記のような構成でhoge-gateway(4pod)からhoge-app(10pod)に向けてコネクションプーリングが1で通信をする場合、hoge-appが最大4podしか使われない状態になります。 下記がその状態です。 GKE Container - CPU usage for hoge-app GKE Container - CPU usage for hoge-gateway 解決方法 これを解決する手段としてgRPCのclientLoadbalancingを使う方法がありますが、clientに依存する方法はあまりスマート
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
