疎結合のマイクロサービスアーキテクチャでは、依存関係をどのように追跡しますか？

最新のプログラムで人気のある高レベルのアーキテクチャの選択は、RESTベースのマイクロサービスシステムです。これには、疎結合、再利用の容易さ、使用できるテクノロジーの制限の制限、高いスケーラビリティなどのいくつかの利点があります。

しかし、そのようなアーキテクチャーで私が予測する問題の1つは、アプリケーションの依存関係が何であるかについての可視性が低いことです。たとえば、1組のREST呼び出しを毎日使用するアプリケーションがあるとします。このアプリケーションは、REST呼び出しの2番目のセットも使用しますが、四半期に1回だけです。過去1週間のログをスキャンすると、1日のカロリーはすべて表示されますが、四半期ごとの呼び出しは表示されません。リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。

このリスクを軽減し、疎結合アーキテクチャの依存関係をより詳細に可視化するために使用できるパターンまたはツールは何ですか？

このリスクを軽減するために使用できるパターンまたはツール

APIとビジネス機能の下位互換性を維持します。

疎結合アーキテクチャの依存関係がどのようなものであるかについての詳細な可視性を提供します

ヘルスチェック。

私のサービスは、毎月のAPI機能のクライアントです。しかし、私のサービスは、私のサービスが実行されているときはいつでも、あなたのAPIのクライアントです。したがって、私のサービスは10分ごとに起動するか、毎月のAPIに接続してプロトコルを実行し、サービスに必要な機能が引き続き利用可能であることを確認します。

そのため、ログには、提供する特定の各サービスが実際に使用される頻度が示されているのと同じように、提供する各特定のサービスがまだ利用可能であることを確認するために他のサービスがチェックする頻度が示されます。

依存関係を見つけることができる場所が少なくとも2つあります。

• 構成。外部APIにアクセスするには、それらの各APIに関する一連の情報を知る必要があります。アクセスID、秘密鍵、エンドポイント。このような情報は変更されるため、これらすべてをコードに含めることはできません。例として、最近すべてのマイクロサービスをSSLに移行し始めました。つまり、移行されるサービスに依存するすべてのサービスは、ではなくバージョンを指すように再構成する必要があります。エンドポイントがハードコーディングされているのではなく、構成内にあったことをうれしく思います。https://http://

• インターフェース。APIのバージョンが変更されるため、サービスからコードに直接アクセスすることはありません。また、別のAPIに切り替えることもできます。代わりに、抽象化レイヤーを作成し、インターフェイスを通じて依存関係を使用します。これらのインターフェースを作成するときに共通のロジックに従うことで、後で依存関係を検索するときに作業が楽になります。

リファクタリングの時期になると、四半期ごとの呼び出しが中断するリスクが高くなります。

これが回帰テストの目的です。

コードを見て、変更して、何も壊れていないことを信じることはできません。これはマイクロサービスアーキテクチャでは機能しません。これはモノリシックアプリケーションでも機能しません。コンパイラは、コードを変更するときに発生するエラーの一部をキャッチできます。Haskellなどの一部の言語では、コンパイラーは非常に能力があり、ほとんどのエラーをキャッチできます。ただし、主流の言語用のコンパイラーはあまり役に立ちません。あなたがテストを持っていない場合、あなたは台無しにされています。マイクロサービスの存在は無関係です。

REST APIは大まかに指定されているため、ある時点でgRPC、google protobufs、またはThriftに移動してRPCインターフェースを定義し、バージョン管理することが役立つ場合があります。