2

特に共通コンポーネントを使用している場合、マイクロサービスでフロントエンドを管理するにはどうすればよいですか?私はインターネット上でいくつかのソリューションを見つけましたが、すべてにはいくつかの欠点があり、どれも私たちのためには適していません。マイクロサービスで共通のフロントエンドコンポーネントを管理する方法

私の問題を明らかにする。大規模な単一プロジェクトでは、5つ以上のグループの人々が異なるマイクロサービスに取り組んでいます。ほとんどの場合、フロントエンドに共通の共通コンポーネントがいくつかあります。これらのコンポーネントは、既に異なるプロジェクトでありながら完全に共有されているため、巨大です。今これらの共有コンポーネントを管理する方法、またはそれらを複製する必要がありますか?

私が最初に見つけた解決策は、ノードパッケージとnpmインストールのような単一のポイントからそれらのコンポーネントを共有して維持することです。しかし、この時点では、誰もがこれらのコンポーネントに依存するため、マイクロサービスのアプローチは壊れてしまいます。誰も必要に応じて直ちにメンテナンスすることはできません。将来的には異なるグループがコンポーネントからのニーズが異なるため、維持管理が非常に難しくなります。

第2は、プロジェクトごとにコンポーネントを複製し、マイクロサービスグル​​ープ内で開発することですが、今回は非常にフランケンシュタインになり、従うべき共通の概念を理解するのは難しいです。本当にエンタープライズプロジェクトであり、すべてのコンポーネントが仮想化の面で一致し、プロジェクトで再構築された他のコンポーネントを探す必要があります。

同じルール(フォントサイズ、色、アクションなど)に従うために必要なエンタープライズプロジェクトに適したマイクロサービス用のフロントエンドソリューションが必要です同時に異なるグループによって

どのようにバランスを取ることができますか?

@kayessのおかげで、チームはお互いに依存しないため、マイクロサービスに共有カーネルをどうやって適用するのですか?私が見つけた

+0

[共有カーネル](https://herbertograca.com/2016/02/05/ddd-14-mainting-model-integrity/)と[this](https: //www.infoq.com/news/2016/02/ddd-microservices)を参照してください。 – kayess

+0

私は共有されたカーネルを探しました、そして、 "システムの合意されたサブセットは、異なるチーム間で共有されるかもしれません。厳密な調整ルールが適用されます。私たちが望むものとまったく同じです。今質問は、チームがお互いに依存しないように、マイクロサービスに共有カーネルを適用する方法のようなものです。 – wertigom

+0

私はあなたの質問にこの情報を編集して簡潔な回答を得るべきだと思います。 – kayess

答えて

2

最初のソリューションは、共有、これらのコンポーネントを作成し、ノードパッケージのような1点から を維持し、異なるグループから を必要なときに、NPMインストールすることです。しかし、この時点でmicroserviceのアプローチは、私がmicroserviceのご理解が間違っていると信じてみんなが

これらのコンポーネントに依存することになりますので、壊れ です。 microserviceのファウラーの定義:要するに

、microservice建築様式1は、各 は独自のプロセスで実行されている、軽量 メカニズムと通信し、小さな一連のサービスとして、単一のアプリケーションを開発 へのアプローチです、多くの場合、HTTPリソースAPIです。

あなたの会社のマイクロサービスでは、共通のコンポーネントを使用できます。マイクロサービスは、コンポーネントよりもはるかに高度な抽象化レベルです。すべてのコンポーネントをマイクロサービスにしないでください。

各コンポーネントを別々のリポジトリで管理する必要があります。アップデートを公開し、互換性の問題を監視するには、semantic versioningを使用してください。

今後非常に難しいので、将来的には異なるグループになる可能性があります。 コンポーネントからのニーズが異なる可能性があります。

私はこれを維持することは難しいとは思わない。何百万人ものプログラマがこれらのフレームワークに依存し、それらを一緒に開発するため、構成の保守性は確かにそれほど高くはありません。それはメンテナーのスキルの質問です。

モノリシックリポジトリアプローチ(すべてのコンポーネントを1つのスタンドアロンレポに入れることができます)が可能ですが、これは非常に迅速に処理が難しくなると思います。

+0

あなたはいくつかのポイントをキャッチしましたが、私たちはまったく同じ方法ではないと思います。各コンポーネントをマイクロサービスにするつもりはありません。あなたが言ったように、マイクロサービスははるかに高い抽象化です。しかし、異なるマイクロサービスで同じコンポーネントを使用したいと考えています。それはマイクロサービス "A"と "B"があり、両方のチームで使用されるべき "componentA"があるようです。 AとBは時々同じサービスを使用していますが、同じapisと問題のないものについてはcdcテストを受け取り、すべてのマイクロサービスはそれらのapisを独自のドメインに変換するbffを持っています。 – wertigom

+0

しかしここで問題はフロントエンドであり、componentAはフロントエンドコンポーネントであり、apiと異なり、すべてのマイクロサービスで維持可能でなければなりません。 Apisはマイクロサービスの責任を負い、bffsもそうであり、それらを維持するのは簡単であり、彼らはマイクロサービスに拘束力がありますが、フロントエンドはすべてのチームの下にあり、bffのように分けることはできません。私は説明できることを願っています。 – wertigom

+0

@ wertigomあなたの問題は技術的な問題ではなく、組織的な問題です。セマンティックバージョニングを使用して、マイクロサービス全体で同じ(または互換性のある)コンポーネントバージョンを維持します。コンポーネントコードをコピー/貼り付けることで、悪夢がもたらされます。 –

1

フロントエンドコンポーネントだけでなく、同じ問題に直面しました。

したがって、「ビット」という単純なコンポーネント管理システムを構築しました。 我々はGitHubのにそれを解放:

https://github.com/teambit/bit

をそれが簡単にあなたのコードからこれらの成分を抽出し、バージョン管理、CI、すべてを含む1つの場所でそれらのすべてを管理することができます。 これにより、他のチームのメンバーは、同じ場所からコンポーネントを簡単にエクスポートしてインポートし、repos、アプリケーション、およびマイクロサービスでそれらを使用することができます。

お試しください。 community hubビットに自由に接続して、オープンソースコンポーネントをホストしたり、チーム/コミュニティを見つけて共有したりすることもできます。 MITライセンスを持つ再利用可能なコンポーネントの例と、array/diffと呼ばれる2つのテストに合格しました。

幸運を祈る!

関連する問題