web-dev-qa-db-ja.com

「プラグインとしてのマイクロサービス」のアーキテクチャパターンはありますか？

簡単に言えば、Jenkinsと同様に、ユーザーがプラグインを介して追加の機能を追加できるWebアプリケーションを、自己啓発の目的でのみ作成したいと思います- https://jenkins.io/doc/book/managing/plugins / -拡張ポイントを介してそれを行います。

それに加えて、同時に、各プラグイン自体が任意のホスト、任意のテクノロジースタック上で自己持続可能なプロセスになり、スケーラブルで、コアシステムを持つホストに影響を与えないようにしたいと考えています。マイクロサービスのように。

私にとっての主なポイントは次のとおりです。

  • ウェブUIを介してオンザフライで追加/削除されるプラグイン。

  • コアまたはその他の同じホスト上に任意に配置するプラグイン
    ホスト;

  • I/Oとパフォーマンスの両方でスケーラブルになるプラグイン。

  • プラグインは任意のテクノロジーで記述され、その機能と使用可能な設定/コントロールをコアに公開するためにいくつかの基本的な契約に従うだけで済みます。

私の脳はそのような単純なアイデアしか生み出せなかった https://svgshare.com/s/FSo

結局のところ、私はここでホイールを再発明しようとしているような気がします。プラグインまたはマイクロサービスアーキテクチャのいずれかに、これらの要件をカバーする準備ができているソリューションがあります-本当にありますか？

architecturemicroservicesarchitectural-patternspluginsplugin-architecture
3
lGSMl

2つの概念の間に非互換性があるようです：

  • マイクロサービスは、設計上、疎結合されたままの独立してデプロイ可能なサービスであることを意図しています。

  • プラグインは既存のものを拡張するためのものです。つまり、プラグイン自体には値がありません。

しかし、マイクロサービス指向の考え方で柔軟性のニーズに適合する client-side discovery pattern に興味があるかもしれません。あなたはそれを使うことができます：

  • 古典的なプラグインアーキテクチャ：適切なマイクロサービスを見つけ、拡張された基本サービスにその機能を使用できるプラグインを作成します。
  • 他のマイクロサービスを動的に検出するマイクロサービスとして、wholdeアプリを設計する。
0
Christophe

あなたの話していることがすでに存在するのかわかりません。しかし、それは珍しいことではないと感じています。 （マイクロ）サービス指向アーキテクチャの「理想的な状態」のように聞こえます。 （マイクロ）サービス指向アーキテクチャーの元の「夢」は、基本的にあなたが説明しているものでした。新しいサービスを「単純に」追加すると、既存のサービスと自動的かつシームレスに統合されます。

新しいサービスが残りのサービスとコアで「フックアップ」するアーキテクチャの設計は、比較的単純でなければなりません。新しいサービスは、プレゼンスを全員にブロードキャストして、接続をセットアップできるようにすることもできます。または、中央ブローカーに連絡して、必要なサービスまたは使用できるサービスを発見することもできます。

難しいのは、コアとプラグインの間のAPIを設計することです。これにより、想定しているような拡張性を実際に実現できます。 APIは、以前は考えていなかった機能の将来の拡張性を可能にするために、本当に良い設計を持つ必要があります。追加するプラグインごとにAPIを変更する必要がある状況に実際に入る必要はありません。

別の問題は、システム全体のデバッグです。異なるサービス間の予期しない緊急動作を把握するには、多くの監視と計測が必要になります。

1
Euphoric

簡単に言えば、Jenkinsと同様に、ユーザーがプラグインを介して追加の機能を追加できるWebアプリケーションを、自己啓発の目的でのみ作成したいと思います- https://jenkins.io/doc/book/managing/plugins / -拡張ポイントを介してそれを行います。

これを行うには、ユーザーがメッセージを送受信するためのWebhookを提供します。この例は Shopify にあります

サードパーティのサービスが聞いたり反応したりするのに役立つと思われる一般的なイベントを教育アプリケーションに設定できます。次に、ユーザーがプラットフォームにWebhookを登録すると、これらのイベントがサブスクライブされます。その後、これらのイベントがトリガーされると、ユーザーのサードパーティサービスが呼び出されます。

デプロイメントトポロジ（ホスティング、テクノロジー、オーケストレーションなど）は、プラットフォームの観点からは単なるHTTPエンドポイントであるため、完全に不可知である必要があります。

注：引き続きセキュリティに注意する必要があり、ユーザーのサービスによるインフラストラクチャのダウンを許可しないでください。

0
Shawn Lim