soa - Webサービス戦争の粒度のベストプラクティス

Question

戦争ごとに少数のWebサービスを使用して多数の小規模な展開を行うのがよいでしょうか、それとも戦争ごとに多数のWebサービスを使用する1つの大規模な展開を行う方がよいでしょうか。

この場合、すべてのWebサービスが共通のバックエンドを共有し、コード共有の恩恵を受けると想定します。小さな戦争の場合、共有コードをjarプロジェクトに入れて、すべての小さな展開から含める必要があります。これで、各戦争を個別にテスト/展開できますが、バックエンドが変更された場合は、1つだけではなく、すべてを更新する必要があります。

この場合のバックエンドは、ベンダーが提供するさらに別のWebサービスです。これに対する更新は通常、下位互換性がありますが、常にそうであるとは限りません。

明確な答えがないことは知っていますが、共有された経験は役に立ちます。

Answer 1

原則として、サービスごとに 1 つの戦争が必要です。ポイントは、サービスが単一の Web サービスである必要はないということです (実際、一部のエンドポイントは Web サービスだけでなく、他のテクノロジでもかまいません)。サービスは、複数のエンドポイントとコントラクトを公開できます。関連するコントラクトをグループ化します。たとえば、ユーザー管理を処理するサービスは、ユーザーとグループの両方に API を持つことができます。ただし、注文に関連する API は、おそらく別のサービスに属します (したがって、戦争)。小さすぎるサービスの断片をスライスすると、私がナノサービス アンチパターンと呼ぶものを得ることができます。この場合、サービスのオーバーヘッドは、サービスから得られるユーティリティよりも大きくなります。