.NETでモノリシックアーキテクチャからマイクロサービスアーキテクチャに切り替える際の重要な考慮事項は何ですか？[閉まっている]

モノリシックモンスターをマイクロサービスベースのアーキテクチャに徐々に分解することを検討しています。私たちには5つのチームがあり、各チームには2〜3人のC＃開発者、少なくとも1人のデータベース開発者、および2人のQAエンジニアが含まれています。モノリシックアーキテクチャからマイクロサービスへの大きな文化とパラダイムシフトに加えて、技術的な課題もあります。同じ間違いをしないように、コミュニティに知恵とアドバイスをお願いしたいと思います。

.NETベースのマイクロサービスが実稼働システムでうまく利用されている良い業界の例はありますか？次の戦略は何でしたか？

• 組織：.NETソリューション/プロジェクトをどのように編成しましたか？
• 開発計画：開発計画に関して、チーム間でどのように作業を分割しましたか？マイクロサービス全体で契約のコンプライアンスを確保するための全体的な戦略は、チーム間で交渉されましたか？
• 負荷分散/ルーティング/ APIゲートウェイ：負荷分散、冗長性、スケーリングの戦略は何でしたか？完全な非同期アーキテクチャを使用して、マイクロサービス通信にキューを使用しましたか、それともロードバランサー/ APIゲートウェイを介してピアツーピアで実行しましたか？なぜ？
• テスト自動化：テスト自動化をどのように処理しましたか。マイクロサービスアーキテクチャでは、これと継続的な統合が絶対に必要であるようです。どうやってそれをやりましたか？
• 展開：どのように展開していますか？1つのVM /マイクロサービス、1つのコンテナー/マイクロサービス、またはその他の何か？各マイクロサービスがデータストアを持つことを考慮しなければ、数十のデータベースがあるという事実をどのように処理しましたか？それはインフラストラクチャに何を行い、DBAはそれをどのように処理しましたか？
• インフラストラクチャ：このアーキテクチャでインフラストラクチャはどのように拡張されましたか。それはとてもおしゃべりで、あなたはそれを微調整する必要がありましたか、それともネットワークが問題なくそれを処理しましたか？セルフホストですか、それともクラウド内ですか？
• モニタリング：あなたのモニタリング戦略は何ですか？数百のマイクロサービスではないにしても、数十のタブをどのように維持していますか？それは主にロギングと集中監視によるものですか？

私はいくつかのマイクロサービスプロジェクトに取り組んできました。ビッグDBアプローチではこれ以上拡張できないため、必然的に企業はこの方法を採用しました。ここに私の経験/お勧めです。

組織。マイクロサービスごとに1つのソリューション。共有ライブラリのnugetパッケージ

開発。より大きなチーム5-6は、一度に1つの機能領域を開発します。インターフェース化されたサービスにリファクタリングします。メモリー内サービスをマイクロサービスのクライアントに置き換えます。

テスト。実際の入力/出力データを使用した統合テスト。実行中のインスタンスに対してそれらを起動して、それらが稼働していること、ローカルインスタンス、テスト/ uat環境、ユニットテスト用のメモリ内インスタンスが正しいことを確認できるようにする必要があります。ヘルスチェックインターフェースなどを介してインスタンスのバージョンをテストできることを確認してください

スケーリング。キューベースは、多段分散プロセスを処理できるので最適です。Rabbit MQ、Zero MQ、MSMQなど。ただし、負荷分散されたRESTサービスは、rpcスタイルの呼び出しには問題なく、簡単に開始できます。

展開。たこ。Mongoのようなdb-sql.dbsを自己作成するdbプロジェクト。複数のデータベースがある場合は、間違ったルートに進んでいると思います。代わりに、プロセスに必要なデータを含む重いメッセージと、独自のAPIの背後に隠されたデータストレージ用のいくつかの大きなdbを用意します。

DBAなし！あなたがDBAがSQLを書いているなら、あなたはそれを間違っています。

