Docker イメージを実行するたびに、ノードのシステム/アーキテクチャ間の非互換性に関するエラーが発生し続けます...

私はこのコマンドを試しました：

しかし、問題はまだ続きます...

より多くのコンテキストのための私のファイルは次のとおりです。

Docker イメージを実行しようとした後、完全なエラーが発生しました

Dockerfile (gRPC ノード サーバーを実行)

Booksserver.js (GRPC サーバー)

基本的に、メイン ディレクトリと Books ディレクトリがあります (一般的なファイル構造、他にもありますが、これらは重要な部分です)。そのため、main から booksServer へのリクエストを発行しても、ノード モジュールが見つからないため機能しません。

これは、ノード モジュールが特定のパス '/usr/src/app'の docker コンテナー内にあるためです。

ブック (サービス/コンテナー) がこの特定のパス内に適切なノード パッケージを持っていることを main.js に確認させるにはどうすればよいですか?

docker-compose は使えると思いますが、まずは docker-compose を使わずに個別にテストしたいと思いました。

内部

エラー：

書籍の Dockerfile

メイン DockerFile

そのため、この「位置0のJSONの予期しないトークンu」エラーが発生し続けます。私は現在、顧客のgRPCサーバーにgRPCリクエストを行っているメインのイニシエーターからリクエストを行っています。

ファイルをコンテナ化せず、各ディレクトリに手動で npm インストール パッケージをインストールすると、スムーズに動作します。ただし、ファイルをコンテナ化すると、何らかの理由でこの問題が発生します。

通常、この問題は非同期リクエストで発生し (gRPC は非同期なので理にかなっています)、完了するまで競争していると思いますが、そうすることができません。しかし、dockerFile は文字通り私が手動で行っていることを行っています (これは機能します...)

私は現在、なぜこれが事実なのかについて迷っています。

エラー

ファイル構造

Docker ファイル(全て)

このコマンドfile.protoを使用してから にコンパイルする方法を知っています。file_pb.js

file_pb.jsしかし、どうすれば からに変換できますかfile.proto

私は 2 つのサービス A と B を実装しました。A は gRPC (Mali で grpc-node を使用) と純粋な HTTP REST 呼び出しの両方を介して B と通信できます。

リクエストのサイズは無視できます。

応答サイズは、次のような 1000 アイテムです。

A と B の両方がサービスとして GKE にデプロイされ、kube-proxy を使用して内部ネットワーク経由で通信します。

私が発見したのは、REST バージョンが gRPC よりもはるかに高速であることです。REST 呼び出しの p99 は 1 秒未満であり、gRPC の p99 は 30 秒を超えることがあります。

詳細

ノードのバージョンと OS:node:14.7.0-alpine3.12

依存関係:

gRPC オプションを設定してクライアント側の TCP プーリングを作成しましgrpc.use_local_subchannel_pool=1たが、これは役に立たないようです。

call.startBatchgrpc libの呼び出しがサイズ〜51kbのデータを送信するのに何秒もかかったことがログからわかるように、問題はサーバー側にあるようです。これは REST バージョンよりもかなり遅いです。

また、サービスの CPU とネットワークが正常であることも確認しました。REST バージョンは 2 mbps を超える速度で送信できましたが、gRPC バージョンは最大 150 kbps しか管理できませんでした。

netstatサービス B で (gRPC で)実行すると、多くの ESTABLISHED TCP 接続が表示されます (TCP プーリングのために予想どおり)。

私の疑いは、grpc-core C++ コードが REST より最適ではないということですが、証拠はありません。

次に見るべきアイデアはありますか？助けてくれてありがとう

更新 1

いくつかのベンチマークを次に示します。

設定

Blazemeter --REST--> services A --gRPC/REST--> service B

• リクエストボディ（両方のラグ）は無視できます
• service Aはノードサービス + Koa
• service B3 つのオプションがあります。
  • grpc-node: grpc-node を持つノード
  • gRPC + Go: 同じ gRPC サービスの Go 実装
  • REST + Koa: Koa のあるノード
• Blazemeter --> service A: 応答ペイロードは無視でき、すべてのテストで同じです
• serivce A --> service B: gRPC/REST 応答ペイロードは 1000 個ですProductPrice:

サービスは GCP の Kubernetes にデプロイされ、

• インスタンスタイプ:n1-highcpu-4
• サービスごとに 5 つのポッド
• 各ポッドに 2 つの CPU、1 GB のメモリ
• クラスター IP を使用する kube-proxy (インターネット経由ではない) (ヘッドレスをclusterIP: Noneでテストしたところ、同様の結果が得られました)

ロード

50rps

結果

grpc-node を使用したサービス B

Go gRPC を使用したサービス B

Koa で REST を使用するサービス B

ネットワーク IO

観察

• gRPC + Goとほぼ同等ですREST（gRPCの方が速いと思いました）
• grpc-nodeよりも 4 倍遅いREST
• ネットワークがボトルネックではない