サービスファブリックアプリケーション間の通信

Question

異なるサービスファブリックアプリケーションで異なる機能をグループ化しました。各サービスファブリックアプリケーションは、特定のスコープ内の一連の機能（例えば、ニュース、ブログ、ユーザーはすべて個別のアプリケーション）を担当します。さまざまなチームがこれらの機能範囲で作業することができます。

各アプリケーションには、/ usersや/ newsや/ blogsのような公開REST APIがあります。したがって、公開されているWebサイトでは、これらのエンドポイントを呼び出して情報を取得/ポストすることができます。

しかし、多くの場合、これらのアプリケーションは互いに通信する必要があります。しかし、これを設定する最良の方法は何ですか？

• （各自の公開されていない独自のIPポートを使用して）内部でのみ使用する新しいHTTPエンドポイントを各アプリケーションに作成します。疎結合。
• RPC呼び出しを使用します（ただし、アプリケーション間で「ハード」リンクが作成されます）。強い結合。

今のところ私は別のHTTPエンドポイントが行く方法だと思いますが、RPC呼び出しが優れているのだろうかと思いますか？それは、設計哲学から、アプリケーション間でRPC呼び出しを使用できるのですか？それとも、アプリケーションが更新され、インターフェースが変更されたときに、これが私を困惑させるでしょうか？

ここで使用する別のパターンはありますか？

Answer 1

サービスの署名を変更する場合や、新しいものを追加する場合は、必ず書き換えてください。したがって、どちらの場合も、変更されたコードと呼び出しコードに触れなければなりません。

RPCの問題は、サービスを使用したい場所でこのインターフェイスにアクセスできるようにする必要があることです。したがって、実際には個別にサービスをアップグレードすることはできません。 HTTP通信はこの問題を解決する可能性があります。

しかし、HTTP通信であなたがにつながるかなり複雑なコード、記述する必要があります。新しい人々のためのロジックとアーキテクチャを理解することで、新たなバグを

• 場所
• 困難を
• おそらく必要になります誰かがそれらを維持しなければならないでしょう
• アップデートを登録する方法について考える必要があります - どのサービスを最初に更新する必要がありますか？

はい、あなたは依存関係から解放されています（完全には私のものではありません）が、作業量とメンテナンスの量は少し増えます。 RPCは安価でシンプルです。

サービスを個別にアップグレードすることが重要であり、サービスのアップグレードが停止したり、他のサービスに影響を与えたりしない場合にのみ、RPC over HTTPを使用します。

Answer 2

私はmicroservicesセッション/サミットに出席し、スピーカーはREST APIエンドポイントを持つ他のマイクロサービスにアクセスすることを推奨しました。

私は、私たちが電話で標準化を維持することができ、維持しやすいので同意します。ちょっとした考え。