インフラ。問題はありません。キューから読み取ります。処理します。キューに書き込みます。小規模または頻繁に呼び出されないサービスのクラウドマイクロインスタンスでも、ボックスごとに複数のインスタンスを使用できます

モニタリング。すべてのサービスのヘルスチェックインターフェイスは、ソフトウェアを監視し、大きなボードで定期的に呼び出されます。

自動フェイルオーバーとリカバリは重要です。インスタンスは必要に応じて起動し、ステートレスである必要があります。そのため、1回のクラッシュでサービスがオフラインになることはありません。

主な問題は、多くのサービスが停止することではなく、マイクロサービスの性質がこの点でサービスを堅牢にするためです。処理できない/処理されていないメッセージの処理方法。

logstashなどを使用して、メッセージフローを追跡し、問題の場所と内容を調べます。失敗したメッセージを再実行できることを確認して、修正されたプロセスが中断したところから続行できるようにします。

最後のメモ。すべて、dll、nugets、データ、インターフェースのバージョンを管理します。複数のサービスの複数のインスタンスと履歴メッセージがそこに浮かんでいると、問題の主な原因になる可能性があります。

過去2年間、モノリスをマイクロサービスに分割しているので、ここではいくつかのことを行っています

組織：各サービスはそれ自体がソリューションとなり、他のサービスとの共通プロジェクトはありません。そして、各バージョンが.nugetパッケージであるコントラクト自体が個別のソリューションになりました。

開発：各チームがアプリケーションの1つの部分に取り組んでいました。契約の作成から開始した新しいサービスごとに、サービスを分離しましたが、メインのアプリ/ソリューションの一部を維持しています（HTTP呼び出しはまだありません）。そして、将来のステップで、このサービスを完全に分解する予定です。

ルーティング：すべてのサービスはロードバランサーの背後にあり、各サービスは数台のVMにデプロイされます。複数のサービスで同じvmを共有しています。Windows vmが正常に機能するには約2Gが必要ですが、サービスは小さいため、サービスごとに1つのvmを使用することは、リソースの無駄遣いのように思えました。ユーザーの操作に関連しない一部のサービス（電子メール/通知の送信など）は、キューで動作しています。

テスト：最初は、サービスを単体でテストし、クライアントの異なるバージョンとPact.Netを使用したサービスとの間のコントラクトの互換性をテストするだけで十分だと考えました。しかし、サービスの新しいバージョンがデプロイされておらず、以前のバージョンで作業していたときに問題が発生しました。すべてのテストに合格しましたが、プラットフォーム全体が正常に機能していませんでした。したがって、メインフローにいくつかの高レベル（統合）テストを追加しました。

デプロイ：すべてのプラットフォームがいくつかのVMにインストールされています。ビルドにはTFS、アーティファクトにはAWS S3、VMの作成、デプロイ、構成にはAnsibleの組み合わせを使用しています。ここでは、Ansibleが大きな役割を果たします。エージェントレスで、ウィンドウへの接続にPowerShellリモート処理を使用します。web.configのxml変換の使用を中止し、Ansibleテンプレートに移動したため、すべての構成をAnsibleファイルに含めることができます。そしてタコと比較して、それは無料でオープンソースの良い部分です。新しいバージョンでは完全に新しいVMが使用され、修正を展開する必要がある場合にのみサービスを更新します。

スケーリング：このようなデプロイでは、vmsのみをスケーリングでき、サービス自体はスケーリングできません。パフォーマンス（CPU、RAM）、取得するリクエストの数、または時間ベース（週末はトラフィックが少ないなど）を監視して、新しいVMを開始および停止します

監視：AWSを使用しており、時系列アラート用のCloudWatchがありますが、GrafanaとPrometheusに移動することを計画しています（Dockerに近づくためのステップ、現在はServer 2016）。ロギングでは、Graylog（ElastiSearchを背後で使用しています）を使用しています。私たちは前にファイルアペンダにlog4netのを使用していたされているので、それを採用するのは簡単だったし、そこにあるアペンダは Graylogのために特に。これに基づいて多くのアラートを作成できますが、実際には継続的なプロセスであることがわかりました。