4

Martin Fowler、Sam Newman、Adrian Cockcroft、Sudhir Tones の多数の記事を見て読んだ後、マイクロサービスは私のソフトウェアに非常に適しているようです。ただし、実装をより深く考えると、いくつかの懸念事項があります。

  1. 私のソフトウェアには UI があります。これを Web ベースのコンポーネントと呼びましょう。このコンポーネントは、10 ～ 20 の異なるマイクロサービスへの呼び出しを内部で調整/調整し (「プライベート マイクロサービス」と呼びましょう)、AJAX 呼び出しにデータを返す必要があります。このコンポーネントでオーケストレーション ロジックを結合するのは適切な設計ですか? それとも、ジョブを実行する別のマイクロサービスを作成し、このマイクロサービスへの呼び出しを委任するために Web ベースのコンポーネントを非常に薄くする必要がありますか?
  2. いくつかのパブリック API を公開する必要があります。上記の場合のように、呼び出しを委任するために別のレイヤーが必要ですか?

多かれ少なかれ、パブリック/プライベート マイクロサービスの設計パターンに関するものだと思います。

上記の懸念に対処するための良いパターンは何ですか?

2015 年 4 月 9 日更新:

API Gateway Pattern は実際に私の懸念に対処します。EAI パターンまたはセキュリティの考慮事項に関する他の回答にも同意します。

私の調査結果をさらに拡張すると、Netflix アーキテクチャにはいわゆる「エッジ サービス」があると思います。これは、Web ベースまたはデバイスからのリクエストを処理するフロント層であり、中間層サービスは実際にはマイクロサービスです。したがって、中間層サービスをエッジ サービスに昇格させるには、デリゲートが必要だと思います。これにより、中間層がクリーンで一貫した状態に保たれます。

さらにアイデアを得るには、https://github.com/cfregly/fluxcapacitor#project-overviewをご覧ください。

4

3 に答える 3

2

API Gateway パターンは、一連のマイクロサービスの前にパブリック API を実装するための良い方法です: http://microservices.io/patterns/apigateway.html

于 2015-03-19T17:57:19.830 に答える
1

Process Manager では、実行時間の長いトランザクションの間にすべてのオーケストレーション ロジックを配置できます。プロセス マネージャーは、イベントをサブスクライブし、イベントからコマンドを取得し、このコマンドを別の MS に委任できます。Sagaで処理できるすべての障害。長期実行ロジックが何らかの例外をスローした場合、Saga は補正アクションを実行する必要があります。

Process ManagerパターンとSagaパターンの詳細。

于 2015-03-16T13:27:59.137 に答える
1

これらの決定は、状態とセキュリティ (状態の特定のケース) という 2 つの懸念事項によって決定されます。
状態: 一時的な状態 (つまり、セッション データに押し込んだもの) をどのように維持しますか? それらをUIに保持したい場合は、純粋なマイクロサービスを保持することを考えることができます.そうしないと、その状態を保持するための調整「サービス」が必要になり、必要に応じてディスパッチセンターにもなります.

セキュリティ: 認証は、通常はクライアントに格納できない状態の特定のケースです。それは通常、人々をステートフルなアプリケーションに駆り立てるものです。それはまた、API 層と Web アプリケーション層の推進要因にもなります。API レイヤーは、おそらく何らかの認証トークン スキーム (OAuth などを参照) を通じて保護する必要があります。このトークンの検証とユーザー資格情報の取得は、かなり遅くなる可能性があります (比較的)。これは通常、各マイクロサービス呼び出しではなく、集中型サービスで最も効率的に実行されます。

于 2015-03-16T13:12:19.700 に答える