NodeJSのマイクロサービスアーキテクチャ

Question

私はサイドプロジェクトに取り組んでおり、Skeltonプロジェクトをマイクロサービスとして再設計することを望んでいましたが、これまでのところ、このパターンに従うオープンソースプロジェクトは見つかりませんでした。何度も読んで検索した後、私はこのデザインについて結論を出しましたが、まだいくつかの質問と考えがあります。

ここに私の質問と考えがあります：

同じマイクロサービスからの2つのノードがある場合、APIゲートウェイを十分にスマートにしてリクエストをロードバランスする方法は？
マイクロサービスの1つがダウンした場合、ディスカバリーはどのように知る必要がありますか？
同様の実装はありますか？私のデザインは正しいですか？
ユーレカまたは類似のものを使用する必要がありますか？

sezerug · Answer

あなたのデザインはOKのようです。また、API Gatewayアプローチを使用してマイクロサービスプロジェクトを構築しています。ゲートウェイサービス（GW）を含むすべてのサービスはcontainerized（dockerを使用） Java applications（spring bootまたはdropwizard）。nodejsを使用して同様のアーキテクチャを構築することもできます。質問に関連して言及するいくつかのトピック：

Authentication/Authorization： GWサービスは、クライアントの単一のエントリポイントです。すべての認証/承認操作は、GWでJSON web tokens（JWT）を使用して処理されます。これには、nodejs librayもあります。ユーザーの役割などの認証情報をJWTトークンに保持します。 GWでトークンが生成されてクライアントに返されると、各リクエストでクライアントがHTTPヘッダーでトークンを送信し、次に、クライアントが特定のサービスを呼び出すために必要なロールを持っているか、トークンの有効期限が切れているかをトークンで確認します。このアプローチでは、サーバー側でユーザーのセッションを追跡する必要はありません。実際にはセッションはありません。必要な情報はJWTトークンにあります。
Service Discovery/Load balance：私たちはdocker、docker swarmを使用しています。これは、Dockerエンジンにバンドルされているドッカーエンジンクラスタリングツールです（Docker v.12.1以降）。）。私たちのサービスはDockerコンテナです。 Dockerを使用したコンテナ化されたアプローチにより、サービスの展開、保守、スケーリングが簡単になります。プロジェクトの開始時に、図面と同様に、Haproxy、RegistratorとConsulを一緒に使用して、サービス検出と負荷分散を実装しました。その後、docker networkを作成してdocker swarmを使用してサービスをデプロイする限り、サービスの検出とロードバランシングにそれらは必要ありません。このアプローチを使用すると、dev、beta、prodのようなサービスの分離された環境を、環境ごとに異なるネットワークを作成することにより、1つまたは複数のマシンで簡単に作成できます。ネットワークを作成してサービスを展開したら、サービスの検出と負荷分散は関係ありません。同じdockerネットワークで、各コンテナーは他のコンテナーのDNSレコードを持ち、それらと通信できます。 docker swarmを使用すると、1つのコマンドでサービスを簡単にスケーリングできます。サービスへのリクエストごとに、Dockerはリクエストをサービスのインスタンスに分散（負荷分散）します。

BlackStork · Answer

あなたのデザインは大丈夫です。

APIゲートウェイがCAS /ある種の認証（サービスの1つを介して-つまり、ある種のユーザーサービス）を実装する必要があり、すべての要求を追跡し、ヘッダーを変更してリクエスターのメタデータを保持する必要がある場合（内部ACL /スコーピング用）-APIゲートウェイはノードで実行する必要がありますが、負荷分散/ HTTPSを考慮したHaproxyの下にある必要があります
発見は正しい位置にあります-あなたのデザインに合うものを探すならどこにも見えません領事。
サービスとAPIゲートウェイにconsul-templateを使用するか、独自のマイクロ検出フレームワークを使用して、起動時にエンドポイントデータを共有できます。
ACL /認証はサービスごとに実装する必要があり、API Gatewayからの最初のリクエストはすべての認証ミドルウェアの影響を受ける必要があります。
「内部」システム内でライフサイクルを追跡できるように、各要求に要求IDを提供するAPI Gatewayで要求を追跡するのは賢明です。
メッセージング/ワーカー/キュー/キャッシュ/キャッシュの無効化などの高速なメモリ内のものにRedisを追加します（1つがないとすべてのMSアーキテクチャを処理できません）-または、分散トランザクションが多く、メッセージングが多い場合は、RabbitMQを使用します
これらすべてをコンテナー（Docker）でスピンして、保守とアセンブルが容易になるようにします。
BIについては、なぜそのためのサービスが必要なのでしょうか。外部のELK Elastisearch、Logstash、Kibanaなど）を使用して、ダッシュボード、ログ集計、巨大なビッグデータウェアハウスを一度に作成できます。