Feathers: マイクロサービス：サービスを分割してアプリをリファクタリングするための推奨される方法は？

そうです、まだドキュメントはあまりありません。それを追跡するために、少し前にhttps://github.com/feathersjs/feathers/issues/157を作成しました。 あなたが言及した2つのトピックについての私の考えのいくつかはここにあります：

最初に2つのサービスを備えたサーバーがあると仮定しましょう。

app.use('/users', memory())
  .use('/todos', memory());

ユーザーサービスは、1つのサーバーが処理できるよりも多くのトラフィックを取得しているため、別のアプリを作成して別のシステムに移動します。

// server1
app.use('/users', memory());
// server2
app.use('/todos', memory());

/todosサービスがリモートサービスと通信できるようにするには、 Feathersをクライアントとして使用して接続できます（WebSocketは高速で双方向なので、サーバー間通信に使用しませんか？）：

// server2
const client = require('feathers/client')
const socketClient = require('feathers-socketio/client');
const io = require('socket.io-client');

const socket = io('http://other-server.com');
const otherApp = client().configure(socketClient(socket));

app.use('/todos', memory())
 .use('/users', otherApp.service('users'));

これは基本的に、WebSocket接続を介してユーザーサービスをリモートサービスに透過的に渡します。 元の/usersエンドポイントを使用するものは、何も変更する必要はありません。

認証に関しては、さまざまなオプションがあります。 上記のシナリオでは、 server2が依然としてクライアントの唯一の通信ポイントであるため、 server1が他のサーバーのIPアドレスをホワイトリストに登録するのが最も簡単な方法です。 最終的に、 server2は、ユーザー認証を処理するゲートウェイになり、サービス呼び出しを他のサーバーに渡すだけで済みます（発信元IPアドレスを確認する以外に認証について心配する必要はありません）。

返信ありがとうございます！ このトピックを公式ドキュメント（おそらくガイドのサブセクション）で取り上げる予定はありますか？ この点で私が貢献できるかどうか教えてください。

絶対に。 そして、私たちは間違いなくいくつかの助けを使うことができました。 たぶん、最初にガイドで見たいものを集めてから、いくつかのデモアプリケーションを作成しましょう。

💯@ dafflは大

@dafflバックエンドマイクロサービスでfeathers-clientを使用して言及したアプローチでは、socket.ioが使用されているため、ストリーミングデータを介した双方向通信が可能です。 フェザーには、このシナリオのセマンティック/ APIがすでにありますか？ マイクロサービスが、ブラウザークライアントではなく、他の関心のあるマイクロサービスのイベントを公開する状況を考えています。

はい、しかしなぜ他の関心のあるサービスもWebSocketを使用できなかったのですか？ 他のプロバイダーを追加することを考えています（たとえば、さまざまなメッセージングサービス用）が、今のところWebSocketは十分に高速であるように思われ、ブラウザーでのみ使用できるようにどこにも記述されていません。

@daffl @ekryskiフェザーアプリケーションが配布されるようになると、少なくとも1回の配信（ack）、べき等、トランザクション、バックプレッシャー（キュー）などの問題にも対処する必要があります。「feathers-service-労働者？」..すなわち。 永続的なamqp（つまりrabbitmq）キューまたはredis（つまりkueを使用）からのイベントを消費する外部プロセス？

@dafflあなたの答えの前に私はよく理解していなかったと思います。 関心のあるサービスがWebソケットを使用してプロデューサーサービスにサブスクライブし、通常のイベントAPIを使用してプロデューサーに新しいイベントを公開する限り、これをフェザーで実装するだけで十分です。

@justingreenbergに同意します。対処すべき別の問題は、責任のあるマイクロサービスがオフラインになったときにリクエストを再生することです（クラッシュ、更新など）。 技術的には、これもメッセージキューを使用して対処します。

これについて何か進展はありますか？ 私は本当にいくつかのドキュメント/実用的な例を見たいです。 特に認証の処理方法に関して。

@imns私たちはこれに取り組んでいます。 私は例に取り組み始め、アプリを分割しましたが、認証の設定方法にいくつかの制限があることに気付きました。 そのため、現在、これをより適切にサポートするために認証をリファクタリングしています。 それが着陸するのに約1週間かかるはずです。

ああ、私は今これをとてもひどく使うことができた：D

好奇心から、複数のフロントエンドでも機能するように認証を作り直していますか？ 最近の大規模なアプリの多くは、バックエンドでマイクロサービスを使用していますが、フロントエンドアプリも分割していると思います。

少し余分なお金がある場合は、この本を読むことをお勧めします： https ：//www.amazon.com/Building-Microservices-Sam-Newman/dp/1491950358/ref=sr_1_1？ie = UTF8＆qid = 1469071253＆sr = 8-1＆keywords =マイクロサービス

みんな、これに関する更新はありますか？ ありがとうございました。

@juanpujol最新情報は常にこのチケットに含まれています。 でもチェックしてくれてありがとう。

（ここのmarcfawzi）

