マイクロサービスとサードパーティAPI
最近、新しいアプリケーションに「マイクロサービス」パターンを使用しようとしているチームに参加しました。彼らはすでにAPIの実装を開始しています。最終的には、モバイルUIとWeb UIの両方のAPIにする必要があります。それらの実装についていくつか問題があります。
私にとって意味のないこと：
- すべての「マイクロサービス」は、1つのgitリポジトリと1つのソリューションファイル（.slnはdotnetを使用しています）内にあります。
- すべてのマイクロサービスが絡み合っているため、個別にデプロイすることはできません。
- 「ゲートウェイパターン」がありますが、ゲートウェイは他の「マイクロサービス」にhttp呼び出しを行っています。
- すべての要求と応答に「共通」プロジェクト（クラスライブラリ）があります。 （すべてのプロジェクトがそのプロジェクトを参照しています）。
- サードパーティのAPIごとに、それを使用する「マイクロサービス」を実装しました。 （モバイルがゲートウェイに要求を出し、次にゲートウェイがマイクロサービスに要求を出し、そのマイクロサービスがサードパーティに「実際の」http呼び出しを行っていると考えてください）これは、Web UIパーツでも同じです。
彼らが正しいやり方でやっているとは思いませんが、どこから始めればいいのかわかりません。リクエストを追跡しようとしましたが、うまくいきませんでした。ソリューションファイルには大量の定型コードがあります。悪いことは、期限があり、大きなリファクタリングに参加したくないということです。
次のステップは何ですか？
それらのことについて従うべきパターンはありますか？
たぶん、マイクロサービスは私たちには良くありません。
すべての「マイクロサービス」は、1つのgitリポジトリと1つのソリューションファイル（.slnはdotnetを使用しています）内にあります。
これで結構です。実際、私は他の方法ではそれをしません。
すべてのマイクロサービスが絡み合っているため、個別にデプロイすることはできません。
これは重大なアーキテクチャ上のミスであり、プロジェクトの俊敏性と稼働時間に影響を与えます。サービスを分離する全体のポイントは、展開の柔軟性です。これはおそらく私が注目する1つの箇条書きです。
「ゲートウェイパターン」がありますが、ゲートウェイは他の「マイクロサービス」にhttp呼び出しを行っています。
これが厄介に思われる理由はわかりますが、実際にはかなり正常です。余分なホップがありますが、最新のハードウェアでは、これらのサービスを軽量に維持している場合はそれほど問題にならず、実際にはセキュリティモデルによってはかなり価値がある場合があります。
すべての要求と応答に「共通」プロジェクト（クラスライブラリ）があります。 （すべてのプロジェクトがそのプロジェクトを参照しています）。
コード管理とリリースモデルによって、これは良いか悪いかのどちらかです。フレームワークがあると便利ですが、リリースプロセスは簡潔に行う必要があります（整然と高品質のビルドが得られ、おそらくNugetなどを介して洗練されたパッケージとして公開されます）。
サードパーティのAPIごとに、それを使用する「マイクロサービス」を実装しました。 （モバイルがゲートウェイに要求を出し、次にゲートウェイがマイクロサービスに要求を出し、そのマイクロサービスがサードパーティに「実際の」http呼び出しを行っていると考えてください）これは、Web UIパーツでも同じです。
少し無駄に思われますが、サードパーティのサービスがすべて異なる方法（WCF、SOAP、REST、RPC）で機能する場合、このような facade を使用してサービスを統一することは実際に非常に役立ちます。これは私にとって赤旗ではありません。
マーティンのコメントは次の点に当てはまると思います。マイクロサービスは複雑なパターンであり、正しくなるには数回の反復が必要です。これらはすべて修正可能です。