リポジトリでマイクロサービスを構造化する方法

Question

約20のマイクロサービスがあるプロジェクトに割り当てられています。それらのそれぞれは、数学関数のようないくつかの一般的なコードを維持する1つのNugetパッケージを除いて、他への参照のない個別のリポジトリにあります。各サービスは、エンドポイントによって他のサービスを参照します。

これの利点は次のとおりです。

各サービスは非常に独立しています。（実際には、1つのサービスのAPIへの変更が他の複数のサービスに影響を与える可能性があるため、この点については議論の余地があります）
ベストプラクティス–私が話をした人によると

欠点は次のとおりです。

コードの再利用はありません。
一部のDTOオブジェクトは複数回定義されています（多分最大10ish）
使いやすさのためにサービスのエンドポイントをラップする各ServiceCommunicationヘルパークラスは、各リポジトリに対して1回ずつ、複数回複製されます。
APIの変更を追跡するのは困難です。テスト/本番環境での失敗がよく見られます

プロジェクトを構成するには、次の方が良い方法だと思います。1つのリポジトリ。各マイクロサービスは、エンドポイントをラップするServer.Communicationヘルパークラスと、Server.CommunicationクラスがそのAPI呼び出しから返す選択Server.Dtoタイプを提供します。他のサービスがそれを使用したい場合は、これが含まれます。

私は問題を十分に説明したことを望みます。これは私の問題のいくつかに対処するより良い解決策ですか、それとも予期しない問題を作成することになりますか？

amon · Answer

通常、コードの再利用は、マイクロサービスのセールスポイントとして理解されていません。

マイクロサービスを開発してデプロイすることができます独立して
異なるマイクロサービスは異なるテクノロジー、特に異なるプログラミング言語を使用できます

これが利点のように思えない場合、特にすべてのマイクロサービスが1つのチームによって1つのテクノロジースタックを使用して開発され、一緒にデプロイされている場合は、マイクロサービスは必要ありませんが、一連のライブラリが必要です。また、すべてのライブラリ/サービスを1つのモノレポ内に維持できます。

少しの間スケーラビリティの引数を無視すると、ライブラリはマイクロサービスよりもはるかに望ましいになります。マイクロサービスAPIは事実上動的に型付けされるであり、これはエラーの原因となる可能性があります–経験したとおりです。対照的に、ライブラリAPIは通常、静的に型指定されます。これにより、コンパイル時の型チェックにより、クラス全体のエラーを防ぐことができます。また、Intellisenseは素晴らしいです。同じプロセス内で実行されるライブラリは分散システムよりも使いやすくなる傾向があり、特にネットワーク障害、一貫性、分散トランザクションに関して独自の課題があります。

マイクロサービスアーキテクチャを使用すると、これらの欠点を受け入れます 組織のスケーラビリティ（異なるチームに開発を任せるなど）およびそれらのサービスを個別に展開します）および技術的なスケーラビリティ（システムのさまざまな部分を個別にスケーリングします）。

ライブラリとマイクロサービスの間に中間の可能性ありがあり、あなたの生活を少し楽にすることができます。

たとえば、マイクロサービスは、そのマイクロサービスに接続するためのクライアントライブラリを提供できます。このライブラリは、接続の詳細を処理し、データ転送オブジェクトのセットを提供します。正しく設計されていれば、古いライブラリバージョンでも新しいバージョンのマイクロサービスとやり取りできるため、それらをいくぶん個別に更新できます。ただし、これには、そのマイクロサービスのすべてのユーザーが同じプログラミング言語を使用し、これらのユーザーが妥当な時間内にクライアントライブラリをアップグレードできることが必要です。このようなアプローチは、影響を理解せずにマイクロサービスの使用を開始したチームには役立つかもしれませんが、組織のスケーラビリティの利点のためにマイクロサービスを使用している場合、通常は実行できません。

これの穏やかなバージョンは、言語に依存しないAPI定義を提供するサービス記述言語を使用することです。その後、クライアントはコード生成ツールを使用して、プログラミング言語でDTOおよび接続ライブラリを生成できます。これにより、APIの不一致エラーの可能性を回避しながら、サービスを別のサービスから正常に分離できます。このサービス記述言語で作業する必要があるため、下位互換性を誤って壊すこともさらに困難になります。ただし、追加のツールを習得する必要があり、生成されたコードは使いにくい場合があります。これは通常、よりエンタープライズ環境に移行する方法です。

高度なテスト方法を適用して、APIの不一致を除外することもできます。記録/再生の統合テスト：最初に、実際のマイクロサービスに対してクライアントのテストケースを実行し、要求と応答を記録します。この記録のアーティファクトは、クライアントとマイクロサービスによって共有されます。次に、録音をクライアントテストで使用して、返信定型文を再生する模擬マイクロサービスを提供できます。録音はマイクロサービスでも使用され、サービスが同じ応答を提供し続けることを確認します。残念ながら、変更に対応するためにこれらの録音を更新することは難しい場合があります。録音は非常に壊れやすい場合もあります。正確な日付などの無関係なメタデータが無害化されていない場合。現在、同様のテストスイートの移行に取り組んでいますが、正確に記録された応答に依存するという脆弱性のため、これは信じられないほど困難です。