スレッド全体を読んだわけではありませんが、サービスごとにデータベースを使用できると思います（Micreoservicesアーキテクチャでは、抽象化を維持するためにこの分離が重要です。そうでない場合、すべてのサービスが同じデータベースを共有していると、人々を妨げることになります。統一されたサービスAPIを使用してサービスを構成する代わりに、サービスモデル間の関係を定義すること（マイクロサービスの抽象化の違反）から？

それを本当に妨げるものは何もありません、私はあなたがそれをしないのはあなた次第だと思います。 モデルと関係をORMレベルで定義する場合にのみ、実際に問題になります。 別のサービスを呼び出すことによってサービスレベルで関係を取得することは、マイクロサービスの抽象化に違反するとは思いません。

ええ、まさに私が意味したことです。 私は、各サービスが独自のデータベースを持っているサービスの分離は、ORMレベルではなく、サービスインターフェイスを介して構成を強制する確実な方法であると考える傾向があります。

ただし、Feathersはマイクロサービスフレームワークよりも一般的であるため、ここではすべて問題ありません。 ありがとうデビッド！ これは私がそれを掘り下げるほど見栄えが良くなり続けます！ すべての周りの素晴らしい仕事！

ここでこれについて言及しようと思ったのは、マイクロサービス環境でFeathersを使用する際に発生する問題のいくつかを解決するためです。 これは最初の実装にすぎませんが、何か貢献できることがあれば、ここに気軽にアクセスして

有望に見える@ zapur1 ...ディスカッションを始めるためにコメントを投稿しました

https://github.com/feathersjs/feathers-syncをrabbitMQ、Redis、またはMongoDBとともに使用して、サービス間のメッセージブローカーとして使用し、すべての同期を維持することもできます。

@ekryski feathers-sync 、少し異なる問題を解決します。名前付きサービス（Feathersサービスではなくマイクロサービススタイルのサービス）の領域内でイベントを1回だけ受信する場合はどうなりますか？ 単一のAPIアプリからイベントを受信する単一のサービスの複数のインスタンスがある場合、それぞれがイベントを受信し、まったく同じコードの複数のインスタンスでそのイベントが受信されたときに実行されるアクションを複製する可能性があります。

@ekryskiリポジトリをもう一度確認したところ、zapur1 / feathers-rabbitmqが「警告」で言及した問題を正確に解決しました。

socketClientによってサービス1をサービス2に接続する場合、サービス2にマルチインスタンスがある場合、負荷分散を実装するにはどうすればよいですか:(

socketClientを介して接続する別のサーバーサイドアプリを作成する場合、設定されている制限に関係なくすべてのサービスを利用できるように認証するための最良の方法は何ですか。

https://github.com/kalisio/feathers-distributedを使用して、これに2セントを追加しhttps://github.com/feathersjs/feathers-syncとは異なり

• 認証管理
• APIゲートウェイと負荷分散
• リモートフックの呼び出し
• ..。

サーバー1とサーバー2を含む例の@dafflは、サーバー2の/usersサービスをどのように保護しますか？ サーバー2でそのサービスを定義している場合、特定のサービスフックファイルでフックを使用できますが、 app.use('/users', otherApp.service('users'));を実行しているため、サーバー2からのそのサービスへの呼び出しのみが実行されるようにするにはどうすればよいでしょうか。ユーザーが最初に認証した場合は？

編集：
Nvm、私は考えがあると思います： const usersService = app.service('users') 、次にusersService.hooks(hooks)ようなことを行うことができます。ここで、フックにはエンドポイントを正しく保護するために必要な認証フックがありますか？

分散認証を行う方法については、 https ：

サービスを分割する方法はいくつかあり、それぞれに長所と短所があります。 Feathersにとって一般的に重要なことの1つは、セッションがなく、JSONWebトークンだけであるということです。 JWTはステートレスであり、同じシークレットを共有する任意のサーバーで読み取ることができるため、中央のセッションストアが必要ありません。 私が考えることができる2つの主なオプションは次のとおりです。

1. 接続されているすべてのクライアントの承認と管理を処理するメインアプリケーションがありますが、データベースと通信するサービスではなく、内部ネットワーク内の個別の単純な個別のAPIサーバーに接続します。 これはセットアップが簡単で、内部APIサーバーが非常にシンプルで、認証をまったく必要としないという利点があります（メインアプリケーションはすべてを実行でき、認証されたユーザーの制限に従ってクエリを実行するため）。 欠点は、メインアプリケーションが依然としてボトルネックであるということです（ただし、基本的に内部APIのプロキシとして機能するため、負荷が減少します）。

1. すべてのクライアントは、JWTを使用して必要なすべてのAPIサーバーに接続します。 JWTは、個別の認証（またはユーザー）APIによって作成されます。 唯一のボトルネックは、一般的なユーザーサービスから最新のユーザー情報を取得することであるため、これはよりスケーラブルなソリューションです（常に必要な場合もありません）。 欠点は、クライアント側での管理がより複雑であり、認証（少なくともJWTの場合）をすべてのサーバーで構成する必要があることです。 ただし、JWTはステートレスであるため、共有セッションは必要ありません。